openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

Re: (ITS#6465) startup error after converting to slapd-config
by rhafer＠suse.de 03 Feb '10

03 Feb '10

Am Mittwoch 03 Februar 2010 13:10:04 schrieb gerard.ranke(a)kmt.hku.nl: > Hi Ralf, > > Ralf Haferkamp wrote: > > A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test. > > I'm afraid I need a little guidance here. To test the fix, I replaced > the config.c from 2.4.21 with rev 1.513, but I got the errors below. > I'm guessing I'm being naive to think this would work, and that I > need to d'l the complete HEAD to compile, but how would I do that? Either that. Or you could get the diff from 1.512 to 1.153 from cvs and apply that on your 2.4.21 tree. > Cvs needs a module name, and I tried 'HEAD' and > 'OPENLDAP_REL_ENG_2_4' but these names couldn't be found. I couldn't > find anything else in the devel faq and website that seems like a > candidate for a module name, so could you please give me some > pointers? You can find instruction howto checkout OpenLDAP from cvs here: http://www.openldap.org/software/repo.html#AnonCVS Further up on that page you will also find a table listing valid modules (you want "ldap"). -- Ralf

1 0

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

03 Feb '10

Hi Ralf, Ralf Haferkamp wrote: > A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test. I'm afraid I need a little guidance here. To test the fix, I replaced the config.c from 2.4.21 with rev 1.513, but I got the errors below. I'm guessing I'm being naive to think this would work, and that I need to d'l the complete HEAD to compile, but how would I do that? Cvs needs a module name, and I tried 'HEAD' and 'OPENLDAP_REL_ENG_2_4' but these names couldn't be found. I couldn't find anything else in the devel faq and website that seems like a candidate for a module name, so could you please give me some pointers? Many thanks in advance, gerard cc-1020 c99: ERROR File = config.c, Line = 1222 The identifier "slap_keepalive" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1020 c99: ERROR File = config.c, Line = 1222 The identifier "sk" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1029 c99: ERROR File = config.c, Line = 1222 An expression is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1065 c99: ERROR File = config.c, Line = 1222 A semicolon is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1020 c99: ERROR File = config.c, Line = 1238 The identifier "slap_keepalive" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1020 c99: ERROR File = config.c, Line = 1238 The identifier "sk" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1029 c99: ERROR File = config.c, Line = 1238 An expression is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1065 c99: ERROR File = config.c, Line = 1238 A semicolon is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1065 c99: ERROR File = config.c, Line = 1239 A semicolon is expected at this point. slap_keepalive sk2; ^ cc-1020 c99: ERROR File = config.c, Line = 1242 The identifier "sk2" is undefined. sk2.sk_idle = 0; ^ cc-1020 c99: ERROR File = config.c, Line = 1246 The identifier "sk2" is undefined. sk2.sk_idle = strtol( s, &next, 10 ); ^ cc-1020 c99: ERROR File = config.c, Line = 1259 The identifier "sk2" is undefined. sk2.sk_probes = 0; ^ cc-1020 c99: ERROR File = config.c, Line = 1263 The identifier "sk2" is undefined. sk2.sk_probes = strtol( s, &next, 10 ); ^ cc-1020 c99: ERROR File = config.c, Line = 1276 The identifier "sk2" is undefined. sk2.sk_interval = 0; ^ cc-1020 c99: ERROR File = config.c, Line = 1280 The identifier "sk2" is undefined. sk2.sk_interval = strtol( s, &next, 10 ); ^ cc-1020 c99: ERROR File = config.c, Line = 1290 The identifier "sk2" is undefined. *sk = sk2; ^ cc-1565 c99: ERROR File = config.c, Line = 1336 The struct "slap_bindconf" has no field "sb_keepalive". { BER_BVC("keepalive="), offsetof(slap_bindconf, sb_keepalive), 'x', 0, (slap_verbmasks *)slap_keepalive_parse }, ^ ( warnings skipped... ) cc-1565 c99: ERROR File = config.c, Line = 1889 The struct "slap_bindconf" has no field "sb_keepalive". if ( sb->sb_keepalive.sk_idle ) { ^ cc-1565 c99: ERROR File = config.c, Line = 1890 The struct "slap_bindconf" has no field "sb_keepalive". ldap_set_option( ld, LDAP_OPT_X_KEEPALIVE_IDLE, &sb->sb_keepalive.sk_idle ); ^ cc-1565 c99: ERROR File = config.c, Line = 1893 The struct "slap_bindconf" has no field "sb_keepalive". if ( sb->sb_keepalive.sk_probes ) { ^ cc-1565 c99: ERROR File = config.c, Line = 1894 The struct "slap_bindconf" has no field "sb_keepalive". ldap_set_option( ld, LDAP_OPT_X_KEEPALIVE_PROBES, &sb->sb_keepalive.sk_probes ); ^ cc-1565 c99: ERROR File = config.c, Line = 1897 The struct "slap_bindconf" has no field "sb_keepalive". if ( sb->sb_keepalive.sk_interval ) { ^ cc-1565 c99: ERROR File = config.c, Line = 1898 The struct "slap_bindconf" has no field "sb_keepalive". ldap_set_option( ld, LDAP_OPT_X_KEEPALIVE_INTERVAL, &sb->sb_keepalive.sk_interval );

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