openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#6667) memberof infinite recursion on node rename
by miguelangel＠nbee.es 07 Oct '10

07 Oct '10

Full_Name: Miguel Angel Ajo Pelayo Version: 2.4.23 stable OS: Linux (Centos5) URL: Submission from: (NULL) (95.16.169.142) I detected that my (compiled from source) openldap crashes on node rename. I run gdb and detected an infinite (too big) recursion that seems to be related with the "memberof" overlay. This is the GDB / debug output: >>> dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> <<< dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> bdb_modrdn: new ndn=cn=aaa aaavzadadfa,dc=nbee,dc=es => bdb_dn2id("cn=aaa aaavzadadfa,dc=nbee,dc=es") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) => bdb_dn2id_delete 0x11: "cn=aaa aaavzadadf,dc=nbee,dc=es" <= bdb_dn2id_delete 0x11: 0 => bdb_dn2id_add 0x11: "cn=aaa aaavzadadfa,dc=nbee,dc=es" <= bdb_dn2id_add 0x11: 0 bdb_modify_internal: 0x00000011: cn=aaa aaavzadadfa,dc=nbee,dc=es oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "inetOrgPerson" oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "posixAccount" oc_check_allowed type "givenName" oc_check_allowed type "sn" oc_check_allowed type "gidNumber" oc_check_allowed type "uid" oc_check_allowed type "uidNumber" oc_check_allowed type "userPassword" oc_check_allowed type "loginShell" oc_check_allowed type "homeDirectory" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "cn" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es <= entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es bdb_modrdn: rdn modified id=00000011 dn="cn=aaa aaavzadadf,dc=nbee,dc=es" send_ldap_result: conn=1007 op=2 p=3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb79e7b90 (LWP 11613)] 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 713 db = *op->o_bd; #0 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 #1 0x080eb21c in over_aux_chk_controls (op=0xb79e680c, rs=0xb79e67d0) at backover.c:814 #2 0x0807bc38 in backend_check_restrictions (op=0xb79e680c, rs=0xb79e67d0, opdata=0x0) at backend.c:1036 #3 0x0806e1fa in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:334 #4 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #5 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #6 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #7 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 [.......] A LOT of recursion... #37385 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37386 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37387 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 #37388 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #37389 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37390 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37391 0x08163ee4 in memberof_isGroupOrMember (op=0x8370ce0, mci=0xb6fe4450) at memberof.c:288 ---Type <return> to continue, or q <return> to quit--- #37392 0x0816723b in memberof_res_modrdn (op=0x8370ce0, rs=0xb79e7134) at memberof.c:1451 #37393 0x0807e621 in slap_response_play (op=0x8370ce0, rs=0xb79e7134) at result.c:402 #37394 0x0807e7cc in send_ldap_response (op=0x8370ce0, rs=0xb79e7134) at result.c:476 #37395 0x0807f5a2 in slap_send_ldap_result (op=0x8370ce0, rs=0xb79e7134) at result.c:750 #37396 0x080fbca9 in bdb_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:789 #37397 0x0808bbb0 in fe_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:314 #37398 0x080eae42 in overlay_op_walk (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn, oi=0x8304f40, on=0x0) at backover.c:669 #37399 0x080eaff7 in over_op_func (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn) at backover.c:721 #37400 0x080eb10c in over_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at backover.c:766 #37401 0x0808b513 in do_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:186 #37402 0x0806aed0 in connection_operation (ctx=0xb79e7220, arg_v=0x8370ce0) at connection.c:1109 #37403 0x0806b410 in connection_read_thread (ctx=0xb79e7220, argv=0xe) at connection.c:1245 #37404 0x081b5055 in ldap_int_thread_pool_wrapper (xpool=0x82d9e00) at tpool.c:685 #37405 0x00adf832 in start_thread () from /lib/libpthread.so.0 #37406 0x00220e0e in clone () from /lib/libc.so.6 Any idea of why could this be happening?

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by nick＠eurobjects.com 07 Oct '10

