openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 13 Feb '10

13 Feb '10

Actually, maybe I wasn't totally wrong. There MAY be a bug at work, = just not the one I initially thought .... 1.) Implemented your exact working example on my dev server. Worked. 2.) Implemented same example on my QA server. Worked. 3.) Implemented on a production server. Failed. I then realized the dynlist-attrset was listed as follows: syncrepl params accesslog params dynlist-attrset params I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl = lines (below my indexes for this DB). Example then worked in production. Is THAT a bug? That its behavior changes depending on where it is placed = inside of a given 'database' section? Thanks, sorry to keep bugging you with this .... J=

1 0

(ITS#6473) delta-syncrepl "replicates" entries with unknown schema elements
by quanah＠zimbra.com 13 Feb '10

13 Feb '10

Full_Name: Quanah Gibson-Mount Version: 2.3.43 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) Recent discrepancies on client replica systems that were 100% reproducible showed that when using delta-syncrepl, it is easy to get a master/replica out of sync in the following scenario when using slapd.conf: A) Stop the master B) update the master with a schema that adds an additional attribute C) Start the master D) Modify an existing entry on the master, setting the new attribute with a value The replica will update its database with the event, but ignoring the new attribute and the value set for it, incorrectly updating its CSN. Instead of accepting the replication event, it should stop replication until its schema is updated to match that of the master. Master log of the modification: dn: reqStart=20100213000511.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20100213000511.000002Z reqEnd: 20100213000511.000003Z reqType: modify reqSession: 3 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: cn=config,cn=zimbra reqResult: 0 reqMod: zimbraMailUseDirectBuffers:= FALSE reqMod: entryCSN:= 20100213000511Z#000000#00#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20100213000511Z entryUUID: 328fcc94-ac7f-102e-8753-251cf08bb530 creatorsName: cn=accesslog createTimestamp: 20100213000511Z entryCSN: 20100213000511Z#000000#00#000000 modifiersName: cn=accesslog modifyTimestamp: 20100213000511Z On the replica, we see: ber_scanf fmt ({ml{) ber: ber_dump: buf=0x9f811c0 ptr=0x9f811c3 end=0x9f81375 len=434 0000: 64 82 01 49 04 2c 72 65 71 53 74 61 72 74 3d 32 d..I.,reqStart=2 0010: 30 31 30 30 32 31 33 30 30 30 35 31 31 2e 30 30 0100213000511.00 0020: 30 30 30 32 5a 2c 63 6e 3d 61 63 63 65 73 73 6c 0002Z,cn=accessl 0030: 6f 67 30 82 01 17 30 13 04 07 72 65 71 54 79 70 og0...0...reqTyp 0040: 65 31 08 04 06 6d 6f 64 69 66 79 30 1e 04 05 72 e1...modify0...r 0050: 65 71 44 4e 31 15 04 13 63 6e 3d 63 6f 6e 66 69 eqDN1...cn=confi 0060: 67 2c 63 6e 3d 7a 69 6d 62 72 61 30 81 af 04 06 g,cn=zimbra0.... 0070: 72 65 71 4d 6f 64 31 81 a4 04 22 7a 69 6d 62 72 reqMod1..."zimbr 0080: 61 4d 61 69 6c 55 73 65 44 69 72 65 63 74 42 75 aMailUseDirectBu 0090: 66 66 65 72 73 3a 3d 20 46 41 4c 53 45 04 2b 65 ffers:= FALSE.+e 00a0: 6e 74 72 79 43 53 4e 3a 3d 20 32 30 31 30 30 32 ntryCSN:= 201002 00b0: 31 33 30 30 30 35 31 31 5a 23 30 30 30 30 30 30 13000511Z#000000 00c0: 23 30 30 23 30 30 30 30 30 30 04 2e 6d 6f 64 69 #00#000000..modi 00d0: 66 69 65 72 73 4e 61 6d 65 3a 3d 20 75 69 64 3d fiersName:= uid= 00e0: 7a 69 6d 62 72 61 2c 63 6e 3d 61 64 6d 69 6e 73 zimbra,cn=admins 00f0: 2c 63 6e 3d 7a 69 6d 62 72 61 04 21 6d 6f 64 69 ,cn=zimbra.!modi 0100: 66 79 54 69 6d 65 73 74 61 6d 70 3a 3d 20 32 30 fyTimestamp:= 20 0110: 31 30 30 32 31 33 30 30 30 35 31 31 5a 30 2e 04 100213000511Z0.. 0120: 08 65 6e 74 72 79 43 53 4e 31 22 04 20 32 30 31 .entryCSN1". 201 0130: 30 30 32 31 33 30 30 30 35 31 31 5a 23 30 30 30 00213000511Z#000 0140: 30 30 30 23 30 30 23 30 30 30 30 30 30 a0 63 30 000#00#000000.c0 0150: 61 04 18 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 a..1.3.6.1.4.1.4 0160: 32 30 33 2e 31 2e 39 2e 31 2e 32 04 45 30 43 0a 203.1.9.1.2.E0C. 0170: 01 01 04 10 32 8f cc 94 ac 7f 10 2e 87 53 25 1c ....2........S%. 0180: f0 8b b5 30 04 2c 63 73 6e 3d 32 30 31 30 30 32 ...0.,csn=201002 0190: 31 33 30 30 30 35 31 31 5a 23 30 30 30 30 30 30 13000511Z#000000 01a0: 23 30 30 23 30 30 30 30 30 30 2c 72 69 64 3d 31 #00#000000,rid=1 01b0: 30 30 00 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x9f811c0 ptr=0x9f811f9 end=0x9f81310 len=279 0000: 30 13 04 07 72 65 71 54 79 70 65 31 08 04 06 6d 0...reqType1...m 0010: 6f 64 69 66 79 30 1e 04 05 72 65 71 44 4e 31 15 odify0...reqDN1. 0020: 04 13 63 6e 3d 63 6f 6e 66 69 67 2c 63 6e 3d 7a ..cn=config,cn=z 0030: 69 6d 62 72 61 30 81 af 04 06 72 65 71 4d 6f 64 imbra0....reqMod 0040: 31 81 a4 04 22 7a 69 6d 62 72 61 4d 61 69 6c 55 1..."zimbraMailU 0050: 73 65 44 69 72 65 63 74 42 75 66 66 65 72 73 3a seDirectBuffers: 0060: 3d 20 46 41 4c 53 45 04 2b 65 6e 74 72 79 43 53 = FALSE.+entryCS 0070: 4e 3a 3d 20 32 30 31 30 30 32 31 33 30 30 30 35 N:= 201002130005 0080: 31 31 5a 23 30 30 30 30 30 30 23 30 30 23 30 30 11Z#000000#00#00 0090: 30 30 30 30 04 2e 6d 6f 64 69 66 69 65 72 73 4e 0000..modifiersN 00a0: 61 6d 65 3a 3d 20 75 69 64 3d 7a 69 6d 62 72 61 ame:= uid=zimbra 00b0: 2c 63 6e 3d 61 64 6d 69 6e 73 2c 63 6e 3d 7a 69 ,cn=admins,cn=zi 00c0: 6d 62 72 61 04 21 6d 6f 64 69 66 79 54 69 6d 65 mbra.!modifyTime 00d0: 73 74 61 6d 70 3a 3d 20 32 30 31 30 30 32 31 33 stamp:= 20100213 00e0: 30 30 30 35 31 31 5a 30 2e 04 08 65 6e 74 72 79 000511Z0...entry 00f0: 43 53 4e 31 22 04 20 32 30 31 30 30 32 31 33 30 CSN1". 201002130 0100: 30 30 35 31 31 5a 23 30 30 30 30 30 30 23 30 30 00511Z#000000#00 0110: 23 30 30 30 30 30 30 #000000 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x9f811c0 ptr=0x9f8120e end=0x9f81310 len=258 0000: 00 1e 04 05 72 65 71 44 4e 31 15 04 13 63 6e 3d ....reqDN1...cn= 0010: 63 6f 6e 66 69 67 2c 63 6e 3d 7a 69 6d 62 72 61 config,cn=zimbra 0020: 30 81 af 04 06 72 65 71 4d 6f 64 31 81 a4 04 22 0....reqMod1..." 0030: 7a 69 6d 62 72 61 4d 61 69 6c 55 73 65 44 69 72 zimbraMailUseDir 0040: 65 63 74 42 75 66 66 65 72 73 3a 3d 20 46 41 4c ectBuffers:= FAL 0050: 53 45 04 2b 65 6e 74 72 79 43 53 4e 3a 3d 20 32 SE.+entryCSN:= 2 0060: 30 31 30 30 32 31 33 30 30 30 35 31 31 5a 23 30 0100213000511Z#0 0070: 30 30 30 30 30 23 30 30 23 30 30 30 30 30 30 04 00000#00#000000. 0080: 2e 6d 6f 64 69 66 69 65 72 73 4e 61 6d 65 3a 3d .modifiersName:= 0090: 20 75 69 64 3d 7a 69 6d 62 72 61 2c 63 6e 3d 61 uid=zimbra,cn=a 00a0: 64 6d 69 6e 73 2c 63 6e 3d 7a 69 6d 62 72 61 04 dmins,cn=zimbra. 00b0: 21 6d 6f 64 69 66 79 54 69 6d 65 73 74 61 6d 70 !modifyTimestamp 00c0: 3a 3d 20 32 30 31 30 30 32 31 33 30 30 30 35 31 := 2010021300051 00d0: 31 5a 30 2e 04 08 65 6e 74 72 79 43 53 4e 31 22 1Z0...entryCSN1" 00e0: 04 20 32 30 31 30 30 32 31 33 30 30 30 35 31 31 . 20100213000511 00f0: 5a 23 30 30 30 30 30 30 23 30 30 23 30 30 30 30 Z#000000#00#0000 0100: 30 30 00 >>> dnPrettyNormal: <cn=config,cn=zimbra> => ldap_bv2dn(cn=config,cn=zimbra,0) <= ldap_bv2dn(cn=config,cn=zimbra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config,cn=zimbra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config,cn=zimbra)=0 <<< dnPrettyNormal: <cn=config,cn=zimbra>, <cn=config,cn=zimbra> ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x9f811c0 ptr=0x9f8122e end=0x9f81310 len=226 0000: 00 81 af 04 06 72 65 71 4d 6f 64 31 81 a4 04 22 .....reqMod1..." 0010: 7a 69 6d 62 72 61 4d 61 69 6c 55 73 65 44 69 72 zimbraMailUseDir 0020: 65 63 74 42 75 66 66 65 72 73 3a 3d 20 46 41 4c ectBuffers:= FAL 0030: 53 45 04 2b 65 6e 74 72 79 43 53 4e 3a 3d 20 32 SE.+entryCSN:= 2 0040: 30 31 30 30 32 31 33 30 30 30 35 31 31 5a 23 30 0100213000511Z#0 0050: 30 30 30 30 30 23 30 30 23 30 30 30 30 30 30 04 00000#00#000000. 0060: 2e 6d 6f 64 69 66 69 65 72 73 4e 61 6d 65 3a 3d .modifiersName:= 0070: 20 75 69 64 3d 7a 69 6d 62 72 61 2c 63 6e 3d 61 uid=zimbra,cn=a 0080: 64 6d 69 6e 73 2c 63 6e 3d 7a 69 6d 62 72 61 04 dmins,cn=zimbra. 0090: 21 6d 6f 64 69 66 79 54 69 6d 65 73 74 61 6d 70 !modifyTimestamp 00a0: 3a 3d 20 32 30 31 30 30 32 31 33 30 30 30 35 31 := 2010021300051 00b0: 31 5a 30 2e 04 08 65 6e 74 72 79 43 53 4e 31 22 1Z0...entryCSN1" 00c0: 04 20 32 30 31 30 30 32 31 33 30 30 30 35 31 31 . 20100213000511 00d0: 5a 23 30 30 30 30 30 30 23 30 30 23 30 30 30 30 Z#000000#00#0000 00e0: 30 30 00 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x9f811c0 ptr=0x9f812e0 end=0x9f81310 len=48 0000: 00 2e 04 08 65 6e 74 72 79 43 53 4e 31 22 04 20 ....entryCSN1". 0010: 32 30 31 30 30 32 31 33 30 30 30 35 31 31 5a 23 20100213000511Z# 0020: 30 30 30 30 30 30 23 30 30 23 30 30 30 30 30 30 000000#00#000000 ldap_get_attribute_ber >>> dnPretty: <uid=zimbra,cn=admins,cn=zimbra> => ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra,0) <= ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=zimbra,cn=admins,cn=zimbra)=0 <<< dnPretty: <uid=zimbra,cn=admins,cn=zimbra> >>> dnNormalize: <uid=zimbra,cn=admins,cn=zimbra> => ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra,0) <= ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=zimbra,cn=admins,cn=zimbra)=0 <<< dnNormalize: <uid=zimbra,cn=admins,cn=zimbra> bdb_modify: cn=config,cn=zimbra bdb_dn2entry("cn=config,cn=zimbra") bdb_modify_internal: 0x0000000c: cn=config,cn=zimbra <= acl_access_allowed: granted to database root bdb_modify_internal: replace entryCSN bdb_modify_internal: replace modifiersName bdb_modify_internal: replace modifyTimestamp => key_change(DELETE,c) bdb_idl_delete_key: c <= key_change 0 => key_change(ADD,c) bdb_idl_insert_key: c <= key_change 0 => entry_encode(0x0000000c): cn=config,cn=zimbra bdb_modify: updated id=0000000c dn="cn=config,cn=zimbra" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" syncrepl_message_to_op: rid 100 be_modify cn=config,cn=zimbra (0) bdb_modify: bdb_dn2entry("") bdb_modify_internal: 0x00000000: <= acl_access_allowed: granted to database root bdb_modify_internal: replace contextCSN => entry_encode(0x00000000): bdb_modify: updated id=00000000 dn="" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" ldap_msgfree As you can see, the replica *clearly* sees the attribute in question, but fails to throw an error, and simply updates the database with all of the other changes (entryCSN, etc) then updates the contextCSN.

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 12 Feb '10

