On Sat, 2007-03-10 at 12:51 -0600, Les Mikesell wrote: > Craig White wrote: > > ---- > > FDS isn't installed by default because there is simply no justification > > for doing so. All of the applications/daemons that have ldap client > > libraries compiled in as options > > Are you saying these don't follow standards and thus interoperate correctly? ---- of course not - both FDS and OpenLDAP incorporate a substantial portion of LDAPv3 standards. ---- > > > So instead of installing OpenLDAP-Server you can install FDS and the > > choice is really up to the system administrator but neither is suitable > > as a default install. > > I agree that they aren't suitable, but don't understand why this wasn't > fixed years ago. How is someone with a few machines supposed to make > their accounts work everywhere? ---- the OpenLDAP client software is included and compiled into virtually all potential client applications on Fedora & RHEL that I have run into which on my FC-5 desktop here includes: autofs, cyrus-sasl, ruby-ldap, evolution-data-server, samba, httpd, subversion, apr-util, opal, python-ldap, php-ldap, sendmail, mod_perl, nss_ldap, wine-ldap, squid, kdebase, nfs-utils-lib, libuser, GConf2, postfix. So in answer to the second question...the implementation of account management via LDAP is left to the administrator as opposed to the predetermined methodology incorporated into Windows Active Directory. ---- > > > The point I was trying to make about needing to be versant with command > > line functionality of LDAP was this...if you can't query/maintain LDAP > > from the command line, you are never going to be able to debug/analyze > > how other applications interact with your LDAP server since LDAP doesn't > > operate in a vacuum. > > Why is this any more true for LDAP than any other protocol? Do you > need to understand imap command line tools and protocol analyzers to use > email? ---- I'm not certain that this is more true for LDAP than any other protocol. What I know is that LDAP directory design has no prescribed correct way for setup except for Windows Active Directory. FDS has a prescribed notion on initial setup but it is easily modified which is what I suspect that most people actually do. I suspect that samba will actually drive some standardization because samba is designed specifically for interchangeability with Windows systems and Samba 4 is trying to become interchangeable with Windows Active Directory and if you want to track the DSA design they are recommending... http://wiki.samba.org/index.php/3.0:_Initialization_LDAP_Database I'm not sure that it serves the open source community to have Microsoft dictating LDAP design though. But in answer to your second question, if you run an IMAP server, you definitely need to know imap command line functions at some point to debug... # telnet srv1 143 Trying 192.168.2.1... Connected to srv1.azapple.com (192.168.2.1). Escape character is '^]'. * OK srv1.azapple.com Cyrus IMAP4 v2.2.12-Invoca-RPM-2.2.12-9 server ready . login craig XXXXXXXXXXXX . OK User logged in . LIST INBOX * * LIST (\HasChildren) "." "INBOX" * LIST (\HasNoChildren) "." "INBOX.App-Server" * LIST (\HasNoChildren) "." "INBOX.Catchall" <snip> . logout ---- > > > LDAP is only useful when you link in other > > applications and if you don't understand how they do that, you are going > > to get nowhere. > > Again, why is LDAP any different in this respect that the other methods > doing the same jobs now - that most people use without understanding? > PAM should be covering up most of it anyway. ---- I presume when you mention PAM, you are specifically referring to LDAP as an account authentication system. With respect to this functionality, there are a number of steps that are necessary in order to accomplish this... configure /etc/nsswitch.conf # somewhat accomplished by authconfig tool configure /etc/ldap.conf # somewhat accomplished by authconfig tool configure /etc/pam.d/system-auth # accomplished by authconfig tool generate server & client certificates for TLS/SSL and put into place I am presently accomplishing this through fedora kickstart installs and on first boot, anyone permitted can login and it's not very difficult at all. The issue of practicality cannot be ignored though. If you want to set up and test, you really need a fast method and that is the command line. More to the point, once you can do command line client tools that openldap-clients package provides, your understanding grows and all things become understood. The GUI tools simply do not fill the gap of knowledge but they can provide easy access to data maintenance. Craig