07 Oct '10

Sorry, I' m not a developer. I'm trying to find a solution from an administrator's point of view. How about doing something like: on log attr <attrname> notify <[ip]:[port]> which would send a "message" with the attr name, the old and the new value of the attribute to [ip]:[port]. Then, someone can set up a net listening process like netcat (nc) to read data and do whatever. Nick On 7/10/2010 5:32 πμ, Howard Chu wrote: > > Spawning processes is not thread safe. The solution you propose will > never be implemented. Alternative suggestions are welcome. >

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by hyc＠symas.com 07 Oct '10

07 Oct '10

nick(a)eurobjects.com wrote: > Full_Name: Nick Milas > Version: 2.3.43 > OS: CentOS 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.65.0.240) > > > Triggers in openldap is a much-desired feature. As mentioned in various places, > openldap community suggests using the accesslog overlay to log changes and then > use another process to listen to changes (e.g. back-perl) or back-sock (I saw > the example in the source tree), feasibly back-shell or even write one's own > overlay. The problem is that all those methods require low-level programming > (not to mention various incompatibilities with system components), which makes > them unusable by administrators, that is by those who mainly install and run > openldap and directories. As a result, I would suggest to slightly enhance > future versions by offering minimal trigger support over the accesslog overlay. > > > So I would suggest to support in slapd.conf a statement like: > "on log attr<attribute name> call<bash script>" (with obvious meaning). > > I consider this would allow the openldap average administrator to use particular > attributes as triggers to start scripts which in turn offer the advantage of > full access to script programming, which does not require low-level > programming. > > Spawning processes is not thread safe. The solution you propose will never be implemented. Alternative suggestions are welcome. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

memberof infinite recursion on node rename
by Miguel Angel 07 Oct '10

07 Oct '10

Hi there, I think I found a bug. I detected that my (compiled from source) openldap crashes on node rename. I run gdb and detected an infinite (too big) recursion that seems to be related with the "memberof" overlay. I'm not familiar with openldap sources, so I decided to post it here, and then try to help fixing it with your advice: This is the GDB / debug output: >>> dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> <<< dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> bdb_modrdn: new ndn=cn=aaa aaavzadadfa,dc=nbee,dc=es => bdb_dn2id("cn=aaa aaavzadadfa,dc=nbee,dc=es") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) => bdb_dn2id_delete 0x11: "cn=aaa aaavzadadf,dc=nbee,dc=es" <= bdb_dn2id_delete 0x11: 0 => bdb_dn2id_add 0x11: "cn=aaa aaavzadadfa,dc=nbee,dc=es" <= bdb_dn2id_add 0x11: 0 bdb_modify_internal: 0x00000011: cn=aaa aaavzadadfa,dc=nbee,dc=es oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "inetOrgPerson" oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "posixAccount" oc_check_allowed type "givenName" oc_check_allowed type "sn" oc_check_allowed type "gidNumber" oc_check_allowed type "uid" oc_check_allowed type "uidNumber" oc_check_allowed type "userPassword" oc_check_allowed type "loginShell" oc_check_allowed type "homeDirectory" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "cn" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es <= entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es bdb_modrdn: rdn modified id=00000011 dn="cn=aaa aaavzadadf,dc=nbee,dc=es" send_ldap_result: conn=1007 op=2 p=3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb79e7b90 (LWP 11613)] 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 713 db = *op->o_bd; #0 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 #1 0x080eb21c in over_aux_chk_controls (op=0xb79e680c, rs=0xb79e67d0) at backover.c:814 #2 0x0807bc38 in backend_check_restrictions (op=0xb79e680c, rs=0xb79e67d0, opdata=0x0) at backend.c:1036 #3 0x0806e1fa in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:334 #4 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #5 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #6 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #7 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 [.......] A LOT of recursion... #37385 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37386 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37387 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 #37388 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #37389 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37390 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37391 0x08163ee4 in memberof_isGroupOrMember (op=0x8370ce0, mci=0xb6fe4450) at memberof.c:288 ---Type <return> to continue, or q <return> to quit--- #37392 0x0816723b in memberof_res_modrdn (op=0x8370ce0, rs=0xb79e7134) at memberof.c:1451 #37393 0x0807e621 in slap_response_play (op=0x8370ce0, rs=0xb79e7134) at result.c:402 #37394 0x0807e7cc in send_ldap_response (op=0x8370ce0, rs=0xb79e7134) at result.c:476 #37395 0x0807f5a2 in slap_send_ldap_result (op=0x8370ce0, rs=0xb79e7134) at result.c:750 #37396 0x080fbca9 in bdb_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:789 #37397 0x0808bbb0 in fe_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:314 #37398 0x080eae42 in overlay_op_walk (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn, oi=0x8304f40, on=0x0) at backover.c:669 #37399 0x080eaff7 in over_op_func (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn) at backover.c:721 #37400 0x080eb10c in over_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at backover.c:766 #37401 0x0808b513 in do_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:186 #37402 0x0806aed0 in connection_operation (ctx=0xb79e7220, arg_v=0x8370ce0) at connection.c:1109 #37403 0x0806b410 in connection_read_thread (ctx=0xb79e7220, argv=0xe) at connection.c:1245 #37404 0x081b5055 in ldap_int_thread_pool_wrapper (xpool=0x82d9e00) at tpool.c:685 #37405 0x00adf832 in start_thread () from /lib/libpthread.so.0 #37406 0x00220e0e in clone () from /lib/libc.so.6 Any idea of why could this be happening? Thanks in advance, Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo

