You might want to look into phpldapadmin...
 
Kevin

________________________________

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of solarflow99
Sent: Wednesday, February 13, 2008 4:04 PM
To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list
Subject: Re: [rhelv5-list] ldap


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

Reply via email to