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