12 Feb '10

> Isn't this what you expect? >=20 That is EXACTLY what I expect. But all hits either come back in POSIX = format (e.g: just the usernames alone), OR LDAP format (e.g: DNs as = members). Never BOTH (like in your example, which is what we want). So, yes, your TEST is correct. However I am seeing something very = different on my end. Clearly I am doing something wrong. Either: 1.) A syntax error somewhere in my URI syntax, or 2.) A syntax error somewhere in the dynlist overlay area in my = slapd.conf > It represents the objectClass that, when present in an entry that is = being > returned by a search, triggers the dynlist expansion. >=20 That TOO is what I interpreted from both the examples and the manpage. So you have answered my question: 1.) Is not a bug 2.) What I am trying to do is perfectly valid 3.) I am the problem - I am doing something wrong =3D) Thank you Pierangelo, as always you're extremely helpful. J > p. >=20

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 12 Feb '10

12 Feb '10

> Pierangelo,=20 > > Thanks for responding. Here are some hopefully helpful answers: > > We have an Openfire (Java-based XMPP server, supporting ldap user/group = > lookups) server that will, when deployed, have thousands of users. = > Openfire works quite well with openldap, however we wanted to avoid = > manually maintaining the group objects since (as I said) they would be = > highly populated. > > Openfire supports two types of groups (in their terms): posix and = > non-posix. Basically what this means is that when in posix mode, = > Openfire looks for groups (e.g: cn=3Dusers) that contain UID-like = > objects (single username strings). When in NON-POSIX mode, however, = > Openfire will look for groups that contain DN-based members. =20 > > The member Attribute names (e.g: memberUid, uniqueMember, etc) are fully = > configurable to openfire, but we had limited success when trying = > different permutations. Some attribute-mappings work, some do not. = > Eventually, we found that the following works for Openfire: > > overlay dynlist > dynlist-attrset groupOfURLs memberURL memberUid > > With this record being returned when queried: > > dn: cn=3Dusers,cn=3Dgroups,dc=3Dexample,dc=3Dcom > cn: users > memberURL: = > ldap:///cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D= > simpleSecurityObject) > objectClass: groupOfURLs > memberUid: > uid=3Dopenfire-admin,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom= > > memberUid: uid=3Duser1,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser2,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser3,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser4,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser5,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser6,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser7,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser8,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser9,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > > I know this doesn't look right (obviously memberUid is not typically a = > DN-based value) BUT THIS WORKS FOR OPENFIRE (which in the end, will be = > the only client that makes use of this record). We'd prefer to use = > DN-based member groups (e.g: this would be "Non-Posix" groups to = > openfire) since this is the only method that works with Openfire. > > HOWEVER on the other side of the situation, we want to begin using = > Dynamic Posix Groups, like so: > > overlay dynlist > dynlist-attrset posixGroup memberURL memberUid:uid > > With this record being returned when queried: > > dn: cn=3Dadmins,cn=3Dposix,cn=3Dgroups,dc=3Dexample,dc=3Dcom > objectClass: posixGroup > objectClass: top > objectClass: extensibleObject > cn: systems > gidNumber: 9001 > memberURL: = > ldap:///cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D= > adminUser) > memberUid: admin1 > memberUid: admin2 > memberUid: admin3 > memberUid: admin4 > memberUid: admin5 > > .... Which works wonderfully! Using shell commands like 'id' , 'groups' = > will work quite nicely on the posix/shell level. > > But all goes to crap when combining the above dynlist-attrsets. As I = > said, only one seems to be evaluated. I'm afraid I don't quite understand. 1) I manually ran test003 2) I configured slapd with overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid dynlist-attrset posixGroup memberURL memberUid:uid 3) I loaded the LDIF dn: ou=dynlist,dc=example,dc=com objectClass: organizationalUnit dn: cn=dl1,ou=dynlist,dc=example,dc=com objectClass: groupOfURLs memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) dn: cn=dl2,ou=dynlist,dc=example,dc=com objectClass: posixGroup objectClass: extensibleObject memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) gidNumber: 0 4) when I execute $ ldapsearch -x -b ou=dynlist,dc=example,dc=com I get # extended LDIF # # LDAPv3 # base <ou=dynlist,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # dynlist, example.com dn: ou=dynlist,dc=example,dc=com objectClass: organizationalUnit ou: dynlist # dl1, dynlist, example.com dn: cn=dl1,ou=dynlist,dc=example,dc=com objectClass: groupOfURLs memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) cn: dl1 memberUid: cn=Barbara Jensen,ou=Information Technology Division,ou=People, dc=example,dc=com memberUid: cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc =example,dc=com memberUid: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,d c=com memberUid: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,d c=com memberUid: cn=James A Jones 2,ou=Information Technology Division,ou=People ,dc=example,dc=com memberUid: cn=Jane Doe,ou=Alumni Association,ou=People,dc=example,dc=com memberUid: cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc =com memberUid: cn=John Doe,ou=Information Technology Division,ou=People,dc=exa mple,dc=com memberUid: cn=Manager,dc=example,dc=com memberUid: cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=co m memberUid: cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,d c=com # dl2, dynlist, example.com dn: cn=dl2,ou=dynlist,dc=example,dc=com objectClass: posixGroup objectClass: extensibleObject memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) gidNumber: 0 cn: dl2 memberUid: bjensen memberUid: bjorn memberUid: dots memberUid: jaj memberUid: jjones memberUid: jdoe memberUid: jen memberUid: johnd memberUid: melliot memberUid: uham # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 Isn't this what you expect? > I have tried incorporating the = > optional URI parameter into the dynlist-attrsets, but this totally broke = > the groups altogether (didn't expand at all). > > I guess I don't understand what role the first ObjectClass listed in the = > dynlist-attrset parameter plays - i assumed it would act appropriately = > for objects that are using the same OC that is listed in the rule. It represents the objectClass that, when present in an entry that is being returned by a search, triggers the dynlist expansion. p.

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 12 Feb '10

