(ITS#6667) memberof infinite recursion on node rename
by miguelangel＠nbee.es
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?
12 years, 11 months
Re: (ITS#6666) Feature Request: Triggers implementation
by nick＠eurobjects.com
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.
>
12 years, 11 months
Re: (ITS#6666) Feature Request: Triggers implementation
by hyc＠symas.com
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/
12 years, 11 months
memberof infinite recursion on node rename
by Miguel Angel
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
12 years, 11 months
Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com
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
12 years, 11 months
(ITS#6666) Feature Request: Triggers implementation
by nick＠eurobjects.com
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.
12 years, 11 months
Re: FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com
--=-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>
<BR>
</BODY>
</HTML>
--=-J3E4Om04oCzTAxqDTGlw--
12 years, 11 months
Re: FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by masarati＠aero.polimi.it
> 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.
12 years, 11 months
