Dear all,
I`m trying to setup replication from OpenLDAP to Fedora 389 DS. It used to work by running slurpd in a push mode initiated by the provider. With OL 2.4 this seems to be replaced by syncrepl proxy mode [1], which works by defining a LDAP backend that will write updates on the consumer from data received from syncrepl engine (provider), acting as a proxy (examples in [1]).
This is not working in case of sincronization from OL to 389 DS, because operational attributes (entryCSN, structuralObjectClass, entryUUID, etc.) is not accepted in 389 DS, giving the following error in 389 DS:
[22/Feb/2014:18:17:25 -0300] - Entry "uid=XXX,dc=sub,dc=example,dc=com" -- attribute "entrycsn" not allowed
I've tried to filter those operational attributes on synrepl, by using "exattrs='structuralObjectClass,entryUUID,entryCSN'" but it didnt help. Another approach (the right one, see bellow) would be disable "lastmod", but then syncprov overlay complains and don't starts (lastmod TRUE is required by syncprov).
From LDAP backend man pages, it already gives a feeling that when proxying,
then lastmod should be OFF (and this is the default behavior):
"Note: In early versions of back-ldap it was recommended to always set 'lastmod off' for ldap and meta databases. This was required because operational attributes related to entry creation and modification should not be proxied, as they could be mistakenly written to the target server(s), generating an error."
So, is there any way to don't export the operational attributes from OL in the above scenario?
Thanks for any help!
[1] http://www.openldap.org/doc/admin24/replication.html#Syncrepl%20Proxy%20Mode
2014-02-25 2:08 GMT+01:00 Italo Valcy italovalcy@gmail.com:
Dear all,
I`m trying to setup replication from OpenLDAP to Fedora 389 DS. It used to work by running slurpd in a push mode initiated by the provider. With OL 2.4 this seems to be replaced by syncrepl proxy mode [1], which works by defining a LDAP backend that will write updates on the consumer from data received from syncrepl engine (provider), acting as a proxy (examples in [1]).
This is not working in case of sincronization from OL to 389 DS, because operational attributes (entryCSN, structuralObjectClass, entryUUID, etc.) is not accepted in 389 DS, giving the following error in 389 DS:
[22/Feb/2014:18:17:25 -0300] - Entry "uid=XXX,dc=sub,dc=example,dc=com" -- attribute "entrycsn" not allowed
I've tried to filter those operational attributes on synrepl, by using "exattrs='structuralObjectClass,entryUUID,entryCSN'" but it didnt help. Another approach (the right one, see bellow) would be disable "lastmod", but then syncprov overlay complains and don't starts (lastmod TRUE is required by syncprov).
From LDAP backend man pages, it already gives a feeling that when proxying, then lastmod should be OFF (and this is the default behavior):
"Note: In early versions of back-ldap it was recommended to always set 'lastmod off' for ldap and meta databases. This was required because operational attributes related to entry creation and modification should not be proxied, as they could be mistakenly written to the target server(s), generating an error."
So, is there any way to don't export the operational attributes from OL in the above scenario?
Hi,
you should give a try to LSC : http://lsc-project.org/wiki/
This engine allows you to define which attributes to sync, and can use syncrepl to get all modifications done on OpenLDAP on the fly.
Clément.
Hi Clément,
On Tue, Feb 25, 2014 at 5:06 AM, Clément OUDOT clem.oudot@gmail.com wrote:
you should give a try to LSC : http://lsc-project.org/wiki/
This engine allows you to define which attributes to sync, and can use syncrepl to get all modifications done on OpenLDAP on the fly.
Thanks for the tip. I will take a look at it, but I would like to try found a solution to the OL issue because it may be usefull in a lot of scenarios. :)
Regards, Italo.
Am Mon, 24 Feb 2014 22:08:30 -0300 schrieb Italo Valcy italovalcy@gmail.com:
Dear all,
I`m trying to setup replication from OpenLDAP to Fedora 389 DS. It used to work by running slurpd in a push mode initiated by the provider. With OL 2.4 this seems to be replaced by syncrepl proxy mode [1], which works by defining a LDAP backend that will write updates on the consumer from data received from syncrepl engine (provider), acting as a proxy (examples in [1]).
This is not working in case of sincronization from OL to 389 DS, because operational attributes (entryCSN, structuralObjectClass, entryUUID, etc.) is not accepted in 389 DS, giving the following error in 389 DS:
[22/Feb/2014:18:17:25 -0300] - Entry "uid=XXX,dc=sub,dc=example,dc=com" -- attribute "entrycsn" not allowed
I've tried to filter those operational attributes on synrepl, by using "exattrs='structuralObjectClass,entryUUID,entryCSN'" but it didnt help. Another approach (the right one, see bellow) would be disable "lastmod", but then syncprov overlay complains and don't starts (lastmod TRUE is required by syncprov).
From LDAP backend man pages, it already gives a feeling that when proxying, then lastmod should be OFF (and this is the default behavior):
"Note: In early versions of back-ldap it was recommended to always set 'lastmod off' for ldap and meta databases. This was required because operational attributes related to entry creation and modification should not be proxied, as they could be mistakenly written to the target server(s), generating an error."
So, is there any way to don't export the operational attributes from OL in the above scenario?
RFC 3673 describes an 'All Operational Attributes' mechanism, which is defined as '+', while an '*' defines all user attributes.
man slapd-config(5) comments in the olcSyncrepl part on default value 'attrs=*,+'. Just define attrs=*
-Dieter
Hi Dieter,
Thanks for the tip!
Actually the problem here is not which attributes are get by ryncrepl from the provider. The problem is that the backend seems to insert the attributes again and then send to the consumer (lastmod on, which is mandatory to syncrepl), do you see?
For example, I've already tried "attrs=*" and "exattrs=structuralObjectClass,entryUUID,entryCSN,creatorsName,createTimestamp,modifiersName,modifyTimestamp", however both fails to syncronize with the consumer because the backend seems to insert these attributes again (IMO because of the mandatory "lastmod on").
I'm using the same ideia from OpenLDAP replication document (proxy mode).
Regards, Italo
Am Tue, 25 Feb 2014 08:37:41 -0300 schrieb Italo Valcy italovalcy@gmail.com:
Hi Dieter,
Thanks for the tip!
Actually the problem here is not which attributes are get by ryncrepl from the provider. The problem is that the backend seems to insert the attributes again and then send to the consumer (lastmod on, which is mandatory to syncrepl), do you see?
For example, I've already tried "attrs=*" and "exattrs=structuralObjectClass,entryUUID,entryCSN,creatorsName,createTimestamp,modifiersName,modifyTimestamp", however both fails to syncronize with the consumer because the backend seems to insert these attributes again (IMO because of the mandatory "lastmod on").
You didn't mention the OpenLDAP version, as actual man slapd-ldap states:
In early versions of back-ldap it was recommended to always set lastmod off ... The current implementation automatically sets lastmod to off, so its use is redundant and should be omitted.
-Dieter
Hello Dieter,
On Tue, Feb 25, 2014 at 10:50 AM, Dieter Klünter dieter@dkluenter.dewrote:
You didn't mention the OpenLDAP version, as actual man slapd-ldap states:
In early versions of back-ldap it was recommended to always set lastmod off ... The current implementation automatically sets lastmod to off, so its use is redundant and should be omitted.
Thanks for the reply. Yes, but when using syncrepl you must enable "lastmod". We have this written on man slapd-conf:
olcLastMod: TRUE | FALSE ... It also controls the entryCSN and entryUUID attributes, which are needed by the syncrepl provider.
And it is hardcoded on syncprov overlay (servers/slapd/overlays/syncprov.c):
static int syncprov_db_open( BackendDB *be, ConfigReply *cr ) { ... if ( !SLAP_LASTMOD( be )) { Debug( LDAP_DEBUG_ANY, "syncprov_db_open: invalid config, lastmod must be enabled\n", 0, 0, 0 ); return -1; }
Kind regards, Italo.
Am Tue, 25 Feb 2014 16:03:34 -0300 schrieb Italo Valcy italovalcy@gmail.com:
Hello Dieter,
On Tue, Feb 25, 2014 at 10:50 AM, Dieter Klünter dieter@dkluenter.dewrote:
You didn't mention the OpenLDAP version, as actual man slapd-ldap states:
In early versions of back-ldap it was recommended to always set lastmod off ... The current implementation automatically sets lastmod to off, so its use is redundant and should be omitted.
Thanks for the reply. Yes, but when using syncrepl you must enable "lastmod". We have this written on man slapd-conf:
No, syncrepl (consumer) does not reqire operational attributs. Only if the ldap backend is also defined as syncprov (provider), than some operational attributes are required in order to provide valid data. But I don't think that the fedora directory supports RFC 4533.
-Dieter
Hello Dieter,
On Tue, Feb 25, 2014 at 5:05 PM, Dieter Klünter dieter@dkluenter.de wrote:
No, syncrepl (consumer) does not reqire operational attributs. Only if the ldap backend is also defined as syncprov (provider), than some operational attributes are required in order to provide valid data. But I don't think that the fedora directory supports RFC 4533.
Thanks for the reply!
Yes, but this is the only way the documentation points to in order to have a push-based replication initiated by the provider, do you agree? Bellow is part of OL documentation:
18.2.4. Syncrepl Proxy Mode
While the LDAP Sync protocol supports both pull- and push-based replication, the push mode (refreshAndPersist) must still be initiated from the consumer before the provider can begin pushing changes (...) This mode can be configured with the aid of the LDAP Backend (Backends and slapd-ldap(8)). Instead of running the syncrepl engine on the actual consumer, a slapd-ldap proxy is set up near (or collocated with) the provider that points to the consumer, and the syncrepl engine runs on the proxy.
18.2.4.1. Replacing Slurpd
The old slurpd mechanism only operated in provider-initiated push mode. Slurpd replication was deprecated in favor of Syncrepl replication and has been completely removed from OpenLDAP 2.4.
Using the old slurpd, it was possible to filter which attributes I would like to send to the consumer. But, as far as could understand, this workaround is not possible with the above proposal (from doc).
Do you see any other way to achieve this feature?
Kind regards, Italo.
Am Tue, 25 Feb 2014 18:24:14 -0300 schrieb Italo Valcy italovalcy@gmail.com:
Hello Dieter,
On Tue, Feb 25, 2014 at 5:05 PM, Dieter Klünter dieter@dkluenter.de wrote:
No, syncrepl (consumer) does not reqire operational attributs. Only if the ldap backend is also defined as syncprov (provider), than some operational attributes are required in order to provide valid data. But I don't think that the fedora directory supports RFC 4533.
Thanks for the reply!
Yes, but this is the only way the documentation points to in order to have a push-based replication initiated by the provider, do you agree? Bellow is part of OL documentation:
18.2.4. Syncrepl Proxy Mode While the LDAP Sync protocol supports both pull- and push-basedreplication, the push mode (refreshAndPersist) must still be initiated from the consumer before the provider can begin pushing changes (...) This mode can be configured with the aid of the LDAP Backend (Backends and slapd-ldap(8)). Instead of running the syncrepl engine on the actual consumer, a slapd-ldap proxy is set up near (or collocated with) the provider that points to the consumer, and the syncrepl engine runs on the proxy.
18.2.4.1. Replacing Slurpd The old slurpd mechanism only operated in provider-initiated pushmode. Slurpd replication was deprecated in favor of Syncrepl replication and has been completely removed from OpenLDAP 2.4.
Using the old slurpd, it was possible to filter which attributes I would like to send to the consumer. But, as far as could understand, this workaround is not possible with the above proposal (from doc).
Do you see any other way to achieve this feature?
Actually, I have no clue how to configure fedora directory as syncrepl consumer. Just as a proof of conzept I have setup a ldap backend with a minimal configuration which you may find here http://pastebin.de/40936 and simulated a consumer
ldapsearch \ -Esync=rp/rid=091,csn=20140115000000.126579Z#000000#000#000000 \ -x -D "cn=Replicator,o=avci,c=de" -w xxxx -H ldap://localhost \ -b "o=avci,c=de" -s sub "*"
You may test yourself.
-Dieter
Italo Valcy wrote:
Hi Dieter,
Thanks for the tip!
Actually the problem here is not which attributes are get by ryncrepl from the provider. The problem is that the backend seems to insert the attributes again and then send to the consumer (lastmod on, which is mandatory to syncrepl), do you see?
For example, I've already tried "attrs=*" and "exattrs=structuralObjectClass,entryUUID,entryCSN,creatorsName,createTimestamp,modifiersName,modifyTimestamp", however both fails to syncronize with the consumer because the backend seems to insert these attributes again (IMO because of the mandatory "lastmod on").
I'm using the same ideia from OpenLDAP replication document (proxy mode).
Syncrepl requires entryCSN and entryUUID, it cannot work without them. You must add them to your 389DS schema if you want to attempt this.
Hi Italo
On Tue, Feb 25, 2014 at 2:08 AM, Italo Valcy italovalcy@gmail.com wrote:
Dear all,
I`m trying to setup replication from OpenLDAP to Fedora 389 DS.
Honestly I don't know the actual state of this implementation, but I suggest you have a look at: - the changelog of 389DS 1.3.2.2 [1] - the details published within this 389DS ticket [2] - possibly the history of the development requisite on the freeipa-devel mailing list (sorry I didn't search this).
If you follow this route, please eventually share your knowledge Marco
[1] http://directory.fedoraproject.org/wiki/Releases/1.3.2.2 [2] https://fedorahosted.org/389/ticket/47388
Hello guys,
Thanks for the replies! I'll take a look at each suggestion and give you a reply soon.
Regards, Italo.
openldap-technical@openldap.org
-
Clément OUDOT -
Dieter Klünter -
Howard Chu -
Italo Valcy -
Marco Pizzoli