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.
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.
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-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
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 across@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-users@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-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
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...). 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-bounces@redhat.com [mailto:fedora-directory-users-bounces@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 across@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-users@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-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- 389 users mailing list 389-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
If you have your main database as openldap and 389 is your secondary the old slurp replication should be able to push LDAP updates at FDS.
On Tue, Aug 4, 2009 at 4:09 PM, Clowser, Jeffjeff_clowser@fanniemae.com wrote:
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...). 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-bounces@redhat.com [mailto:fedora-directory-users-bounces@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 across@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-users@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-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- 389 users mailing list 389-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- 389 users mailing list 389-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
389-users@lists.fedoraproject.org