2014-02-25 2:08 GMT+01:00 Italo Valcy <[email protected]>: > > 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.