12 Feb '10

--0-1804724661-1266012508=:41453 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On point to note, i have the same situation as here : http://www.openldap.o= rg/lists/openldap-technical/200912/msg00007.html --- On Fri, 2/12/10, alin vasile <alinachegalati(a)yahoo.com> wrote: From: alin vasile <alinachegalati(a)yahoo.com> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: linamat(a)telco.md Cc: openldap-its(a)OpenLDAP.org Date: Friday, February 12, 2010, 1:56 PM looping openldap group --- On Fri, 2/12/10, alin vasile <alinachegalati(a)yahoo.com> wrote: From: alin vasile <alinachegalati(a)yahoo.com> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: linamat(a)telco.md Date: Friday, February 12, 2010, 1:55 PM Hi Serghei, =A0 =A0=A0=A0=A0 For the first point, the function ldap_msgfree=A0 will check f= or NULL, so if the check is missing, no error occurs. =A0 =A0=A0=A0 I am using the ldap_search_ext_s function (the synchronous one) s= o the second and third point doesn't apply as i don't have access to the ms= gid. If the memory leak is high maybe will switch to the async queries. =A0 Regards, Alin =A0 =A0=A0=20 =A0=A0=A0=20 --- On Fri, 2/12/10, linamat(a)telco.md <linamat(a)telco.md> wrote: From: linamat(a)telco.md <linamat(a)telco.md> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: openldap-its(a)OpenLDAP.org Cc: alinachegalati(a)yahoo.com Date: Friday, February 12, 2010, 1:34 PM Buna ziua, domnule. 1. The pointer must be checked before operation, e.g. if (res !=3D NULL) { =A0 =A0 ldap_msgfree (res); =A0 =A0 res =3D NULL; } 2. Also while processing the ext query, you should call the functions in the following manner: 2.1 ldap_search_ext() which has pointer to msgid 2.2 ldap_result() which gives the LDAPMessage structure for the msgid 2.3 if ok - ldap_parse_result() 2.4 on any stage if something is not good and you have the msgid filled with value (integer, typicaly more then 1) you should call ldap_abandon_ext() for that msgid 2.5 Finish with ldap_msgfree() 3. Periodically between the asynchronous searches (after 100 for example)you should call ldap_result() with short timer and LDAP_RES_ANY argue for clearing stalled or nonfreed calls. The obtained LDAPMessage can be freed with ldap_msgfree(). Of course, you can count the asynch calls which hadn't been completed or were timed out and you can make the corresponding cycle for checking all iterations. Please try and let me know. With respect, Serghei. =0A=0A=0A --0-1804724661-1266012508=:41453 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">On point to note, i have the same situation a= s here : <A href=3D"http://www.openldap.org/lists/openldap-technical/200912= /msg00007.html">http://www.openldap.org/lists/openldap-technical/200912/msg= 00007.html</A><BR><BR>--- On <B>Fri, 2/12/10, alin vasile <I><alinachega= lati(a)yahoo.com></I></B> wrote:<BR> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: alin vasile <alinachegalati(a)yahoo.com&gt= ;<BR>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: li= namat(a)telco.md<BR>Cc: openldap-its(a)OpenLDAP.org<BR>Date: Friday, February 1= 2, 2010, 1:56 PM<BR><BR> <DIV id=3Dyiv1659718545> <TABLE border=3D0 cellSpacing=3D0 cellPadding=3D0> <TBODY> <TR> <TD vAlign=3Dtop>looping openldap group<BR><BR>--- On <B>Fri, 2/12/10, alin= vasile <I><alinachegalati(a)yahoo.com></I></B> wrote:<BR> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: alin vasile <alinachegalati(a)yahoo.com&gt= ;<BR>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: li= namat(a)telco.md<BR>Date: Friday, February 12, 2010, 1:55 PM<BR><BR> <DIV id=3Dyiv1668921465> <TABLE border=3D0 cellSpacing=3D0 cellPadding=3D0> <TBODY> <TR> <TD vAlign=3Dtop> <DIV>Hi Serghei,</DIV> <DIV> </DIV> <DIV>     For the first point, the function ldap_msgfre= e  will check for NULL, so if the check is missing, no error occurs.</= DIV> <DIV> </DIV> <DIV>    I am using the ldap_search_ext_s function (the sync= hronous one) so the second and third point doesn't apply as i don't have ac= cess to the msgid. If the memory leak is high maybe will switch to the asyn= c queries.</DIV> <DIV> </DIV> <DIV>Regards,</DIV> <DIV>Alin</DIV> <DIV> </DIV> <DIV>   </DIV> <DIV>    <BR><BR>--- On <B>Fri, 2/12/10, linamat(a)telco.md <I= ><linamat(a)telco.md></I></B> wrote:<BR></DIV> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: linamat(a)telco.md <linamat(a)telco.md><B= R>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: openl= dap-its(a)OpenLDAP.org<BR>Cc: alinachegalati(a)yahoo.com<BR>Date: Friday, Febru= ary 12, 2010, 1:34 PM<BR><BR> <DIV class=3DplainMail>Buna ziua, domnule.<BR><BR>1. The pointer must be ch= ecked before operation, e.g.<BR>if (res !=3D NULL) {<BR>    ldap_= msgfree (res);<BR>    res =3D NULL;<BR>}<BR><BR>2. Also while pro= cessing the ext query, you should call the functions in<BR>the following ma= nner:<BR>2.1 ldap_search_ext() which has pointer to msgid<BR>2.2 ldap_resul= t() which gives the LDAPMessage structure for the msgid<BR>2.3 if ok - ldap= _parse_result()<BR>2.4 on any stage if something is not good and you have t= he msgid filled<BR>with value (integer, typicaly more then 1) you should ca= ll<BR>ldap_abandon_ext() for that msgid<BR>2.5 Finish with ldap_msgfree()<B= R><BR>3. Periodically between the asynchronous searches (after 100 for<BR>e= xample)you should call ldap_result() with short timer and LDAP_RES_ANY<BR>a= rgue for clearing stalled or nonfreed calls. The obtained LDAPMessage can<B= R>be freed with ldap_msgfree(). Of course, you can count the asynch calls<BR>which hadn't been completed or were timed out and you can make th= e<BR>corresponding cycle for checking all iterations.<BR><BR>Please try and= let me know.<BR><BR>With respect, Serghei.<BR><BR></DIV></BLOCKQUOTE></TD>= </TR></TBODY></TABLE><BR></DIV></BLOCKQUOTE></TD></TR></TBODY></TABLE><BR><= /DIV></BLOCKQUOTE></td></tr></table><br>=0A=0A=0A=0A --0-1804724661-1266012508=:41453--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 12 Feb '10

