[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: modify dn while replication



> Pierangelo Masarati wrote:
>
>>Jehan,
>>
>>the fact of using updatedn in the proxy is a hack,
>>to instruct the proxy about leaving operational
>>attributes in the modification structure;
>>what I suspect is that the test if the incoming
>>request is a replication is done AFTER the bound DN
>>has been rewrittien, so, assuming
>>
>>"cn=replicator,ou=people,dc=int-evry,dc=fr" is a real
>>
>>
> is it a real user ! and it also exist in the slave .
>
>>entry in your master, you should use
>>
>>"cn=replicator-<uid>,ou=people,dc=int-evry,dc=fr"
>>
>>as updatedn in the proxy.
>>
>>
> what do you mean by <uid>, what should I put in <uid> ? I blindly copied
>  the example and obviously had an error while starting the proxy
>
> line 154 (updatedn  "cn=replicator-<uid>,ou=people,dc=int-evry,dc=fr")
> /etc/openldap/slapd_proxy.conf: line 154: updatedn DN is invalid
> slapd stopped.

I mean: updatedn as it would appear AFTER
it is rewritten by the rule you wrote
in the rewrite section, e.g.

rewriteMap  ldap uidMap "ldap:///ou=People,dc=int-evry,dc=fr?uid?one";
rewriteRule "^(uid=[^,]+)(,.*)$$" "%1-%{uidMap(%1)}%2" ":@I"

what is done to avoid stripping the operational
attributes from the entry is to check if
the bound DN is equal to the updatedn; but
the bound DN definitely passes thru the rewrite
rules, because they're the default rules so they
apply to any operation including bind, so, at
least for this very purpose, you need to provide
the updatedn in the slapd.conf as it would appear
after passing thru bind and thus rewriting.

p.

>
>>If this is not the case, I'll dig further.
>>
>>p.
>>
>>
>>
>>
>>>OK, i've move to the rewrite stuff ! unfortunatly I get new problems .
>>> Here I test with  adding a new entry (user maisel)
>>>$ ldapadd -f maisel.ldif -h localhost -D "cn=admin,dc=int-evry,dc=fr"
>>> -x  -W -p
>>>389
>>>Enter LDAP Password:
>>>adding new entry "uid=maisel,ou=People,dc=int-evry,dc=fr"
>>>
>>>Logs on the proxy server
>>>
>>> Feb 19 13:27:21 corbeau slapd[7260]: conn=0 op=0 BIND
>>>dn="cn=replicator,ou=people,dc=int-evry,dc=fr" mech=simple ssf=0 Feb
>>> 19 13:27:21 corbeau slapd[7260]: conn=0 op=0 RESULT tag=97 err=0 text=
>>> Feb 19 13:27:21 corbeau slapd[7260]: conn=0 op=1 ADD
>>>dn="uid=maisel,ou=People,dc=int-evry,dc=fr"
>>>Feb 19 13:27:22 corbeau slapd[7260]: conn=0 op=1 RESULT tag=105 err=80
>>> text=no structuralObjectClass operational attribute
>>>
>>>Logs on the slave:
>>>Feb 19 13:27:21 corbeau slapd[7278]: conn=0 op=0 BIND
>>>dn="cn=replicator,ou=people,dc=int-evry,dc=fr" mech=simple ssf=0 Feb
>>> 19 13:27:21 corbeau slapd[7278]: conn=0 op=0 RESULT tag=97 err=0 text=
>>> Feb 19 13:27:22 corbeau slapd[7278]: conn=0 op=1 ADD
>>>dn="uid=maisel-maisel,ou=People,dc=int-evry,dc=fr"
>>>Feb 19 13:27:22 corbeau slapd[7278]: No structuralObjectClass for
>>> entry (uid=maisel-maisel,ou=People,dc=int-evry,dc=fr)
>>>Feb 19 13:27:22 corbeau slapd[7278]: conn=0 op=1 RESULT tag=105 err=80
>>> text=no structuralObjectClass operational attribute
>>>
>>>However on the master it does have a structuralObjectClass opreational
>>> attribute; proof :
>>>$ ldapsearch -x uid=maisel -D"cn=admin,dc=int-evry,dc=fr"
>>>-b'ou=people,dc=int-evry,dc=fr' -W -h localhost -p 389 + | grep
>>>structuralObjectClass
>>>Enter LDAP Password:
>>>structuralObjectClass: inetOrgPerson
>>>
>>> is this a pb of dn not beeing normalized ? uid=maisel-maisel is
>>>normalized ? should'nt it be also the same value in the dn and in the
>>> attribute uid itself in the entry:
>>>dn: uid=maisel-maisel,ou=People,dc=int-evry,dc=fr
>>>uid: maisel-maisel
>>>so there should be a rewrite rule for the uid atribute itself and not
>>> only for the dn ?
>>>
>>>Configurations; slave and proxy replicate only the subtree:
>>>ou=people,dc=int-evry,dc=fr, master suffix is dc=int-evry,dc=fr . I
>>> tested before rewrite stuff , replication worked fine.
>>>
>>>Master slapd.conf
>>>replica         host=127.0.0.1:8006
>>>                suffix="ou=people,dc=int-evry,dc=fr"
>>>                binddn="cn=replicator,ou=people,dc=int-evry,dc=fr"
>>>bindmethod=simple   credentials=secret
>>>replogfile      /var/lib/ldap/replica/replogfile
>>>
>>>Proxy slapd_proxy.conf
>>>database ldap
>>>suffix          "ou=people,dc=int-evry,dc=fr"
>>>uri             "ldap://127.0.0.1:9006";;
>>>updatedn  "cn=replicator,ou=people,dc=int-evry,dc=fr"
>>>lastmod on
>>>rewriteEngine on
>>>rewriteContext default
>>>binddn cn=admin,ou=people,dc=int-evry,dc=fr
>>>bindpw {crypt}secret
>>>rewriteMap      ldap uidMap
>>>"ldap:///ou=People,dc=int-evry,dc=fr?uid?one"; rewriteRule
>>>"^(uid=[^,]+)(,.*)$$" "%1-%{uidMap(%1)}%2" ":@I"
>>>
>>>Slave slapd_slave.conf
>>>
>>>database        bdb
>>>suffix          "ou=people,dc=int-evry,dc=fr"
>>>rootdn          "cn=admin,ou=people,dc=int-evry,dc=fr"
>>>rootpw          {crypt}secret
>>>directory       /var/lib/ldap/int_slave
>>>#lastmod off
>>>updatedn        "cn=replicator,ou=people,dc=int-evry,dc=fr"
>>>updateref       "ldap://127.0.0.1:389";
>>>
>>>Thanks.
>>>
>>>
>>>
>>>>>:-(
>>>>>
>>>>>here's the error message on the proxy server logs:
>>>>>Feb 16 16:27:23 corbeau slapd[15683]: conn=0 op=1 MOD
>>>>>dn="uid=test,ou=People,dc=int-evry,dc=fr"
>>>>>Feb 16 16:27:23 corbeau slapd[15683]: conn=0 op=1 MOD
>>>>>attr=userPassword homePostalAddress entryCSN modifiersName
>>>>>modifyTimestamp
>>>>>Feb 16 16:27:23 corbeau slapd[15683]: conn=0 op=1 RESULT tag=103
>>>>> err=19 text=entryCSN: no user modification allowed
>>>>>
>>>>>
>>>>>slapd.conf: (running on localhost port 389)
>>>>>database        bdb
>>>>>suffix          "dc=int-evry, dc=fr"
>>>>>rootdn          "cn=admin, dc=int-evry, dc=fr"
>>>>>rootpw          secret
>>>>>directory       /var/lib/ldap/int
>>>>>replica         host=127.0.0.1:8006
>>>>>               binddn="cn=replicator,ou=System,dc=int-evry,dc=fr"
>>>>>bindmethod=simple   credentials=secret
>>>>>replogfile      /var/lib/ldap/replica/replogfile
>>>>>
>>>>>
>>>>>slapd_proxy.conf: (running on localhost port 8006)
>>>>>database ldap
>>>>>suffix          "dc=int-evry,dc=fr"
>>>>>uri             "ldap://127.0.0.1:9006";;
>>>>>lastmod on
>>>>>binddn cn=admin,dc=int-evry,dc=fr
>>>>>bindpw secret
>>>>>
>>>>>slapd_slave.conf: (running on localhost port 9006)
>>>>>
>>>>>database        bdb
>>>>>suffix          "dc=int-evry,dc=fr"
>>>>>rootdn          "cn=admin,dc=int-evry,dc=fr"
>>>>>rootpw          secret
>>>>>directory       /var/lib/ldap/int_slave
>>>>>updatedn        "cn=replicator,ou=System,dc=int-evry,dc=fr"
>>>>>updateref       "ldap://127.0.0.1:389";
>>>>>
>>>>>What a I doing wrong ?,
>>>>>
>>>>>thanks .
>>>>>
>>>>>
>>>>>Pierangelo Masarati wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>Pierangelo Masarati wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>It could be possible, but it's going to be rather clumsy;
>>>>>>>>it depends on whether there's a clear way you can extract
>>>>>>>>a filtering attribute from the DN, e.g. the "uid=<smtg>"
>>>>>>>>part, to do:
>>>>>>>>
>>>>>>>>rewriteMap      ldap uidMap "ldap:///<naming context>?uid?sub"
>>>>>>>> rewriteRule     "^(uid=[^,]+)(,.*)$$" "%1-%{uidMap(%1)}%2" ":@I"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>OK thanks a lot for the example :-), I'll try out, but before one
>>>>>>> question, where should I put
>>>>>>>these rewrite rules, in the replica section of the master ? this
>>>>>>> way :
>>>>>>>
>>>>>>>replica         host=127.0.0.1:9006
>>>>>>>              suffix="ou=people,dc=int-evry,dc=fr"
>>>>>>>
>>>>>>>attr!="posixAccount,shadowAccount,loginShell,homeDirectory,uidNumber,gidNumber,gecos"
>>>>>>>              binddn="cn=replicator,ou=people,dc=int-evry,dc=fr"
>>>>>>>bindmethod=simple   credentials=secret
>>>>>>>              rewriteMap      ldap uidMap
>>>>>>>"ldap:///ou=People,dc=int-evry,dc=fr?uid?one";
>>>>>>>              rewriteRule     "^(uid=[^,]+)(,.*)$$"
>>>>>>>"%1-%{uidMap(%1)}%2" ":@I"
>>>>>>>replogfile /var/lib/ldap/replica/replogfile
>>>>>>>
>>>>>>>or on a dediceted ldap or meta backend ? sorry for beeing so
>>>>>>> ignorant, but it's the first time I play with the rewrite engine !
>>>>>>> by the way, I suspect I need a " rewriteEngine on" somewhere, in
>>>>>>> slapd.conf ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>Sorry, my answer was incomplete.  Yes, you need to replicate
>>>>>>thru a proxy server, e.g. a server in between the master and
>>>>>>the slave so that
>>>>>>
>>>>>>master --> m2s-proxy: uid=test,... ==> uid=test-number,... -->
>>>>>> slave
>>>>>>
>>>>>>you need to figure out what you intend to do with referrals
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>from slave to master; if you need to rewrite as well, then
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>you need another proxy to revert the massaging.
>>>>>>
>>>>>>slave --> s2m-proxy: uid=test-number,... ==> uid=test,... -->
>>>>>> master
>>>>>>
>>>>>>the proxy needs to be a back-ldap compiled with --enable-rewrite,
>>>>>> and needs to be configured with
>>>>>>
>>>>>>database ldap
>>>>>>uri ldap://<slave>
>>>>>>lastmod on
>>>>>>rewriteEngine on
>>>>>>rewriteContext default
>>>>>><rules as in example>
>>>>>>
>>>>>>Note:
>>>>>>
>>>>>>if the proxy is used also for normal operations,
>>>>>>you'll need to deal with other rewrite contexts,
>>>>>>e.g. searchBase, searchFilter, compareDN,
>>>>>>compareAttrDN if you want any rewriting to occur
>>>>>>in these cases.
>>>>>>
>>>>>>you'll also need to deal with searchResults and more,
>>>>>>otherwise they'll be treated with the default rules.
>>>>>>see slapd-meta(5) in the REWRITE section for what
>>>>>>rewrite contexts are active.  otherwise you can add
>>>>>>
>>>>>>rewriteContext searchBase
>>>>>>rewriteContext searchFilter
>>>>>>rewriteContext compareDN
>>>>>>rewriteContext compareAttrDN
>>>>>>
>>>>>>rewriteContext searchResult
>>>>>>rewriteContext searchAttrDN
>>>>>>rewriteContext matchedDN
>>>>>>
>>>>>>if you don't want any rewrite to occur for these
>>>>>>rewrite contexts.
>>>>>>
>>>>>>On the contrary, the default rewriting should occur
>>>>>>for any write operation; the default naming context
>>>>>>is picked if you don't specify any.
>>>>>>
>>>>>>Note: the "lastmod on" should work since the target
>>>>>>is a replica; it is important wince you want the
>>>>>>replica to be in sync with the master also in terms
>>>>>>of timestamps.
>>>>>>
>>>>>>p.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it