Yeah, when the time came for me to transition to a new machine in my
old department, I chose to go with an OS X server for just this
reason. I ran openldap on Solaris for a long, long time, but eventually
got sick of just messing with ldifs and went with Open Directory, since
we were about 50/50 Linux and OS X. It worked very well, but I had to
break things so that it wasn't "the Apple way" in several places on the
OS X machines. Even with Tiger, though, I still had to do the nfs ldap
automounts by hand, unfortunately, otherwise, everything was via the
interface.
-jeremy
solarflow99 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] <mailto:[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]>
[mailto:[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] <mailto:[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
