openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

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 12 Feb '10

12 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 12 Feb '10

12 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

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by rhafer＠suse.de 03 Feb '10

03 Feb '10

Am Mittwoch 03 Februar 2010 09:39:19 schrieb hyc(a)symas.com: > rhafer(a)suse.de wrote: > > Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: > >> But how did the suffix entry get created without an entryCSN in the > >> first place? The MOD that updates the contextCSN doesn't happen > >> until after the suffix entry already exists. > > > > It wasn't created without an entryCSN. It always had one. But the > > MOD to update the contextCSN (coming from the provider) doesn't > > contain one. So bdb_modify() will call slap_mods_opattrs() to add > > entryCSN to the MOD operation. The easiest fix is probably to never > > touch the opattrs if "updatedn" is doing MODs, though I am not yet > > sure if it might break something. Currently my fix (not committed > > yet) only skips the slap_mods_opattrs() step if "updatedn" it is > > doing a MOD on contextCSN. > > Ah, got it. Yes, sounds like your fix is fine. Do you think it's fine to always skip slap_mods_opattrs() if "updatedn" is writing? Or should I check for contextCSN MODs specifically? > Historically the updatedn user (e.g. slurpd) has always provided all of > the operational attributes in its updates. -- Ralf

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by hyc＠symas.com 03 Feb '10

03 Feb '10

rhafer(a)suse.de wrote: > Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: >> But how did the suffix entry get created without an entryCSN in the >> first place? The MOD that updates the contextCSN doesn't happen until >> after the suffix entry already exists. > It wasn't created without an entryCSN. It always had one. But the MOD to > update the contextCSN (coming from the provider) doesn't contain one. So > bdb_modify() will call slap_mods_opattrs() to add entryCSN to the MOD > operation. The easiest fix is probably to never touch the opattrs if > "updatedn" is doing MODs, though I am not yet sure if it might break > something. Currently my fix (not committed yet) only skips the > slap_mods_opattrs() step if "updatedn" it is doing a MOD on contextCSN. Ah, got it. Yes, sounds like your fix is fine. Historically the updatedn user (e.g. slurpd) has always provided all of the operational attributes in its updates. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

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