hi all,
the last few days i was testing a setup with several openldap 2.0.18
servers. one is the master slapd, the rest are configured as replicas.
replication works as expected, updates on the master slapd are
propagated to the slaves. update requests received by the slaves are
answered with a referral to the master slapd.
the oddity i mentioned above happened, when i tried to change the
password of an entry with ldappasswd. by accident, i called ldappasswd
with a host that is running a slave slapd as the host argument. i
expected the slave slapd to return a referral to the master slapd or at
least an error message. neither happended.
instead, the slave slapd died and ldappasswd exited with the error
message:
"ldappasswd: ldap_result: Can't contact LDAP server"
slapd logged this debug info:
Jan 7 20:00:49 stumm slapd[6046]: daemon: activity on 1 descriptors
Jan 7 20:00:49 stumm slapd[6046]: daemon: new connection on 11
Jan 7 20:00:49 stumm slapd[6046]: daemon: conn=1 fd=11 connection from IP=10.16.1.19:1132 (IP=0.0.0.0:34049) accepted.
Jan 7 20:00:49 stumm slapd[6046]: daemon: added 11r
Jan 7 20:00:49 stumm slapd[6046]: daemon: activity on:
Jan 7 20:00:49 stumm slapd[6046]:
Jan 7 20:00:49 stumm slapd[6046]: daemon: select: listen=6 active_threads=0 tvp=NULL
Jan 7 20:00:49 stumm slapd[6046]: daemon: activity on 1 descriptors
Jan 7 20:00:49 stumm slapd[6046]: daemon: activity on:
Jan 7 20:00:49 stumm slapd[6046]: 11r
Jan 7 20:00:49 stumm slapd[6046]:
Jan 7 20:00:49 stumm slapd[6046]: daemon: read activity on 11
Jan 7 20:00:49 stumm slapd[6046]: connection_get(11)
Jan 7 20:00:49 stumm slapd[6046]: connection_get(11): got connid=1
Jan 7 20:00:49 stumm slapd[6046]: connection_read(11): checking for input on id=1
Jan 7 20:00:49 stumm slapd[6046]: ber_get_next on fd 11 failed errno=11 (Resource temporarily unavailable)
Jan 7 20:00:49 stumm slapd[6049]: do_bind
Jan 7 20:00:49 stumm slapd[6046]: daemon: select: listen=6 active_threads=1 tvp=NULL
Jan 7 20:00:49 stumm slapd[6049]: do_bind: version=3 dn="uid=hager,dc=1012surf,dc=net,dc=." method=128
Jan 7 20:00:49 stumm slapd[6049]: conn=1 op=0 BIND dn="UID=HAGER,DC=1012SURF,DC=NET,DC=." method=128
Jan 7 20:00:49 stumm slapd[6049]: ==> ldbm_back_bind: dn: uid=hager,dc=1012surf,dc=net,dc=.
Jan 7 20:00:49 stumm slapd[6049]: dn2entry_r: dn: "UID=HAGER,DC=1012SURF,DC=NET,DC=."
Jan 7 20:00:49 stumm slapd[6049]: => dn2id( "UID=HAGER,DC=1012SURF,DC=NET,DC=." )
Jan 7 20:00:49 stumm slapd[6049]: ====> cache_find_entry_dn2id("UID=HAGER,DC=1012SURF,DC=NET,DC=."): 998 (1 tries)
Jan 7 20:00:49 stumm slapd[6049]: <= dn2id 998 (in cache)
Jan 7 20:00:49 stumm slapd[6049]: => id2entry_r( 998 )
Jan 7 20:00:49 stumm slapd[6049]: entry_rdwr_rtrylock: ID: 998
Jan 7 20:00:49 stumm slapd[6049]: ====> cache_find_entry_id( 998 ) "uid=hager,dc=1012surf,dc=net,dc=." (found) (1 tries)
Jan 7 20:00:49 stumm slapd[6049]: <= id2entry_r( 998 ) 0x80e4bc8 (cache)
Jan 7 20:00:49 stumm slapd[6049]: => access_allowed: auth access to "uid=hager,dc=1012surf,dc=net,dc=." "userPassword" requested
Jan 7 20:00:49 stumm slapd[6049]: => acl_get: [1] check attr userPassword
Jan 7 20:00:49 stumm slapd[6049]: <= acl_get: [1] acl uid=hager,dc=1012surf,dc=net,dc=. attr: userPassword
Jan 7 20:00:49 stumm slapd[6049]: => acl_mask: access to entry "uid=hager,dc=1012surf,dc=net,dc=.", attr "userPassword" requested Jan 7 20:00:49 stumm slapd[6049]: => acl_mask: to all values by "", (=n)
Jan 7 20:00:49 stumm slapd[6049]: <= check a_dn_pat: self
Jan 7 20:00:49 stumm slapd[6049]: <= check a_dn_pat: *
Jan 7 20:00:49 stumm slapd[6049]: <= acl_mask: [2] applying auth (=x) (stop)
Jan 7 20:00:49 stumm slapd[6049]: <= acl_mask: [2] mask: auth (=x)
Jan 7 20:00:49 stumm slapd[6049]: => access_allowed: auth access granted by auth (=x)
Jan 7 20:00:49 stumm slapd[6049]: entry_rdwr_runlock: ID: 998
Jan 7 20:00:49 stumm slapd[6049]: ====> cache_return_entry_r( 998 ): returned (0)
Jan 7 20:00:49 stumm slapd[6049]: do_bind: v3 bind: "uid=hager,dc=1012surf,dc=net,dc=." to "uid=hager,dc=1012surf,dc=net,dc=."
Jan 7 20:00:49 stumm slapd[6049]: send_ldap_result: conn=1 op=0 p=3
Jan 7 20:00:49 stumm slapd[6049]: send_ldap_result: 0::
Jan 7 20:00:49 stumm slapd[6049]: send_ldap_response: msgid=1 tag=97 err=0
Jan 7 20:00:49 stumm slapd[6049]: conn=1 op=0 RESULT tag=97 err=0 text=
Jan 7 20:00:49 stumm slapd[6046]: daemon: activity on 1 descriptors
Jan 7 20:00:49 stumm slapd[6046]: daemon: activity on:
Jan 7 20:00:49 stumm slapd[6046]: 11r
Jan 7 20:00:49 stumm slapd[6046]:
Jan 7 20:00:49 stumm slapd[6046]: daemon: read activity on 11
Jan 7 20:00:49 stumm slapd[6046]: connection_get(11)
Jan 7 20:00:49 stumm slapd[6046]: connection_get(11): got connid=1
Jan 7 20:00:49 stumm slapd[6046]: connection_read(11): checking for input on id=1
Jan 7 20:00:49 stumm slapd[6046]: ber_get_next on fd 11 failed errno=11 (Resource temporarily unavailable)
Jan 7 20:00:49 stumm slapd[6049]: do_extended
Jan 7 20:00:49 stumm slapd[6046]: daemon: select: listen=6 active_threads=1 tvp=NULL
Jan 7 20:00:49 stumm slapd[6049]: do_extended: oid=1.3.6.1.4.1.4203.1.11.1
Jan 7 20:00:49 stumm slapd[6049]: send_ldap_extended 10: (0)
Jan 7 20:00:49 stumm slapd[6049]: send_ldap_response: msgid=2 tag=120 err=10
slapd dies, before sending the LDAP_REFERRAL error code to the client.
a test with openldap-2.0.19 showed the same behaviour.
can anyone verify this behaviour?
note that i do not intend to use ldappasswd that way, i just want to
know whether it's a slapd issue or a bug in my setup ;-)
regards,
tom.
--
Thomas Hager | "Microsoft is not the
answer.
tele.ring / Technical Product Development | Microsoft is the question.
thomas.hager@1012surf.net | NO is the answer."
http://www.telering.at | Erik Naggum.
Attachment:
pgpXqDDGchrTB.pgp
Description: PGP signature