I was even just thinking about the front end to openldap, since the task of adding new users, etc could be delegated to someone else with less experience. I can get ldap going, but I want anyone else to be easily familiar with it too, the thought of having to create ldif files just to add a new user, etc is ridiculous. Redhat directory server seems to be better, but i'm not sure its free, havent used it yet. The RH5 docs say its intended to eventually replace openldap, yet theres no sign of it, and solaris has included Sun ONE for ages now.
On Feb 13, 2008 6:02 PM, Collins, Kevin [MindWorks] <[EMAIL PROTECTED]> wrote: > I migrated a large NIS environment to LDAP (with RFC2307) about a year > ago. Because of the large number of servers and high reliance on NIS I > needed to run LDAP and NIS in parallel, so I developed a method sync'ing > LDAP from NIS every time an NIS update was made. > > This method combined modified versions of some of the migration scripts > (see /usr/share/openldap/migration/) that are provided to load LDAP from NIS > with a couple of scripts I found on the net called ldifsort.pl and > ldifdiff.pl, which allowed me to: > > 1) dump current NIS data out into an LDIF file for each NIS source file > 2) dump current LDAP data into an LDIF file for each source > 3) do a sort/diff between the NIS data and the LDAP data > 4) update the LDAP database with differences > > This worked very well, and we ran NIS and LDAP in parallel for several > months. I then developed another process for maintaining LDAP data in a > similar fashion to NIS, where we use LDIF files as the "master" copy, and > update changes into LDAP: > > 1) backup master file (for example, netgroup.ldif) > 2) make edits to master file > 3) dump current LDAP data to temporary LDIF file > 4) do a sort/diff between the data in the file and the LDAP data > 5) update the LDAP database with the difference > > *Note - this method won't work for passwd because users can change their > own passwords - in this case, we treat LDAP as the master, but we still dump > it to a file for modification by admins. > > I find that this has some key advantages over maintaining the data > directly in the database (where we have a staff of about 40 people with > access to update some or all LDAP data): > > 1) We can add comments to the master file. This allows us to track > modification history, which is important to us > 2) We always have the master files to fall back on > 3) We can generate/maintain alternate NIS maps that LDAP doesn't maintain > (netgroup.byhost, netgroup.byuser, passwd.byuid, etc) > > > I should also note that we migrated primarily because we were hitting size > limitations in NIS that could not worked around. We have hundreds of scripts > that use ypmatch/ypcat > commands and they continue to use them because I also wrote a > ypmatch/ypcat replacement script that converts the syntax to LDAP, queries > LDAP, then converts the results back to NIS format. > > I don't know if this helps you or not, but scripting can get you around a > lot of cryptic ldap command syntax... > > Kevin > > ------------------------------ > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *solarflow99 > *Sent:* Wednesday, February 13, 2008 9:14 AM > *To:* Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list > *Subject:* [rhelv5-list] ldap > > I wonder what most people use for central authentication, i'm replacing > an NIS based system and was looking for a more elegant way than having to > use cryptic ldapadd commands with ldiff files. > > > > _______________________________________________ > rhelv5-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/rhelv5-list > >
_______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
