Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by linamat＠telco.md
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.
13 years, 3 months
Re: (ITS#6456) Feature Request
by j＠gropefruit.com
... bump ....
I would like *some* kind of acknowledgment of this ticket. Is this a =
good idea? Bad idea? Any response whatsoever?=
13 years, 3 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com
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=
13 years, 3 months
(ITS#6472) Syncrepl : loop problem with moddn on a new node
by julien.combes＠i-carre.net
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,
13 years, 3 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it
> 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.
13 years, 3 months
(ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com
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
13 years, 3 months
(ITS#6470) slapd dying under load
by bmaupin＠uta.edu
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.
13 years, 3 months
Re: (ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk
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
13 years, 4 months
Re: (ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl
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
13 years, 4 months
