Using a persistent search will work, but if the script stops running for any reason (crash, reboot, etc), you might miss some changes. A more reliable, and probably more efficient approach is to use the retro changelog (http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Replication-Using_the_Retro_Changelog_Plug_in.html). As each change is made, it's logged there, with a sequential changenumber id. Using the changenumber ID, you can always record where you left off, so if you have to restart your sync script, you can pick up exactly where you left off. You can probably even use a persistent search on the retro changelog to process changes as they happen near realtime, while still having the benefit of tracking what the last change made was.
- Jeff > -----Original Message----- > From: fedora-directory-users-boun...@redhat.com > [mailto:fedora-directory-users-boun...@redhat.com] On Behalf > Of Andrey Ivanov > Sent: Tuesday, August 04, 2009 3:43 PM > To: General discussion list for the 389 Directory server project. > Subject: Re: [389-users] OpenLDAP as a slave of Fedora > Directory Server? > > Hi, > > You can also use the LDAP persistent search control an then convert > the 389 attributes to openLDAP ones and send them immediately in real > time, and then, once a day, just to be sure that everything is ok you > can push the whole LDIF dump. Here is an example of a simple > persistent search script in perl : > > > my $ldap = Net::LDAP -> new ("ldap-test.example.com", port => 389, > version => 3 ) or die $!; > my $result = $ldap -> bind( "cn=Directory Manager", password > => "mypassword"); > > my $persist = Net::LDAP::Control::PersistentSearch -> new ( > > changeTypes => 15, > > changesOnly => 1, > returnECs => 1 > ); > > > > my $ldap_filter = "(objectClass=*)"; > my $result_search = $ldap -> search ( > base => $COMPLETE_BASE, > scope => "sub", > filter => $ldap_filter, > control => [ $persist ], > callback=> \&process_entry > ); > exit; > > sub process_entry > { > my $message = shift; > my $entry = shift; > print $entry -> dn()."\n"; #output entry DN > my $ldif = Net::LDAP::LDIF -> new( "", "w", onerror > => 'undef'); > $ldif -> write_entry ($entry); #output entry in LDIF > $ldif -> done ( ); > } > > > > You may also be interested in digging a little bit the ldofsort.pl and > ldifdiff.pl utilities from perl-LDAP rpm package (they are in > /usr/share/doc/perl-LDAP-0.33/contrib/ in CentOS/RHEL 5.3). These are > an excellent solution if you need to generate the difference between > two ldifs and then push this delta to openldap, for example... > > > 2009/7/31 Anne Cross <acr...@itasoftware.com>: > > Rats. That's pretty much the conclusion I'd reached, but > I'd hoped I was > > wrong, based on the wiki page. Unfortunately, for account > terminations, we > > need more than just the ldif export/import, and Security is > kind of cranky > > about the lack. > > > > Thanks for the answer. I guess I'll cross my fingers that > somebody takes it > > off of the wishlist soon. > > > > -- juniper > > > > George Holbert wrote: > >> > >> Currently, OpenLDAP and 389 have totally different > replication mechanisms, > >> so you can't really replicate between the two. > >> You can of course export / import filtered LDIF in either > direction, > >> which, depending on the need, is occasionally good enough. > >> > >> Anne Cross wrote: > >>> > >>> I've been through the FDS/389 website, and the best I've > come up with is > >>> this: > http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration > >>> > >>> Unfortunately, that gives me the sync in the wrong > direction. We have > >>> pre-existing OpenLDAP servers that belong to a different > group. We're > >>> supposed to be their ultimate source of data - once we > get set up - but they > >>> won't change their servers from OpenLDAP because, as they > say, they know how > >>> they work and why should they do more work. > >>> > >>> I don't need data synced back from OpenLDAP, but syncrepl > doesn't appear > >>> to do the right thing when pointed at an FDS directory > server, so what's the > >>> secret, undocumented method? Even a hint would help. Google just keeps > >>> turning up pages where people have named their box > "Fedora" and it's all > >>> openldap to openldap. > >>> > >>> > >> > >> > >> > >> -- > >> 389 users mailing list > >> 389-us...@redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > >> > > > > > > -- > > ,___, > > {o,o} Anne "Juniper" Cross > > (___) Senior Linux Systems Engineer and Extropic Crusader > > -"-"-- Information Technology, ITA Software > > /^^^ > > > > -- > > 389 users mailing list > > 389-us...@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > 389 users mailing list > 389-us...@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- 389 users mailing list 389-us...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