12 Feb '10

--0-1659389023-1266011766=:33437 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable looping openldap group --- On Fri, 2/12/10, alin vasile <alinachegalati(a)yahoo.com> wrote: From: alin vasile <alinachegalati(a)yahoo.com> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: linamat(a)telco.md Date: Friday, February 12, 2010, 1:55 PM Hi Serghei, =A0 =A0=A0=A0=A0 For the first point, the function ldap_msgfree=A0 will check f= or NULL, so if the check is missing, no error occurs. =A0 =A0=A0=A0 I am using the ldap_search_ext_s function (the synchronous one) s= o the second and third point doesn't apply as i don't have access to the ms= gid. If the memory leak is high maybe will switch to the async queries. =A0 Regards, Alin =A0 =A0=A0=20 =A0=A0=A0=20 --- On Fri, 2/12/10, linamat(a)telco.md <linamat(a)telco.md> wrote: From: linamat(a)telco.md <linamat(a)telco.md> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: openldap-its(a)OpenLDAP.org Cc: alinachegalati(a)yahoo.com Date: Friday, February 12, 2010, 1:34 PM Buna ziua, domnule. 1. The pointer must be checked before operation, e.g. if (res !=3D NULL) { =A0 =A0 ldap_msgfree (res); =A0 =A0 res =3D NULL; } 2. Also while processing the ext query, you should call the functions in the following manner: 2.1 ldap_search_ext() which has pointer to msgid 2.2 ldap_result() which gives the LDAPMessage structure for the msgid 2.3 if ok - ldap_parse_result() 2.4 on any stage if something is not good and you have the msgid filled with value (integer, typicaly more then 1) you should call ldap_abandon_ext() for that msgid 2.5 Finish with ldap_msgfree() 3. Periodically between the asynchronous searches (after 100 for example)you should call ldap_result() with short timer and LDAP_RES_ANY argue for clearing stalled or nonfreed calls. The obtained LDAPMessage can be freed with ldap_msgfree(). Of course, you can count the asynch calls which hadn't been completed or were timed out and you can make the corresponding cycle for checking all iterations. Please try and let me know. With respect, Serghei. =0A=0A=0A --0-1659389023-1266011766=:33437 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">looping openldap group<BR><BR>--- On <B>Fri, = 2/12/10, alin vasile <I><alinachegalati(a)yahoo.com></I></B> wrote:<BR> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: alin vasile <alinachegalati(a)yahoo.com&gt= ;<BR>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: li= namat(a)telco.md<BR>Date: Friday, February 12, 2010, 1:55 PM<BR><BR> <DIV id=3Dyiv1668921465> <TABLE border=3D0 cellSpacing=3D0 cellPadding=3D0> <TBODY> <TR> <TD vAlign=3Dtop> <DIV>Hi Serghei,</DIV> <DIV> </DIV> <DIV>     For the first point, the function ldap_msgfre= e  will check for NULL, so if the check is missing, no error occurs.</= DIV> <DIV> </DIV> <DIV>    I am using the ldap_search_ext_s function (the sync= hronous one) so the second and third point doesn't apply as i don't have ac= cess to the msgid. If the memory leak is high maybe will switch to the asyn= c queries.</DIV> <DIV> </DIV> <DIV>Regards,</DIV> <DIV>Alin</DIV> <DIV> </DIV> <DIV>   </DIV> <DIV>    <BR><BR>--- On <B>Fri, 2/12/10, linamat(a)telco.md <I= ><linamat(a)telco.md></I></B> wrote:<BR></DIV> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: linamat(a)telco.md <linamat(a)telco.md><B= R>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: openl= dap-its(a)OpenLDAP.org<BR>Cc: alinachegalati(a)yahoo.com<BR>Date: Friday, Febru= ary 12, 2010, 1:34 PM<BR><BR> <DIV class=3DplainMail>Buna ziua, domnule.<BR><BR>1. The pointer must be ch= ecked before operation, e.g.<BR>if (res !=3D NULL) {<BR>    ldap_= msgfree (res);<BR>    res =3D NULL;<BR>}<BR><BR>2. Also while pro= cessing the ext query, you should call the functions in<BR>the following ma= nner:<BR>2.1 ldap_search_ext() which has pointer to msgid<BR>2.2 ldap_resul= t() which gives the LDAPMessage structure for the msgid<BR>2.3 if ok - ldap= _parse_result()<BR>2.4 on any stage if something is not good and you have t= he msgid filled<BR>with value (integer, typicaly more then 1) you should ca= ll<BR>ldap_abandon_ext() for that msgid<BR>2.5 Finish with ldap_msgfree()<B= R><BR>3. Periodically between the asynchronous searches (after 100 for<BR>e= xample)you should call ldap_result() with short timer and LDAP_RES_ANY<BR>a= rgue for clearing stalled or nonfreed calls. The obtained LDAPMessage can<B= R>be freed with ldap_msgfree(). Of course, you can count the asynch calls<BR>which hadn't been completed or were timed out and you can make th= e<BR>corresponding cycle for checking all iterations.<BR><BR>Please try and= let me know.<BR><BR>With respect, Serghei.<BR><BR></DIV></BLOCKQUOTE></TD>= </TR></TBODY></TABLE><BR></DIV></BLOCKQUOTE></td></tr></table><br>=0A=0A = --0-1659389023-1266011766=:33437--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by linamat＠telco.md 12 Feb '10

