Antivirus in FC3?

[Craig White]

On Thu, 2005-03-24 at 11:04 -0600, Les Mikesell wrote:
> On Thu, 2005-03-24 at 08:06, Craig White wrote:
> > > 
> > > If you think people will have trouble making a standard tool work
> > > when it comes with working defaults, consider how much harder it
> > > becomes when you have to build your own tool from parts and it
> > > ends up being one of a kind.  There is quite a bit of talk on
> > > the k12ltsp list about this as they are trying to settle on a
> > > scripted approach to building a working LDAP configuration.  It
> > > just doesn't make sense for every user to have to do that himself.
> > ----
> > OK let me get this straight...
> > 
> > SLES has it's own method for turnkey LDAP
> > Samba is doing their own
> > K12LTSP is doing their own
> > and Paul is asking why Fedora / Red Hat isn't doing their own 
> 
> Yes, you have it straight.  Red Hat, the most popular distribution, or
> so they would like to claim, does not provide a standard solution so
> everyone else is forced to make up their own, resulting in versions
> that aren't likely to interoperate.  It makes about as much sense
> as making every user hand code their own sendmail.cf following their
> own interpretation of the RFC's.
----
give Red Hat some credit - they finally migrated off the terribly
ancient openldap 2.0.27 that was in RHEL 3 into the 2.2.13 (still out of
date) in RHEL 4 and FC-3
----
> > and we know that Red Hat purchased the Netscape Directory
> > 
> > and in the end, we will end up with a lot of different 'standard'
> > implementations of LDAP that work with one specific setup
> > 
> > Doesn't exactly simplify things for users
> 
> Who, other than Red Hat is in a position to fix this?
----
seems to me that LDAP is a much larger technology and has implications -
uses in a large variety of OS's and hardware. My experience tells me
that most of the larger users/consumers of LDAP is not on Linux but on
various Unix systems. 
----
> 
> > Considering all of things that such a system would entail - openssl,
> > cyrus-sasl, kerberos, samba, pam, generating certificates, and on and
> > on, thinking that someone is going to provide a turnkey solution for
> > LDAP is rather myopic...
> 
> The more complicated it is, the more critical it is to supply a standard
> solution and let everyone share the problem solving as they do with
> the other programs included in the distribution.
> 
> > it's only going to entail solutions for the
> > specific needs of a particular set of circumstances and in essence,
> > become a limiting technology when LDAP is purposely designed to be an
> > enabling technology.
> 
> That argument might apply to the linux kernel and it's associated
> drivers that have to specifically address the user's particular
> hardware.  I don't see how it applies to shipping a server that
> will answer the queries of the clients shipped in the same distribution.
----
I understand what you are saying and agree with the thought that you
don't have to understand it to use it.
----
> 
> > Of course the price of admission to this technology
> > has always been knowledge...these really are only efforts to circumvent
> > the need to understand how to set it up and how it works.
> 
> Good defaults are what makes things work.  I don't know how to
> write a device driver and I'm happy that I don't need to.  I wish it
> were the same for LDAP.
----
your view and my view of 'good defaults' for LDAP are likely gonna
differ. I don't know of any 'good defaults' for LDAP
----
> 
> > Not sure how the topic of Windows viruses has transformed into an LDAP
> > discussion...
> 
> I've forgotten where the discussion went, but having a working LDAP
> server where you 'just add users' for the network would go a long way
> toward making it easy to replace virus-ridden boxes with thin clients or
> other linux solutions.
----
I know that you don't believe this but the standard base for users and
groups is in /etc/passwd and /etc/group (and obviously by
implication /etc/shadow)

They's been including various utilities for NIS but no one complains
that they don't have turnkey solutions for NIS administration.

There's little difference with LDAP - if you actually created a DSA,
created a container for 'users' put in the attributes necessary for
users to authenticate, it still wouldn't work. LDAP doesn't do things
necessary such as create user home directories, keep track of UID's and
GID's to keep adding them sequentially, make their home directories, set
their shell, etc. That's another layer of infrastructure. If you start
to consider all of the layers of infrastructure that you will need to
get going, you will find that much of the time, you aren't really
talking about LDAP, you are talking about the integration of other
technologies. 

LDAP is entirely off the table for a distribution unless it chooses to
make it so - and the only way that they can do it is to detail a finite
lists of services that are to be integrated and build it out. Recognize
though that should a distribution take this approach, all of the
services thus built out will have to have customized configurations too.

Now there is an opportunity for a 'distribution' perhaps based on Fedora
core that provides a turnkey/integrated function for all of this stuff -
a one vision, one implementation approach but to expect it to parallel
with SuSE, Debian, FreeBSD etc. is naive.

There may be a point where Red Hat does try to provide an integrated
setup - more specifically a turnkey setup of LDAP - but it isn't likely
to be functional beyond a certain point, interchangeable with other OS's
and other needs/implementations and thus, will be of value only to those
that want to point and click administrate.

Craig