Re: Chaining stops working after slapd restart
On 30.04.2013. 17:09, jeevan kc wrote: Thanks for checking on 2.4.35 . Is there any way to fix the chaining overlay so it works even after restarting the slapd. I need to initiate a password policy for the directory but the chaining needs to be there for it to take effect. Any help / suggestion is appreciated. I was having the same issue with the chaining overlay and cn=config. It seems that the issue only affects the first olcChainDatabase entry, which is obviously ignored after a server restart. Any further olcChainDatabase entry seems to be working correctly. As a workaround, I modified the first olcChainDatabase entry with a dummy olcDBURI (e.g. ldap://127.0.0.1) and created a second olcChainDatabase entry with the correct configuration. As long as ITS#7381 isn't fixed, you could try this workaround. Best regards, Manuel
RE: Chaining stops working after slapd restart
Thanks for the reply Manuel. I'll give that a shot and see if it works. Jeevan Subject: Re: Chaining stops working after slapd restart From: mga...@googlemail.com Date: Fri, 3 May 2013 14:56:24 +0200 CC: openldap-technical@openldap.org To: jeev_...@hotmail.com On 30.04.2013. 17:09, jeevan kc wrote: Thanks for checking on 2.4.35 . Is there any way to fix the chaining overlay so it works even after restarting the slapd. I need to initiate a password policy for the directory but the chaining needs to be there for it to take effect. Any help / suggestion is appreciated. I was having the same issue with the chaining overlay and cn=config. It seems that the issue only affects the first olcChainDatabase entry, which is obviously ignored after a server restart. Any further olcChainDatabase entry seems to be working correctly. As a workaround, I modified the first olcChainDatabase entry with a dummy olcDBURI (e.g. ldap://127.0.0.1) and created a second olcChainDatabase entry with the correct configuration. As long as ITS#7381 isn't fixed, you could try this workaround. Best regards, Manuel
Re: Chaining stops working after slapd restart
On 30.04.2013. 17:09, jeevan kc wrote: Thanks for checking on 2.4.35 . Is there any way to fix the chaining overlay so it works even after restarting the slapd. I need to initiate a password policy for the directory but the chaining needs to be there for it to take effect. Any help / suggestion is appreciated. I can't be of much help here -- I went back to slapd.conf for the time being, since I have an undemanding setup where static configuration and straightforward change management do the job fine. Generally I didn't have problems with cn=config, but as long as there are fragile corner cases such as this one I'm not prepared to use it in production (and unfortunately I don't have time to chase the bug myself.) -- Ivan Nejgebauer Glavni sistem inženjer CIT-UNS/ARMUNS Univerzitet u Novom Sadu Trg Dositeja Obradovića 5 21000 Novi Sad +381 21 485 2025 i...@uns.ac.rs www.uns.ac.rs
Re: Chaining stops working after slapd restart
Quanah Gibson-Mount wrote: --On Monday, April 29, 2013 6:56 PM + jeevan kc jeev_...@hotmail.com wrote: No, I'm fully using cn=config on Openldap 2.4.30 . I'm working on the chain overlay for the past couple of weeks and when now I finally was able to get it working, I found I could modify the slaves until I restart the server. After I restart the server the chaining doesn't work it says strong authentication required. So the chaining basically worked only just before I restarted the server. Please verify whether or not you can reproduce this with OpenLDAP 2.4.35. This sounds similar to ITS#7381, which was filed against 2.4.32. I've just tested 2.4.35 and can reproduce the bug (using the scripts from the ITS attachment.) -- Ivan Nejgebauer Glavni sistem inženjer CIT-UNS/ARMUNS Univerzitet u Novom Sadu Trg Dositeja Obradovića 5 21000 Novi Sad +381 21 485 2025 i...@uns.ac.rs www.uns.ac.rs
RE: Chaining stops working after slapd restart
IvanThanks for checking on 2.4.35 . Is there any way to fix the chaining overlay so it works even after restarting the slapd. I need to initiate a password policy for the directory but the chaining needs to be there for it to take effect. Any help / suggestion is appreciated. Jeevan Date: Tue, 30 Apr 2013 08:51:16 +0200 From: i...@uns.ac.rs To: qua...@zimbra.com CC: jeev_...@hotmail.com; openldap-technical@openldap.org Subject: Re: Chaining stops working after slapd restart Quanah Gibson-Mount wrote: --On Monday, April 29, 2013 6:56 PM + jeevan kc jeev_...@hotmail.com wrote: No, I'm fully using cn=config on Openldap 2.4.30 . I'm working on the chain overlay for the past couple of weeks and when now I finally was able to get it working, I found I could modify the slaves until I restart the server. After I restart the server the chaining doesn't work it says strong authentication required. So the chaining basically worked only just before I restarted the server. Please verify whether or not you can reproduce this with OpenLDAP 2.4.35. This sounds similar to ITS#7381, which was filed against 2.4.32. I've just tested 2.4.35 and can reproduce the bug (using the scripts from the ITS attachment.) -- Ivan Nejgebauer Glavni sistem inženjer CIT-UNS/ARMUNS Univerzitet u Novom Sadu Trg Dositeja Obradovića 5 21000 Novi Sad+381 21 485 2025 i...@uns.ac.rs www.uns.ac.rs
Chaining stops working after slapd restart
Hi, I am trying to setup a chain overlay to allow writes to a read-only slave
to be chained up to the master.
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=configchangetype: add
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
changetype: add
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDBURI: ldap://10.1.0.3/
olcDbIDAssertBind: bindmethod=simple
binddn=cn=admin,dc=example,dc=com
credentials=**
mode=self
This works until I have to restart the slave ldap server. Can anyone help me
fix this problem?
Re: Chaining stops working after slapd restart
--On Monday, April 29, 2013 6:06 PM + jeevan kc jeev_...@hotmail.com
wrote:
Hi,
I am trying to setup a chain overlay to allow writes to a read-only slave
to be chained up to the master.
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
dn:
olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
changetype: add
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDBURI: ldap://10.1.0.3/
olcDbIDAssertBind: bindmethod=simple
binddn=cn=admin,dc=example,dc=com
credentials=**
mode=self
This works until I have to restart the slave ldap server. Can anyone help
me fix this problem?
Are you using slapd.conf and then modifying an instantiated cn=config from
inside of it, rather than fully using cn=config?
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
RE: Chaining stops working after slapd restart
--On Monday, April 29, 2013 6:56 PM + jeevan kc jeev_...@hotmail.com wrote: No, I'm fully using cn=config on Openldap 2.4.30 . I'm working on the chain overlay for the past couple of weeks and when now I finally was able to get it working, I found I could modify the slaves until I restart the server. After I restart the server the chaining doesn't work it says strong authentication required. So the chaining basically worked only just before I restarted the server. Thanks Please do not top post. Please keep replies to the list. Please verify whether or not you can reproduce this with OpenLDAP 2.4.35. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: Chaining not working
Quoting Howard Chu h...@symas.com: The chain overlay needs to be configured on the frontendDB in order to catch these update referrals. Excellent. Thanks to your advice together with Pierangelo's patch of 29 April 2010 (which I hope will soon be committed), my test configuration is now behaving as it should. Thanks! Jaap
Chaining not working
Hi folks,
While testing the current Debian squeeze version of OpenLDAP,
v2.4.23-6, in a provider/consumer syncprov/syncrepl
(refreshAndPersist) configuration, using a patch(1) written by
Pierangelo, I have not been able to get chaining to work.
The consumer, ldaps2, was configured with a referral(2) to the
provider, ldaps1, as well as a chaining configuration(3). A couple of
authzTo rules(4) were added to its entry in the DIT, which immediately
replicated to the consumer, and the provider was configured with an
olcAuthzPolicy directive for to(5). So far, so good.
However, when using ldapmodify on the consumer to test that an entry
in the DIT could actually be modified (the description attr of the
consumer's entry) from there as a result, I got this response:
modifying entry cn=ldaps2,dc=example,dc=com
ldap_modify: Referral (10)
referrals:
ldap://ldaps.example.com/cn=ldaps2,dc=example,dc=com
I know ldapmodify doesn't understand referrals; this is where chaining
should have worked instead. So, I removed the referral from the
consumer's configuration to see what would then happen with the same
command:
modifying entry cn=ldaps2,dc=example,dc=com
ldap_modify: Server is unwilling to perform (53)
additional info: shadow context; no update referral
(shadow context?). In both cases, this shows up in the syslog as a result:
Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 fd=19 ACCEPT from
IP=127.0.1.1:43982 (IP=0.0.0.0:389)
Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 BIND
dn=cn=admin,dc=example,dc=com method=128
Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 BIND
dn=cn=admin,dc=example,dc=com mech=SIMPLE ssf=0
Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 RESULT tag=97 err=0 text=
Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 MOD
dn=cn=ldaps2,dc=example,dc=com
Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 MOD attr=description
Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 RESULT tag=103
err=53 text=shadow context; no update referral
Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=2 UNBIND
Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 fd=19 closed
Have I made a mistake somewhere, or could this be another bug?
Thanks,
Jaap
1)
ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch
2) LDIF applied to ldaps2 (the consumer) to create the referral to
ldaps1 (the provider) via an alias (ldaps):
-
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcUpdateref
olcUpdateref: ldap://ldaps.example.com
-
3) LDIF applied to ldaps2 to create the chaining configuration:
-
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: {1}back_ldap
dn: olcOverlay={0}chain,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
olcChainReturnError: TRUE
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbURI: ldap://ldaps.example.com
olcDbRebindAsUser: TRUE
olcDbIDAssertBind: bindmethod=simple
binddn=cn=ldaps2,dc=example,dc=com
credentials=bilineatus
mode=self
-
4) LDIF to create a couple of authzTo rules for the consumer:
-
dn: cn=ldaps2,dc=example,dc=com
changetype: modify
add: authzTo
authzTo: {0}dn.regex:^uid=[^,]+,ou=people,dc=example,dc=com$
authzTo: {1}dn.exact:cn=admin,dc=example,dc=com
-
5) LDIF to add an olcAuthzPolicy directive to the provider, ldaps1:
-
dn: cn=config
changetype: modify
add: olcAuthzPolicy
olcAuthzPolicy: to
-
Re: Chaining not working
Jaap Winius wrote: Hi folks, While testing the current Debian squeeze version of OpenLDAP, v2.4.23-6, in a provider/consumer syncprov/syncrepl (refreshAndPersist) configuration, using a patch(1) written by Pierangelo, I have not been able to get chaining to work. The consumer, ldaps2, was configured with a referral(2) to the provider, ldaps1, as well as a chaining configuration(3). A couple of authzTo rules(4) were added to its entry in the DIT, which immediately replicated to the consumer, and the provider was configured with an olcAuthzPolicy directive for to(5). So far, so good. However, when using ldapmodify on the consumer to test that an entry in the DIT could actually be modified (the description attr of the consumer's entry) from there as a result, I got this response: modifying entry cn=ldaps2,dc=example,dc=com ldap_modify: Referral (10) referrals: ldap://ldaps.example.com/cn=ldaps2,dc=example,dc=com I know ldapmodify doesn't understand referrals; this is where chaining should have worked instead. So, I removed the referral from the consumer's configuration to see what would then happen with the same command: modifying entry cn=ldaps2,dc=example,dc=com ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral (shadow context?). In both cases, this shows up in the syslog as a result: Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 fd=19 ACCEPT from IP=127.0.1.1:43982 (IP=0.0.0.0:389) Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 BIND dn=cn=admin,dc=example,dc=com method=128 Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 BIND dn=cn=admin,dc=example,dc=com mech=SIMPLE ssf=0 Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 RESULT tag=97 err=0 text= Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 MOD dn=cn=ldaps2,dc=example,dc=com Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 MOD attr=description Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 RESULT tag=103 err=53 text=shadow context; no update referral Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=2 UNBIND Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 fd=19 closed Have I made a mistake somewhere, or could this be another bug? The chain overlay needs to be configured on the frontendDB in order to catch these update referrals. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