2 1

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 06 Oct '10

06 Oct '10

masarati(a)aero.polimi.it wrote: >> Hey Pierangelo, >> >> I just noticed http://www.openldap.org/its/index.cgi?findid=6574 - this >> looks like it fixes the issue I mentioned in >> http://www.openldap.org/its/index.cgi?findid=6540? Is that assertion >> correct? > > I couldn't specifically look at your issue (apart from the simple fix to > allow cn=config to work). ITS#6574 should have nothing to do with your > issue, as it affects back-meta in a part that has no code commonality with > back-ldap, and slapo-chain is built on top of back-ldap. I apologize - it had occurred to me that since http://www.openldap.org/doc/admin24/backends.html#Metadirectory states that back-meta and back-ldap share a subset of code, and since the issue described in ITS#6574 appears to be *exactly* the same problem I'm seeing in ITS#6540, that they might have been one and the same. > I'm sorry I went back through this thread and got somehow lost; what's the > exact topic now? I infer (from followup #14) that there seems to be an > issue about chaining because slapo-chain seems not to rebind as expected. ITS#6540 had two parts: 1. The test script failed to identify a specific set of conditions in which slapo-chain would cause slapcat to fail and also prevent slapd from being restarted after slapo-chain was enabled. 2. The problem that the test script failed to detect with slapo-chain is directly related to the current problem: slapo-chain does not properly rebind as the appropriate user as set in the olcDbIDAssertBind attribute. Instead, it rebinds as 'anonymous' (an empty DN), which is of very little practical use, since unauthenticated anonymous users should not be allowed to modify anything. As a result, slapd kicks the referral back to the client instead of chasing it automatically, which completely defeats the purpose of using slapo-chain. > Could you isolate the problem in a minimal setup (slapd.conf or the > corresponding back-config's LDIF, a database and a simple operation that > can be performed with ldapmodify/ldappasswd or so) to clearly reproduce > the issue? > > Thanks, p. > The configuration and test operations below should show exactly what's going on, but first, allow me to describe the process in a nutshell: 1. The client binds to the slave and issues a modification request 2. The slave creates the referral and tries to chase it automatically on the client's behalf to the upstream master using slapo-chain 3. The automatic referral chasing fails because the DN is not passed through and the slave erroneously rebinds to the master as anonymous (an empty DN) instead of the identity it's configured to assert, as set by the olcDbIDAssertBind attribute. 4. Because the automatic referral chasing fails, the slave kicks back the referral to the client, stating that the client "is not logged in" to the master and that "modifications require authentication". 5. When the client provides credentials for the referral (manual referral chasing), the rest of the operation works as expected (updates made on master, which then cascades to the slaves). The following LDIFs and sample operations exemplify the problem; please let me know if this example suffices, or if you need a more complete reference or further clarification: ################################################# # CONFIGURATION # ################################################# ### back-config base entry on slave (abbreviated) dn: cn=config objectClass: olcGlobal cn: config olcConfigDir: /etc/ldap/slapd.d olcReadOnly: FALSE olcReverseLookup: FALSE olcTLSCACertificateFile: /etc/ldap/ssl/certs/cacert.pem olcTLSCertificateFile: /etc/ldap/ssl/certs/openldap.cert.pem olcTLSCertificateKeyFile: /etc/ldap/ssl/keys/openldap.key.pem olcAuthzPolicy: none olcLogLevel: stats sync olcPasswordHash: {SSHA}SUPERSECRET olcServerID: 1 ldap://master1.example.com olcServerID: 2 ldap://slave1.example.com ### back-config modules entry dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}autogroup.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}back_ldap.la ### back-config chain overlay entry dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain ### back-config chain database dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldap://master1.example.com olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=SECRET mode=self ################################################# # SIMPLE OPERATIONAL EXAMPLE # ################################################# ### NOTE: This example uses ldapvi, but results are identical to ldapmodify, etc. ### NOTE: The client binds initially to the slave as the admin here, but results are identical to scenarios in which the client binds as a regular user ### Attempting to modify 'displayColor' attribute belonging to entry 'uid=ryans,ou=Users,dc=example,dc=com' root@slave1:~# ldapvi -h localhost --bind=simple -D cn=admin,dc=example,dc=com -w `cat /etc/ldap.secret` --discover 159 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Received referral to ldap://master1.example.com/uid=ryans,ou=Users,dc=example,dc=com. You are not logged in to ldap://master1.example.com:389 yet. Type '!' or 'y' to do so. Rebind? [y!nB*qQ?] y --- Login Type M-h for help on key bindings. Filter or DN: cn=admin,dc=example,dc=com Password: *********** Bound as cn=admin,dc=example,dc=com. Done. ################################################# # LOGS FOR OPERATIONAL EXAMPLE # ################################################# ### Logs on slave showing referral was correctly generated (err=10) Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 ACCEPT from IP=127.0.0.1:34118 (IP=0.0.0.0:389) Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 STARTTLS Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 RESULT oid= err=0 text= Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 TLS established tls_ssf=128 ssf=128 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 RESULT tag=97 err=0 text= Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH attr=+ * Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 ENTRY dn="" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="cn=admin,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="ou=users,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="ou=groups,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="uid=ryans,ou=users,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="cn=ryans,ou=groups,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SEARCH RESULT tag=101 err=0 nentries=159 text= Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD attr=displayColor Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 RESULT tag=103 err=10 text= ### Logs on master showing that when the slave tried to chase the referral, it erroneously bound as anonymous ### NOTE: slave1.example.com = 10.0.1.196 Oct 5 10:27:07 master1 slapd[8794]: conn=402475 fd=273 ACCEPT from IP=10.0.1.196:43376 (IP=0.0.0.0:389) Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 BIND dn="" method=128 Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 RESULT tag=97 err=0 text= Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 MOD attr=displayColor Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 RESULT tag=103 err=8 text=modifications require authentication Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=2 UNBIND Oct 5 10:27:08 master1 slapd[8794]: conn=402475 fd=273 closed Oct 5 10:27:08 master1 slapd[8794]: conn=402476 fd=273 ACCEPT from IP=10.0.1.196:43377 (IP=0.0.0.0:389) If there are any details not shown that you'd like, or any clarification you require, or if there's anything at all you need to help facilitate the investigation, please let me know and I'll do my best to accommodate. Thanks! -Ryan

