openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

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

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

12 Feb '10

> While using the dynlist.la overlay, I found that it is only observing the > bottom-most dynlist-attrset statement. > > For example: > > dynlist-attrset groupOfURLs memberURL <--- ignored > dynlist-attrset posixGroup memberURL memberUid:uid <--- observed > > Individually (one at a time) each one of these statements does exactly > what we > need. When combined, however, all dynamic groups are indiscriminately > expanded > using one attrset "method". In the above example, all dynamic groups are > expanded to the simple UID field (like a posix group). The groupOfURLs > attrset > rule (what would normally generate simple DN-member groups) is completely > ignored. Not quite sure what you're trying to accomplish; could you send an LDIF excerpt of your dynamic groups (significantly the memberURL values), a description of what you expect and an example of what you get? > I've read the manpage, and although I don't see anything that says only > one will > be observed, I wanted to check with someone here to make sure this isn't a > bug. > If it isn't a bug, rather a feature, perhaps this topic should be expanded > in > the next manpage revision. p.

1 0

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

11 Feb '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) While using the dynlist.la overlay, I found that it is only observing the bottom-most dynlist-attrset statement. For example: dynlist-attrset groupOfURLs memberURL <--- ignored dynlist-attrset posixGroup memberURL memberUid:uid <--- observed Individually (one at a time) each one of these statements does exactly what we need. When combined, however, all dynamic groups are indiscriminately expanded using one attrset "method". In the above example, all dynamic groups are expanded to the simple UID field (like a posix group). The groupOfURLs attrset rule (what would normally generate simple DN-member groups) is completely ignored. I've read the manpage, and although I don't see anything that says only one will be observed, I wanted to check with someone here to make sure this isn't a bug. If it isn't a bug, rather a feature, perhaps this topic should be expanded in the next manpage revision. Let me know, thanks. J

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 11 Feb '10

11 Feb '10

I am unable to reproduce this error. My peers and I believe this may = have been something unrelated to slapd specifically. You may close. Sorry.

1 0

(ITS#6470) slapd dying under load
by bmaupin＠uta.edu 10 Feb '10

10 Feb '10

Full_Name: Bryan Maupin Version: 2.4.21 OS: Red Hat Enterprise Linux 5.4 URL: http://omega.uta.edu/~bmaupin/bryan-maupin-100210.txt Submission from: (NULL) (129.107.38.77) About 2 months ago we upgraded from OpenLDAP 2.3 to OpenLDAP 2.4.19. All seemed well for about 4 weeks, and then slapd started dying on our replica servers. It frequently correlates with a CPU load spike, but not always. Available memory doesn't seem to be an issue. These problems didn't show up during testing, and don't seem to have affected the master, which has been running without stopping for the last 2 months, so the problems only seem to manifest themselves under production load. In our /var/log/messages we get messages like: Jan 15 16:58:03 kernel: slapd[22663] general protection rip:2ac667af65cc rsp:4659d970 error:0 Jan 16 15:42:34 kernel: slapd[10272] general protection rip:2b71f6c6d9c4 rsp:45441980 error:0 Jan 16 17:20:01 kernel: slapd[7538] general protection rip:2aec51954ae0 rsp:449518d0 error:0 Jan 19 13:38:46 kernel: slapd[2821] general protection rip:2aeac3070ae0 rsp:4918f8d0 error:0 Quanah Gibson-Mount told me to upgrade OpenLDAP and tcmalloc, so I did, but it didn't fix the problem. We're running OpenLDAP 2.4.21 on RHEL 5.4, with Heimdal 1.2.1-3, OpenSSL 0.9.8k, Cyrus-SASL 2.1.23, BDB 4.7.25 (with patches), Google tcmalloc (minimal) 1.5. Backtrace is available here: http://omega.uta.edu/~bmaupin/bryan-maupin-100210.txt Thanks.

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 05 Feb '10

05 Feb '10

Howard Chu wrote: >> If I can't trust slapcat during this >> phase, how can I trust slapcat for backups? > > Does slapcat behave this way on the active server? Yes. Sorry for the delay, but I've only just confirmed it now. The passive server needed to be moved, so I took it completely offline. Now there's only the active server and a backup shows the same result. Running slapcat while slapd is running produced invalid LDIF. Running slapcat after slapd is stopped produced OK LDIF - at least once. slapd has since been upgraded to 2.4.21. /Peter

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 05 Feb '10

05 Feb '10

Problem solved! olcSyncrepl now reads: olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 bindmethod=simple timeout =0 network-timeout=0 binddn="cn=dsyncuser,dc=example,dc=com" credentials="xxxxxxx " starttls=critical tls_cert="/usr/ssl/certs/examplewildcard.cert" tl s_key="/usr/ssl/certs/examplewildcard.key" tls_cacert="/usr/ ssl/certs/cacert_root.crt" tls_reqcert=demand tls_crlcheck=none filter="(obje ctClass=*)" searchbase="dc=example,dc=com" scope=sub attrs="*,+" schemachecking=of f type=refreshAndPersist retry="5 5 10 +" so the 'uri=""' string is no longer present, and slapd starts normally after converting. Thanks for the quick fix! Best, gerard

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