try lam (ldap account manager)
On Feb 13, 2008 7:04 PM, solarflow99 <[EMAIL PROTECTED]> wrote: > 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 > > _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