1 0

(ITS#6666) Feature Request: Triggers implementation
by nick＠eurobjects.com 06 Oct '10

06 Oct '10

Full_Name: Nick Milas Version: 2.3.43 OS: CentOS 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.65.0.240) Triggers in openldap is a much-desired feature. As mentioned in various places, openldap community suggests using the accesslog overlay to log changes and then use another process to listen to changes (e.g. back-perl) or back-sock (I saw the example in the source tree), feasibly back-shell or even write one's own overlay. The problem is that all those methods require low-level programming (not to mention various incompatibilities with system components), which makes them unusable by administrators, that is by those who mainly install and run openldap and directories. As a result, I would suggest to slightly enhance future versions by offering minimal trigger support over the accesslog overlay. So I would suggest to support in slapd.conf a statement like: "on log attr <attribute name> call <bash script>" (with obvious meaning). I consider this would allow the openldap average administrator to use particular attributes as triggers to start scripts which in turn offer the advantage of full access to script programming, which does not require low-level programming.

1 0

Re: FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 06 Oct '10

06 Oct '10

--=-J3E4Om04oCzTAxqDTGlw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit > In the meanwhile, you can try to use an instance of back-ldap as the > translucent local storage, and place slapo-rwm on the database of the > remote server that acts as local. I haven't tested it, so there might be > minor issues, but I don't expect anything like this one. Thanks for the input. This is also not an option because the remote server is in fact an Active Directory. Which in this case I can't alter. I will try to create 2 slapd process - One which will do the translucent proxy stuff, running on a non standard port - one which will have a back-ldap to this non standard port and doing there the rewrites. Thanks for helping me with this issue. --=-J3E4Om04oCzTAxqDTGlw Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> <PRE> > In the meanwhile, you can try to use an instance of back-ldap as the > translucent local storage, and place slapo-rwm on the database of the > remote server that acts as local.  I haven't tested it, so there might be > minor issues, but I don't expect anything like this one. Thanks for the input. This is also not an option because the remote server is in fact an Active Directory. Which in this case I can't alter. I will try to create 2 slapd process - One which will do the translucent proxy stuff, running on a non standard port - one which will have a back-ldap to this non standard port and doing there the rewrites. Thanks for helping me with this issue. </PRE> </BODY> </HTML> --=-J3E4Om04oCzTAxqDTGlw--

