Re: dynamic config replication
On 13-02-18 18:59, Dieter Klünter wrote:
> Am Fri, 9 Feb 2018 15:26:20 +0100
> schrieb Gerard Ranke <gerard.ra...@hku.nl>:
>
>> Hello list,
>>
>> Openldap 2.4.45 here, on 1 producer and 4 consumers. ( I'll attach
>> relevant parts of the configuration at the end of this message. )
>> Following the scripts from test059, I configured the producer to serve
>> up a cn=config backend for the consumers. This seems to work nicely at
>> first: When you start a consumer from a minimal config, it loads the
>> producers schemafiles and the cn=config, and replication of the main
>> database is fine. Also, when fi. changing the loglevel on the
>> producers cn=config,cn=slave, the consumers pick up this change in
>> their cn=config. However, when I modify an olcAccess line on the
>> producers cn=config,cn=slave database, I get these errors on the
>> consumer:
>>
>> slapd[26324]: syncrepl_message_to_entry: rid=002 DN:
>> olcDatabase={1}mdb,cn=config,cn=slave, UUID:
> ^
>
>> 7cff5ef6-90b1-1037-9d95-6dfd3149c2dc
>> slapd[26324]: syncrepl_entry: rid=002
>> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) slapd[26324]: syncrepl_entry:
>> rid=002 inserted UUID 7cff5ef6-90b1-1037-9d95-6dfd3149c2dc
>> slapd[26324]: syncrepl_entry: rid=002 be_search (0)
>> slapd[26324]: syncrepl_entry: rid=002 olcDatabase={1}mdb,cn=config
>
>
>
>> slapd[26324]: null_callback : error code 0x43
>> slapd[26324]: syncrepl_entry: rid=002 be_modify
>> olcDatabase={1}mdb,cn=config (67)
>
>
I believe this is correct: The consumers have a different configuration
than the producer, so it's set up as cn=config,cn=slave on the producer.
The consumers have a suffixmassage option in their olcSyncrepl line that
changes the suffix to cn=config, so the {1}mdb section should land in
the right place.
>> slapd[26324]: syncrepl_entry: rid=002 be_modify failed (67)
>> slapd[26324]: do_syncrepl: rid=002 rc 67 retrying
>>
>> From the error code ox43, it seems that the replication is somehow
>> trying to change the rdn, olcDatabase{1}mdb, on the consumer, which
>> makes no sense to me.
>>
>> From the producer, cn=config,cn=slave:
>> ( This is identical to the consumer's cn=config )
>>
>> dn: cn=config,cn=slave
>> objectClass: olcGlobal
>> objectClass: olcConfig
>> objectClass: top
>> cn: slaveconfig
>> cn: config
>> olcArgsFile: /var/run/slapd/slapd.args
>> olcAttributeOptions: lang-
>> olcAuthzPolicy: none
>> olcConcurrency: 0
>> olcConfigDir: slapd.d/
>> olcConnMaxPending: 100
>> olcConnMaxPendingAuth: 1000
>> olcGentleHUP: FALSE
>> olcIdleTimeout: 0
>> olcIndexIntLen: 4
>> olcIndexSubstrAnyLen: 4
>> olcIndexSubstrAnyStep: 2
>> olcIndexSubstrIfMaxLen: 4
>> olcIndexSubstrIfMinLen: 2
>> olcLocalSSF: 71
>> olcLogFile: none
>> olcLogLevel: none
>> olcPidFile: /var/run/slapd/slapd.pid
>> olcReadOnly: FALSE
>> olcSaslSecProps: noplain,noanonymous
>> olcSizeLimit: 2
>> olcSockbufMaxIncoming: 262143
>> olcSockbufMaxIncomingAuth: 16777215
>> olcThreads: 16
>> olcTLSCACertificatePath: /etc/ssl/certs
>> olcTLSCertificateFile: /etc/ssl/certs/hkuwildcardcacert.cert
>> olcTLSCertificateKeyFile: /etc/ssl/private/hkuwildcardcacert.key
>> olcTLSCRLCheck: none
>> olcTLSVerifyClient: never
>> olcToolThreads: 2
>>
>> I'll leave the rest PM, except for:
>>
>> dn: olcDatabase={0}config,cn=config,cn=slave
>> objectClass: olcDatabaseConfig
>> objectClass: olcConfig
>> objectClass: top
>> olcDatabase: {0}config
> ^^^
> [...]
It's the same here, the producers cn=config,cn=slave is changed in
replication to become just cn=config on the consumer. This actually
works: I can change fi olcLogLevel or schemas on cn=config,cn=slave on
the producer, and they get replicated to the consumers. Just when I try
to change things on the {1}mdb section, like an olcAccess line, I get
the 0x43 errors...
Thanks a lot for answering!
Best,
gerard
signature.asc
Description: OpenPGP digital signature
dynamic config replication
Hello list,
Openldap 2.4.45 here, on 1 producer and 4 consumers. ( I'll attach
relevant parts of the configuration at the end of this message. )
Following the scripts from test059, I configured the producer to serve
up a cn=config backend for the consumers. This seems to work nicely at
first: When you start a consumer from a minimal config, it loads the
producers schemafiles and the cn=config, and replication of the main
database is fine. Also, when fi. changing the loglevel on the producers
cn=config,cn=slave, the consumers pick up this change in their cn=config.
However, when I modify an olcAccess line on the producers
cn=config,cn=slave database, I get these errors on the consumer:
slapd[26324]: syncrepl_message_to_entry: rid=002 DN:
olcDatabase={1}mdb,cn=config,cn=slave, UUID:
7cff5ef6-90b1-1037-9d95-6dfd3149c2dc
slapd[26324]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
slapd[26324]: syncrepl_entry: rid=002 inserted UUID
7cff5ef6-90b1-1037-9d95-6dfd3149c2dc
slapd[26324]: syncrepl_entry: rid=002 be_search (0)
slapd[26324]: syncrepl_entry: rid=002 olcDatabase={1}mdb,cn=config
slapd[26324]: null_callback : error code 0x43
slapd[26324]: syncrepl_entry: rid=002 be_modify
olcDatabase={1}mdb,cn=config (67)
slapd[26324]: syncrepl_entry: rid=002 be_modify failed (67)
slapd[26324]: do_syncrepl: rid=002 rc 67 retrying
>From the error code ox43, it seems that the replication is somehow
trying to change the rdn, olcDatabase{1}mdb, on the consumer, which
makes no sense to me.
>From the producer, cn=config,cn=slave:
( This is identical to the consumer's cn=config )
dn: cn=config,cn=slave
objectClass: olcGlobal
objectClass: olcConfig
objectClass: top
cn: slaveconfig
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcAttributeOptions: lang-
olcAuthzPolicy: none
olcConcurrency: 0
olcConfigDir: slapd.d/
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexIntLen: 4
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcLocalSSF: 71
olcLogFile: none
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcReadOnly: FALSE
olcSaslSecProps: noplain,noanonymous
olcSizeLimit: 2
olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCACertificatePath: /etc/ssl/certs
olcTLSCertificateFile: /etc/ssl/certs/hkuwildcardcacert.cert
olcTLSCertificateKeyFile: /etc/ssl/private/hkuwildcardcacert.key
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcToolThreads: 2
I'll leave the rest PM, except for:
dn: olcDatabase={0}config,cn=config,cn=slave
objectClass: olcDatabaseConfig
objectClass: olcConfig
objectClass: top
olcDatabase: {0}config
olcRootDN: cn=root,cn=config
olcRootPW: xx
olcSyncrepl: {0}rid=002 provider=ldap://xxx.xx.xx bindmethod=simple
binddn="cn=config,cn=slave" credentials=""
tls_cert="/etc/ssl/certs/xxx.cert" tls_key="/etc/ssl/private/xxx.key"
tls_cacertdir="/etc/ssl/certs" tls_reqcert=demand tls_crlcheck=none
searchbase="cn=config,cn=slave" schemachecking=off
type=refreshAndPersist retry="5 5 10 +" suffixmassage="cn=config"
olcSyncUseSubentry: FALSE
This is identical to the consumers olcDatabase={0}config,cn=config entry.
Hopefully somebody can point me in the right direction!
Many thanks in advance,
gerard
Re: OpenLDAP not starting using "systemctl start" but runs fine invoking slapd directly
On 01-09-17 11:30, michael.haer...@t-systems.com wrote:
> Dear List,
>
>
>
> I hope that somebody can help me here.
>
>
>
> My OpenLDAP starts fine using “slapd -d -1 -F /etc/openldap/slapd.d”.
> Everything is OK if I start the service using that command. But if I try
> to use the service “/bin/systemctl start slapd.service” it fails to start.
>
>
>
> “/bin/systemctl start slapd.service
>
> Job for slapd.service failed because the control process exited with
> error code. See "systemctl status slapd.service" and "journalctl -xe"
> for details.”
>
>
>
>
>
> The output of “systemctl status slapd.service”:
>
>
>
> /● slapd.service - OpenLDAP Server Daemon/
>
> / Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled;
> vendor preset: disabled)/
>
> / Active: failed (Result: exit-code) since Fri 2017-09-01 10:37:55
> CEST; 7s ago/
>
> / Docs: man:slapd/
>
> / man:slapd-config/
>
> / man:slapd-hdb/
>
> / man:slapd-mdb/
>
> / file:///usr/share/doc/openldap-servers/guide.html/
>
> / Process: 45146 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS}
> $SLAPD_OPTIONS (code=exited, status=1/FAILURE)/
>
> / Process: 45132 ExecStartPre=/usr/libexec/openldap/check-config.sh
> (code=exited, status=0/SUCCESS)/
>
> / /
>
> /Sep 01 10:37:55 tmv2312.devlab.de.tmo systemd[1]: Starting OpenLDAP
> Server Daemon.../
>
> /Sep 01 10:37:55 tmv2312.devlab.de.tmo runuser[45135]:
> pam_unix(runuser:session): session opened for user ldap by (uid=0)/
>
> /Sep 01 10:37:55 tmv2312.devlab.de.tmo runuser[45135]:
> pam_unix(runuser:session): session closed for user ldap/
>
> /Sep 01 10:37:55 tmv2312.devlab.de.tmo slapd[45146]: @(#) $OpenLDAP:
> slapd 2.4.40 (Nov 3 2016 18:02:29) $/
>
> /
> mockbuild@x86-ol7-builder-01:/builddir/build/BUILD/openldap-2.4.40/openldap-2.4.40/servers/slapd/
>
> /Sep 01 10:37:55 tmv2312.devlab.de.tmo systemd[1]: slapd.service:
> control process exited, code=exited status=1/
>
> /Sep 01 10:37:55 tmv2312.devlab.de.tmo systemd[1]: Failed to start
> OpenLDAP Server Daemon./
>
> /Sep 01 10:37:55 tmv2312.devlab.de.tmo systemd[1]: Unit slapd.service
> entered failed state./
>
> /Sep 01 10:37:55 tmv2312.devlab.de.tmo systemd[1]: slapd.service failed./
>
> / /
>
> Output of “journalctl -xe”
>
>
>
>
>
> /Sep 01 11:24:06 tmv2312.devlab.de.tmo polkitd[772]: Registered
> Authentication Agent for unix-process:51631:336035477 (system bus name
> :1.16850 [/usr/bin/pkttyagent --notify-fd 5 --fall/
>
> /Sep 01 11:24:06 tmv2312.devlab.de.tmo systemd[1]: Starting OpenLDAP
> Server Daemon.../
>
> /-- Subject: Unit slapd.service has begun start-up/
>
> /-- Defined-By: systemd/
>
> /-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel/
>
> /--/
>
> /-- Unit slapd.service has begun starting up./
>
> /Sep 01 11:24:06 tmv2312.devlab.de.tmo runuser[51640]:
> pam_unix(runuser:session): session opened for user ldap by (uid=0)/
>
> /Sep 01 11:24:06 tmv2312.devlab.de.tmo runuser[51640]:
> pam_unix(runuser:session): session closed for user ldap/
>
> /Sep 01 11:24:06 tmv2312.devlab.de.tmo slapd[51651]: @(#) $OpenLDAP:
> slapd 2.4.40 (Nov 3 2016 18:02:29) $/
>
> /
> mockbuild@x86-ol7-builder-01:/builddir/build/BUILD/openldap-2.4.40/openldap-2.4.40/servers/slapd/
>
> /Sep 01 11:24:06 tmv2312.devlab.de.tmo systemd[1]: slapd.service:
> control process exited, code=exited status=1/
>
> /Sep 01 11:24:06 tmv2312.devlab.de.tmo systemd[1]: Failed to start
> OpenLDAP Server Daemon./
>
> /-- Subject: Unit slapd.service has failed/
>
> /-- Defined-By: systemd/
>
> /-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel/
>
> /--/
>
> /-- Unit slapd.service has failed./
>
> /--/
>
> /-- The result is failed./
>
> /Sep 01 11:24:06 tmv2312.devlab.de.tmo systemd[1]: Unit slapd.service
> entered failed state./
>
> /Sep 01 11:24:06 tmv2312.devlab.de.tmo systemd[1]: slapd.service failed./
>
> /Sep 01 11:24:06 tmv2312.devlab.de.tmo polkitd[772]: Unregistered
> Authentication Agent for unix-process:51631:336035477 (system bus name
> :1.16850, object path /org/freedesktop/PolicyKit/
>
> / /
>
> / /
>
> I don’t see any message that would help me to understand the reason for
> the failure.
>
>
>
> The content of slapd.service:
>
>
>
> /“[Unit]/
>
> /Description=OpenLDAP Server Daemon/
>
> /After=syslog.target network-online.target/
>
> /Documentation=man:slapd/
>
> /Documentation=man:slapd-config/
>
> /Documentation=man:slapd-hdb/
>
> /Documentation=man:slapd-mdb/
>
> /Documentation=file:///usr/share/doc/openldap-servers/guide.html/
>
> / /
>
> /[Service]/
>
> /Type=forking/
>
> /PIDFile=/var/run/openldap/slapd.pid/
>
> /Environment="SLAPD_URLS=ldap:/// ldapi:///" "SLAPD_OPTIONS="/
>
> /EnvironmentFile=/etc/sysconfig/slapd/
>
>
Re: delta syncrepl errors
On 28-08-17 17:22, Quanah Gibson-Mount wrote:
> --On Tuesday, August 22, 2017 12:36 PM +0200 Gerard Ranke
> <gerard.ra...@hku.nl> wrote:
>
>> 2017-08-18T14:54:39.153660+02:00 del slapd[25530]: do_syncrep2: rid=001
>> got search entry without Sync State control
>> (reqStart=20170815125023.01Z,cn=accesslog)
>
> You appear to be missing the syncprov overlay from the accesslog DB. I
> would suggest revisting the configuration on your master. Both the
> primary database and the accesslog database require having syncprov
> present, with different options set. It should be something along the
> lines of:
>
> dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: syncprov
> olcSpNoPresent: TRUE
> olcSpReloadHint: TRUE
>
> as can be found in test063
>
Ah, yes, I totally missed that in the docs, must have read over it
somehow... It works now, thanks a lot, Quanah!
gerard
signature.asc
Description: OpenPGP digital signature
delta syncrepl errors
Hello all,
I'm trying to set up delta-syncrepl on a test setup, consisting of a
producer plus consumer running openldap 2.4.45. ( I'll put relevant
parts of both producer and consumer config at the end of this post. )
I'm following the instructions from the openldap manual ( chapter 18.3.2
) as much as possible. Both slapd's start up but replication isn't
happening. I get the following messages in the logs:
producer:
2017-08-18T14:54:39.153754+02:00 pro slapd[10098]: send_search_entry:
conn 1278 ber write failed.
2017-08-18T14:54:44.157627+02:00 pro slapd[10098]: send_search_entry:
conn 1279 ber write failed.
2017-08-18T14:54:49.368758+02:00 pro slapd[10098]: send_search_entry:
conn 1281 ber write failed.
2017-08-18T14:55:09.390341+02:00 pro slapd[10098]: send_search_entry:
conn 1283 ber write failed.
2017-08-18T14:55:19.395091+02:00 pro slapd[10098]: send_search_entry:
conn 1284 ber write failed.
consumer:
2017-08-18T14:54:39.153660+02:00 del slapd[25530]: do_syncrep2: rid=001
got search entry without Sync State control
(reqStart=20170815125023.01Z,cn=accesslog)
2017-08-18T14:54:39.154089+02:00 del slapd[25530]: do_syncrepl: rid=001
rc -1 retrying (1 retries left)
2017-08-18T14:54:44.157539+02:00 del slapd[25530]: do_syncrep2: rid=001
got search entry without Sync State control
(reqStart=20170815125023.01Z,cn=accesslog)
2017-08-18T14:54:44.158156+02:00 del slapd[25530]: do_syncrepl: rid=001
rc -1 retrying
2017-08-18T14:54:49.368843+02:00 del slapd[25530]: do_syncrep2: rid=001
got search entry without Sync State control
(reqStart=20170815125023.01Z,cn=accesslog)
2017-08-18T14:54:49.369446+02:00 del slapd[25530]: do_syncrepl: rid=001
rc -1 retrying
2017-08-18T14:54:59.383750+02:00 del slapd[25530]: do_syncrep2: rid=001
got search entry without Sync State control
(reqStart=20170815125023.01Z,cn=accesslog)
2017-08-18T14:54:59.384369+02:00 del slapd[25530]: do_syncrepl: rid=001
rc -1 retrying
2017-08-18T14:55:09.390382+02:00 del slapd[25530]: do_syncrep2: rid=001
got search entry without Sync State control
(reqStart=20170815125023.01Z,cn=accesslog)
2017-08-18T14:55:09.390971+02:00 del slapd[25530]: do_syncrepl: rid=001
rc -1 retrying
2017-08-18T14:55:19.395206+02:00 del slapd[25530]: do_syncrep2: rid=001
got search entry without Sync State control
(reqStart=20170815125023.01Z,cn=accesslog)
When I do a search on the producer from the consumer I get results that
look like I would expect to see:
ldapsearch -x -h pro.hku.nl -b "cn=accesslog" -D
cn=dsyncuser,dc=hku,dc=nl -w **
"(&(objectClass=auditWriteObject)(reqResult=0))"
(...)
# 20170817170609.01Z, accesslog
dn: reqStart=20170817170609.01Z,cn=accesslog
objectClass: auditAdd
reqStart: 20170817170609.01Z
reqEnd: 20170817170610.00Z
reqType: add
reqSession: 1
reqAuthzID: cn=root,dc=hku,dc=nl
reqDN: nlHkuID=77454,ou=People,dc=hku,dc=nl
reqResult: 0
reqMod: objectClass:+ top
reqMod: objectClass:+ posixAccount
reqMod: objectClass:+ shadowAccount
reqMod: objectClass:+ inetOrgPerson
reqMod: objectClass:+ nlHkuPerson
reqMod: objectClass:+ eduPerson
reqMod: objectClass:+ apple-user
reqMod: objectClass:+ sambaSamAccount
reqMod: ou:+ People
reqMod: authAuthority:+ ;basic;
reqMod: nlHkuID:+ 77454
reqMod: loginShell:+ /bin/false
reqMod: gidNumber:+ 300
(...)
reqMod: structuralObjectClass:+ nlHkuPerson
reqMod: entryUUID:+ 1b7405d0-17ba-1037-98e3-99bbae3c2a53
reqMod: creatorsName:+ cn=root,dc=hku,dc=nl
reqMod: createTimestamp:+ 20170817170608Z
reqMod: entryCSN:+ 20170817170608.603041Z#00#000#00
reqMod: modifiersName:+ cn=root,dc=hku,dc=nl
reqMod: modifyTimestamp:+ 20170817170608Z
reqEntryUUID: 1b7405d0-17ba-1037-98e3-99bbae3c2a53
(...)
The producer config has:
(...)
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}back_mdb.so
olcModuleLoad: {1}dynlist.so
olcModuleLoad: {2}accesslog.so
olcModuleLoad: {3}syncprov.so
olcModuleLoad: {4}smbk5pwd.so
structuralObjectClass: olcModuleList
(...)
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=hku,dc=nl
olcAccess: {0}to * by dn.base="cn=dsyncuser,dc=hku,dc=nl" read by * break
(...)
olcAccess: {15}to * by * read
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcLimits: {0}dn.exact="cn=root,dc=hku,dc=nl" size=unlimited time=unlimited
olcLimits: {1}dn.exact="cn=dsyncuser,dc=hku,dc=nl" size=unlimited time=unlim
ited
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=root,dc=hku,dc=nl
olcRootPW:: ***
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
(...)
dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcAccessLogConfig
objectClass: olcOverlayConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
(...)
dn: olcOverlay={2}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcSyncProvConfig
[SOLVED] olcDbCacheSize: no equality matching rule
Dear listmembers,
After upgrading from openldap 2.4.21 to 2.4.25 my olcDbCacheSize entry seems
to have gone awoll. I
tried to fix that with the following ldif file:
dn: olcDatabase={1}hdb,cn=config
changetype:modify
add: olcDbCachesize
olcDbCachesize: 1
but I got this errormessage:
modifying entry olcDatabase={1}hdb,cn=config
ldap_modify: Inappropriate matching (18)
additional info: modify/add: olcDbCacheSize: no equality matching rule
Been staring at this for too long: The olcDbCacheSize was sitting right
there... Sorry for the noise.
Best,
gerard