12 Feb '10

Buna ziua, domnule. 1. The pointer must be checked before operation, e.g. if (res != NULL) { ldap_msgfree (res); res = NULL; } 2. Also while processing the ext query, you should call the functions in the following manner: 2.1 ldap_search_ext() which has pointer to msgid 2.2 ldap_result() which gives the LDAPMessage structure for the msgid 2.3 if ok - ldap_parse_result() 2.4 on any stage if something is not good and you have the msgid filled with value (integer, typicaly more then 1) you should call ldap_abandon_ext() for that msgid 2.5 Finish with ldap_msgfree() 3. Periodically between the asynchronous searches (after 100 for example)you should call ldap_result() with short timer and LDAP_RES_ANY argue for clearing stalled or nonfreed calls. The obtained LDAPMessage can be freed with ldap_msgfree(). Of course, you can count the asynch calls which hadn't been completed or were timed out and you can make the corresponding cycle for checking all iterations. Please try and let me know. With respect, Serghei.

1 0

Re: (ITS#6456) Feature Request
by j＠gropefruit.com 12 Feb '10

12 Feb '10

... bump .... I would like *some* kind of acknowledgment of this ticket. Is this a = good idea? Bad idea? Any response whatsoever?=

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 12 Feb '10

12 Feb '10

Pierangelo,=20 Thanks for responding. Here are some hopefully helpful answers: We have an Openfire (Java-based XMPP server, supporting ldap user/group = lookups) server that will, when deployed, have thousands of users. = Openfire works quite well with openldap, however we wanted to avoid = manually maintaining the group objects since (as I said) they would be = highly populated. Openfire supports two types of groups (in their terms): posix and = non-posix. Basically what this means is that when in posix mode, = Openfire looks for groups (e.g: cn=3Dusers) that contain UID-like = objects (single username strings). When in NON-POSIX mode, however, = Openfire will look for groups that contain DN-based members. =20 The member Attribute names (e.g: memberUid, uniqueMember, etc) are fully = configurable to openfire, but we had limited success when trying = different permutations. Some attribute-mappings work, some do not. = Eventually, we found that the following works for Openfire: overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid With this record being returned when queried: dn: cn=3Dusers,cn=3Dgroups,dc=3Dexample,dc=3Dcom cn: users memberURL: = ldap:///cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D= simpleSecurityObject) objectClass: groupOfURLs memberUid: uid=3Dopenfire-admin,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom= memberUid: uid=3Duser1,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser2,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser3,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser4,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser5,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser6,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser7,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser8,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser9,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom I know this doesn't look right (obviously memberUid is not typically a = DN-based value) BUT THIS WORKS FOR OPENFIRE (which in the end, will be = the only client that makes use of this record). We'd prefer to use = DN-based member groups (e.g: this would be "Non-Posix" groups to = openfire) since this is the only method that works with Openfire. HOWEVER on the other side of the situation, we want to begin using = Dynamic Posix Groups, like so: overlay dynlist dynlist-attrset posixGroup memberURL memberUid:uid With this record being returned when queried: dn: cn=3Dadmins,cn=3Dposix,cn=3Dgroups,dc=3Dexample,dc=3Dcom objectClass: posixGroup objectClass: top objectClass: extensibleObject cn: systems gidNumber: 9001 memberURL: = ldap:///cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D= adminUser) memberUid: admin1 memberUid: admin2 memberUid: admin3 memberUid: admin4 memberUid: admin5 .... Which works wonderfully! Using shell commands like 'id' , 'groups' = will work quite nicely on the posix/shell level. But all goes to crap when combining the above dynlist-attrsets. As I = said, only one seems to be evaluated. I have tried incorporating the = optional URI parameter into the dynlist-attrsets, but this totally broke = the groups altogether (didn't expand at all). I guess I don't understand what role the first ObjectClass listed in the = dynlist-attrset parameter plays - i assumed it would act appropriately = for objects that are using the same OC that is listed in the rule. Hope this clarifies the situation for you. Thanks again for your time = ...... J=

1 0

(ITS#6472) Syncrepl : loop problem with moddn on a new node
by julien.combes＠i-carre.net 12 Feb '10

12 Feb '10

Full_Name: Julien COMBES Version: 2.4.21 OS: Debian 5.0.4 URL: ftp://ftp.openldap.org/incoming/its-syncrepl-loop-moddn.tar.bz2 Submission from: (NULL) (212.23.175.185) Hello, I think I have found a loop problem with syncrepl replication with openldap 2.4.21, BDB 4.7.25 with all patches and hdb database. The problem appears sometimes when an entry is moved with "modrdbn -s" in a node which has just been created. I have reproduced the problem with the creation of a node and a moddn while the consumer was stopped and then restarted after. The problem follows these steps : - When it starts, the consumer does a request objectClass=* on the provider : Feb 12 09:09:19 ldapma24-ida01 slapd[30445]: conn=1007 op=1 SRCH base="dc=my,dc=domain" scope=2 deref=0 filter="(objectClass=*)" - The consumer finds the modrdn and tries to do this : Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: ==>hdb_modrdn(cn=user1,ou=A,dc=my,dc=domain,cn=user1,ou=X,dc=my,dc=domain) - The consumer fails with these errors : Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: => hdb_dn2id("ou=x,dc=my,dc=domain") Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: hdb_modrdn: newSup(ndn=ou=x,dc=my,dc=domain) not here! Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: conn=-1 op=0 p=0 Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: err=32 matched="" text="new superior not found" - The consumer retries the request objectClass=* on the provider and loops on the problem. The replication doesn't work anymore. To reproduce the problem, I have used these steps : - start an empty provider - ldapadd the entries in mydomain.ldif ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f mydomain.ldif - start the consumer. - stop the consumer when replication is finished - ldapadd the new node ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f add.ldif - modrdn -s ldapmodrdn -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -r -s "ou=X,dc=my,dc=domain" "cn=user1,ou=A,dc=my,dc=domain" "cn=user1" - start the consumer I join in its-syncrepl-loop-moddn.tar.bz2 : - slapd.conf of provider and consummer - log files of provider and consummer - mydomain.ldif and add.ldif regards,

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