Antivirus in FC3?

[Craig White]

On Thu, 2005-03-24 at 17:23 -0600, Les Mikesell wrote:
> On Thu, 2005-03-24 at 14:29, Craig White wrote:
> 
> > > That's the odd part.  All the pieces are there, but they are still
> > > useless unless someone puts them together in a standard way.
> > ----
> > OK - I'll byte - what is the standard way? I certainly don't see a
> > standard way defined by openldap.org
> > ----
> 
> It will be the way that the most popular distribution decides to
> ship it.
----
I guess then 'not implemented' out of the box is the standard way that
Fedora and RHEL chooses to implement LDAP - makes perfectly good sense
to me.
----
> 
> > > Most people need just what the clients
> > > included in their distribution know how to query plus perhaps a
> > > replacement for their ancient windows NT domain controller.  All
> > > easily canned stuff.
> > ----
> > I've been doing exactly that - replacing WinNT 4 domain
> > controllers...damn if I see it as 'easily canned stuff' - I'm obviously
> > not as bright as you.
> > ----
> 
> Not me - I haven't made it all work yet because as soon as a popular
> distribution ships something, everything else will be obsolete.  However
> the discussion on the k12ltsp list leads me to believe that a scripted
> setup works for a lot of people, and they end up with linux accounts
> with automounted home dirs and an idealx based domain controller. If
> a few more people succeed with the setup it will probably be included
> in the distribution which is basically fedora plus ltsp and a few other
> extras.
----
see this is what confuses me - k12ltsp is thin clients for Linux server.
Windows domain controller seems to be totally out of purview of k12ltsp.
Of course, it all breaks if they don't use k12ltsp server for domain
controller and my general feelings about IDEALX scripts are that they
are a poor way to run a railroad. 

Now that we are discussing the IDEALX scripts - they are a one size fits
all and the only time I have used them is to migrate an NT 4 domain
controller and I have had to hack the scripts to get what I want and
then I still end up doing a slapcat on the DSA and a few global
find/replace edits, drop the DSA, slapadd the fixed one and then I'm
done. No doubt they are finding that IDEALX scripts need a bunch of work
for their purposes too.

The purpose of the IDEALX scripts is to facilitate the use of
Microsoft's 'User Manager for Domains' utility aka usrmgr.exe

While this tool does a reasonable job for Windows attributes, it falls
far short in all other areas so the IDEALX scripts too end up being
mostly inadequate for a more comprehensive solution.
----
> > of course the 'good default' of IDEALX doesn't do anything with
> > automounted home directories - in fact - I haven't spent the time, but
> > Red Hat's autofs.schema doesn't work at all with openldap-2.2.24
> > 
> > One of these days, I'm gonna play with it and find out why - haven't had
> > the time.
> > ----
> 
> If you poke through recent k12ltsp list archives you should find the
> script setup.
---
I do see a k12ltsp-list at lists.redhat.com but there's nothing really
in the archives - I am a subscriber to ltsp list @ sourceforge but there
hasn't been that much discussed about ldap

of course the k12ltsp is as you say, a fedora based project where as
ltsp itself is vendor neutral - thus a 'fedora' solution isn't going to
be adopted by the larger project if it isn't vendor neutral. At best, it
is going to be a 'local' fix.

Based on my experience on samba at lists.samba.org and turnkey installation
of IDEALX scripts, there is going to be a LOT of pain, anguish,
frustration and recrimination going on in k12ltsp arena if they actually
implement this.
---
> 
> > ----
> > open source - knock yourself out - or leave it to others to do it but it
> > hardly seems to be a valid complaint if you expect others to do that for
> > you.
> > ----
> 
> But it is of marginal use if it won't work automatically with the
> next box I install.  That won't happen until a big player sets the
> standard.
---
I guess I'm really dense then because all this time, I thought Fedora
was a community based, community supported distro. How did the
discussion end up when you brought this up to fedora-devel list?

Surely your not expecting this discussion on this list to get anything
done in this regard.
---
> > > 
> > > But there are clients already in the distribution - just no server to
> > > match.
> > ----
> > some clients yes...but many clients no
> > ----
> 
> Authentication, samba, addressbooks, maybe sendmail - I'll settle for
> all of those working network-wide.
---
me too - where can I find it?

Well, I've got to set it up myself again - well that's ok, I get it now,
and it doesn't take me long.
---
> 
> > I know that the only 'simple' implementation is one that isn't that
> > simple when you start to flesh it out.
> 
> The kernel isn't simple - apache isn't simple - sendmail isn't simple.
> Things that are already done don't have to be simple to work.
---
mod_authz_ldap and sendmail are actually fairly easy to implement ONCE
you get ldap working AND you understand it. It's the fairy dust
methodology that gets bogged down here, as in - there's no way in hell
that a script can implement what would be needed to make sendmail,
mod_authz_ldap, postfix (maybe), cyrus-imapd (no way), ftp (no).

In fact, this is the ugly truth about LDAP - once you finally get
it...you get it. Until then, it's a bitch. So to implement even a core
LDAP setup without a full understanding, you can't troubleshoot, you
can't fix it, you can't even describe what it is that isn't working.
It's a tragedy that I see playing out daily on the samba list. They've
now moved much of that traffic over to ldap-interop list so it plays in
two separate arena's now.
---
> 
> > And by the way...'the most popular distribution DOES ship a working
> > server based upon standards' - at least as they interpret them and that
> > includes kerberos, dns, dhcp, account management, authentication
> > services and ldap - it's called Windows Server.
> 
> Seems to have worked out OK for them.
---
security issues notwithstanding - perhaps

extensible? Not many people I know can extend it.

Craig