Hello,
I have been trying to configure my slave ldap servers to send changes to the master servers.
From what I have been able to understand from previous mailing lists and various google searches I need to configure and olcUpdateref on the salve and then add the chaining overlay (I think it should be on the olcDatabase{-1}frontend database from everything I have read however slaptest using openldap-2.4.36 slapd-chain2.conf as the seed generates the overlay atop of the declared database…)
Everything I have been trying results in a failure:
ldap_modify: Server is unwilling to perform (53) additional info: operation restricted
I cannot for the life of me figure out what needs to be done to enable this. Any help would be appreciated, my ldifs are included below.
-Russell J. Jancewicz University of Connecticut
dn: olcDatabase={1}mdb,cn=config … olcUpdateref: ldap://master.example.com …
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: FALSE
dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: ldap olcDbURI: "ldap://master.example.com" olcDbStartTLS: start starttls=no olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="cn=admin,dc=example,dc=com" credentials="<SECRET>" keepalive=0:0:0 olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0
--On Thursday, September 26, 2013 4:02 PM +0000 "Jancewicz, Russell" russell.jancewicz@uconn.edu wrote:
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: FALSE
dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: ldap olcDbURI: "ldap://master.example.com" olcDbStartTLS: start starttls=no olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="cn=admin,dc=example,dc=com" credentials="<SECRET>" keepalive=0:0:0 olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0
This is not a valid conversion of slapd-chain2.conf from the test suite. How did you arrive at this config?
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration
It was modified from the generation of slapd-chain2.conf which also didn't work (I was working off the assumption that the overlay needed to be on olcDatabase={1}frontend)
This is the slapd-chain2.conf file I am using (modified slightly) The only differences between this and the unmodified slapd-chain2.conf is the directory and the addition of chain-tls and chain-idassert-authzFrom to the "overlay chain" section.
I'm generating my config with it with $ slaptest -f slapd-chain2.conf -F ./slapd.d-test/
""" include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/nis.schema
database hdb directory /srv/ldap/example.com/ suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret
overlay chain chain-uri ldap://master.example.com chain-idassert-bind bindmethod=simple binddn="dc=example,dc=com" credentials=secret mode=self chain-tls start chain-idassert-authzFrom "*" """
The resulting cn=config doesn't generate objects on the olcDatabase={1}frontend database but rather the two following objects are generated within olcOverlay={0}chain,olcDatabase={1}hdb,cn=config
olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config
""" # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 f3da9a85 dn: olcDatabase={0}ldap objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: none starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 structuralObjectClass: olcLDAPConfig entryUUID: df7b759c-bb09-1032-82c9-adb6d4ef9266 creatorsName: cn=config createTimestamp: 20130926151258Z entryCSN: 20130926151258.900907Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130926151258Z """
olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config
""" # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 b7a21479 dn: olcDatabase={1}ldap objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldap://master.example.com" olcDbStartTLS: start starttls=no olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn="dc=example,dc=com" credentials ="secret" keepalive =0:0:0 olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 structuralObjectClass: olcLDAPConfig entryUUID: df7b7c90-bb09-1032-82ca-adb6d4ef9266 creatorsName: cn=config createTimestamp: 20130926151258Z entryCSN: 20130926151258.900907Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130926151258Z """
The changes to relocate these objects to the olcDatabase{-1}fontend was in response to the things I had read online.
-Russell J. Jancewicz University of Connecticut
On 2013-09-26 13:02, "Quanah Gibson-Mount" quanah@zimbra.com wrote:
--On Thursday, September 26, 2013 4:02 PM +0000 "Jancewicz, Russell" russell.jancewicz@uconn.edu wrote:
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: FALSE
dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: ldap olcDbURI: "ldap://master.example.com" olcDbStartTLS: start starttls=no olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="cn=admin,dc=example,dc=com" credentials="<SECRET>" keepalive=0:0:0 olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0
This is not a valid conversion of slapd-chain2.conf from the test suite. How did you arrive at this config?
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC
Zimbra :: the leader in open source messaging and collaboration
Am Thu, 26 Sep 2013 17:23:42 +0000 schrieb "Jancewicz, Russell" russell.jancewicz@uconn.edu:
It was modified from the generation of slapd-chain2.conf which also didn't work (I was working off the assumption that the overlay needed to be on olcDatabase={1}frontend)
This is the slapd-chain2.conf file I am using (modified slightly) The only differences between this and the unmodified slapd-chain2.conf is the directory and the addition of chain-tls and chain-idassert-authzFrom to the "overlay chain" section.
I'm generating my config with it with $ slaptest -f slapd-chain2.conf -F ./slapd.d-test/
""" include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/nis.schema
database hdb directory /srv/ldap/example.com/ suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret
overlay chain chain-uri ldap://master.example.com chain-idassert-bind bindmethod=simple binddn="dc=example,dc=com" credentials=secret mode=self chain-tls start chain-idassert-authzFrom "*" """
[...]
In this particular case chaining is a global configuration parameter, bear in mind that chaining confuration is based on back-ldap, thus you may add configuration parameters from slapd-ldap(5) by attaching a chain- prefix.
[other global stuff] overlay chain chain-uri ldap://some.host chain-idassert-bind bindmethod=xxxxx credentials=xxxx mode=self flags=non-prescriptive chain-return-error TRUE chain-rebind-as user TRUE
database config [...] database mdb [...]
-Dieter
On 2013-09-26 15:04, "Dieter Klünter" dieter@dkluenter.de wrote:
Am Thu, 26 Sep 2013 17:23:42 +0000 schrieb "Jancewicz, Russell" russell.jancewicz@uconn.edu:
It was modified from the generation of slapd-chain2.conf which also didn't work (I was working off the assumption that the overlay needed to be on olcDatabase={1}frontend)
This is the slapd-chain2.conf file I am using (modified slightly) The only differences between this and the unmodified slapd-chain2.conf is the directory and the addition of chain-tls and chain-idassert-authzFrom to the "overlay chain" section.
I'm generating my config with it with $ slaptest -f slapd-chain2.conf -F ./slapd.d-test/
""" include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/nis.schema
database hdb directory /srv/ldap/example.com/ suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret
overlay chain chain-uri ldap://master.example.com chain-idassert-bind bindmethod=simple binddn="dc=example,dc=com" credentials=secret mode=self chain-tls start chain-idassert-authzFrom "*" """
[...]
In this particular case chaining is a global configuration parameter,
If that's the case what should I do to propagate writes/modifies from a *specific* database on my slave to a master? (ideally in cn=config style ldifs, not ldap.conf)
Regardless if I apply it to the {-1}frontend or the {1}hdb both situations have resulted in the unwilling to perform error.
bear in mind that chaining confuration is based on back-ldap, thus you may add configuration parameters from slapd-ldap(5) by attaching a chain- prefix.
[other global stuff] overlay chain chain-uri ldap://some.host chain-idassert-bind bindmethod=xxxxx credentials=xxxx mode=self flags=non-prescriptive chain-return-error TRUE chain-rebind-as user TRUE
database config [...] database mdb [...]
-Dieter
-- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E
-Russell J. Jancewicz University of Connecticut
Am Thu, 26 Sep 2013 19:50:08 +0000 schrieb "Jancewicz, Russell" russell.jancewicz@uconn.edu:
On 2013-09-26 15:04, "Dieter Klünter" dieter@dkluenter.de wrote:
Am Thu, 26 Sep 2013 17:23:42 +0000 schrieb "Jancewicz, Russell" russell.jancewicz@uconn.edu:
It was modified from the generation of slapd-chain2.conf which also didn't work (I was working off the assumption that the overlay needed to be on olcDatabase={1}frontend)
This is the slapd-chain2.conf file I am using (modified slightly) The only differences between this and the unmodified slapd-chain2.conf is the directory and the addition of chain-tls and chain-idassert-authzFrom to the "overlay chain" section.
I'm generating my config with it with $ slaptest -f slapd-chain2.conf -F ./slapd.d-test/
""" include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/nis.schema
database hdb directory /srv/ldap/example.com/ suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret
overlay chain chain-uri ldap://master.example.com chain-idassert-bind bindmethod=simple binddn="dc=example,dc=com" credentials=secret mode=self chain-tls start chain-idassert-authzFrom "*" """
[...]
In this particular case chaining is a global configuration parameter,
If that's the case what should I do to propagate writes/modifies from a *specific* database on my slave to a master? (ideally in cn=config style ldifs, not ldap.conf)
Regardless if I apply it to the {-1}frontend or the {1}hdb both situations have resulted in the unwilling to perform error.
If you want to chain write operations to a remote server, you should define your local server, or at least partitions of the local server, as a syncrepl client.
-Dieter
On 2013-09-26 16:42, "Dieter Klünter" dieter@dkluenter.de wrote:
Am Thu, 26 Sep 2013 19:50:08 +0000 schrieb "Jancewicz, Russell" russell.jancewicz@uconn.edu:
On 2013-09-26 15:04, "Dieter Klünter" dieter@dkluenter.de wrote:
Am Thu, 26 Sep 2013 17:23:42 +0000 schrieb "Jancewicz, Russell" russell.jancewicz@uconn.edu:
It was modified from the generation of slapd-chain2.conf which also didn't work (I was working off the assumption that the overlay needed to be on olcDatabase={1}frontend)
This is the slapd-chain2.conf file I am using (modified slightly) The only differences between this and the unmodified slapd-chain2.conf is the directory and the addition of chain-tls and chain-idassert-authzFrom to the "overlay chain" section.
I'm generating my config with it with $ slaptest -f slapd-chain2.conf -F ./slapd.d-test/
""" include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/nis.schema
database hdb directory /srv/ldap/example.com/ suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret
overlay chain chain-uri ldap://master.example.com chain-idassert-bind bindmethod=simple binddn="dc=example,dc=com" credentials=secret mode=self chain-tls start chain-idassert-authzFrom "*" """
[...]
In this particular case chaining is a global configuration parameter,
If that's the case what should I do to propagate writes/modifies from a *specific* database on my slave to a master? (ideally in cn=config style ldifs, not ldap.conf)
Regardless if I apply it to the {-1}frontend or the {1}hdb both situations have resulted in the unwilling to perform error.
If you want to chain write operations to a remote server, you should define your local server, or at least partitions of the local server, as a syncrepl client.
The system I am working on is already a syncrepl consumer from the master (hence the terminology master, slave).
The master system is sends all data to the slave. I want any attempted writes to said save to be forwarded back to the master. I understand that individual LDAP clients can complete this via referral chasing however I would like (and maybe wrongly assumed) that chaining would provide me this functionality. If this is not how chaining behaves would someone please explain the intended use?
From what I read in documentation and other places it would appear that
the following configurations should accomplish what I am looking for however every variation on them results in Server unwilling to preform on modify
dn: olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: FALSE
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.com" olcDbIDAssertBind: mode=self bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials="secret"
I am trying to add said chaining to an already running server which was bootstrapped via cn=config.
*** Is there any way to accomplish what I am looking to do? *** Should I modify the LDIF above in any way to make things work?
-Russell J. Jancewicz University of Connecticut
openldap-technical@openldap.org
-
Dieter Klünter -
Jancewicz, Russell -
Quanah Gibson-Mount