1 0

Re: FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by masarati＠aero.polimi.it 06 Oct '10

06 Oct '10

> I installed the latest version currently available 2.4.23 > The same bug still exists in this version. > > So I can for sure say this is not related to ITS#6070 > > Since this is a major loss of functionality I would kindly ask someone to > h= > ave a deeper look at this. I confirm it is related to ITS#6070; only, that ITS could be fixed (read: worked around) differently. I don't think this qualifies as a "major loss of functionality" for the vast majority of the users of OpenLDAP. Solving this issue the right way (and few others) would require to advance OpenLDAP at least to 2.5 or 3.0, because a significant portion of the ABI would need to change, so do not expect to see it solved any soon. In the meanwhile, you can try to use an instance of back-ldap as the translucent local storage, and place slapo-rwm on the database of the remote server that acts as local. I haven't tested it, so there might be minor issues, but I don't expect anything like this one. p.

1 0

FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 05 Oct '10

05 Oct '10

I installed the latest version currently available 2.4.23 The same bug still exists in this version. So I can for sure say this is not related to ITS#6070 Since this is a major loss of functionality I would kindly ask someone to h= ave a deeper look at this. Thanks Wouter=

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 05 Oct '10

05 Oct '10

--=-pjbfbkt+SDCV4FzF9Ohv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I'm hitting this bug also in Debian Lenny. Is this bug already fixed? It prevents me from implementing our OpenLDAP server. Thanks Wouter --=-pjbfbkt+SDCV4FzF9Ohv Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> I'm hitting this bug also in Debian Lenny. Is this bug already fixed? It prevents me from implementing our OpenLDAP server. Thanks Wouter </BODY> </HTML> --=-pjbfbkt+SDCV4FzF9Ohv--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs