openldap-devel

openldap-devel@openldap.org

1416 discussions

Beware of Fedora 11's glibc
by Howard Chu 10 Jun '09

10 Jun '09

From this bug it appears there's a known history of problems with the experimental malloc being used in the new glibc. https://bugzilla.redhat.com/show_bug.cgi?id=494631 It appears that slapd is hitting some issues in this code still, even though the other symptoms in that bug report are marked as fixed. LD_PRELOADing a 3rd party malloc library shows no issues and likewise valgrind finds no invalid memory accesses in our code. I was seeing crashes on x86_64; the 32 bit code may actually be fixed by now. Just an fyi. I've already spent more than 2 weeks looking for a memory overwrite in slapd only to find that the malloc library is broken. I can't afford to spend any more time tracking this down. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 2

held locks after exit
by Aaron Richton 09 Jun '09

09 Jun '09

After an otherwise "clean" exit of test058, the smc/db directory showed the following, despite the fact that there was no more 9196 pid on the system. Is there any facility in db4 to trace locking? I don't think slapd's own debugging would give the level of detail that would be necessary to find a smoking gun, but if I'm just reading stuff wrong, I have the testrun directory from this. ---------- begin output ---------- Default locking region information: 138 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 20 Number of lock object partitions 4 Number of current locks 12 Maximum number of locks at any one time 3 Maximum number of locks in any one bucket 0 Maximum number of locks stolen by for an empty partition 0 Maximum number of locks stolen for any one partition 9 Number of current lockers 15 Maximum number of lockers at any one time 4 Number of current lock objects 8 Maximum number of lock objects at any one time 2 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 1009 Total number of locks requested 1005 Total number of locks released 0 Total number of locks upgraded 46 Total number of locks downgraded 4 Lock requests not available due to conflicts, for which we waited 0 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 488KB The size of the lock region 4 The number of partition locks that required waiting (0%) 4 The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 1 The number of locker allocations that required waiting (0%) 0 The number of region locks that required waiting (0%) 2 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Lock Region type 5 Region ID __db.005 Region name 0xfecf0000 Original region address 0xfecf0000 Region address 0xfecf00c8 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest Allocations by power-of-two sizes: 1KB 3003 2KB 0 4KB 0 8KB 0 16KB 2 32KB 0 64KB 1 128KB 0 256KB 0 512KB 0 1024KB 0 REGION_JOIN_OK Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 104 Lock region region mutex [0/119 0% 11775/1] 1031 locker table size 1031 object table size 616 obj_off 63456 locker_off 0 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 0 1 1 0 0 0 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 0 1 1 1 0 1 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 85 dd= 0 locks held 1 write locks 0 pid/thread 9196/1 85 READ 1 HELD id2entry.bdb handle 0 86 dd= 0 locks held 0 write locks 0 pid/thread 9196/1 87 dd= 0 locks held 1 write locks 0 pid/thread 9196/1 87 READ 1 HELD dn2id.bdb handle 0 88 dd= 0 locks held 0 write locks 0 pid/thread 9196/1 89 dd= 0 locks held 0 write locks 0 pid/thread 9196/1 8a dd= 0 locks held 0 write locks 0 pid/thread 9196/1 8000013c dd= 0 locks held 0 write locks 0 pid/thread 9196/1 8000013d dd= 0 locks held 0 write locks 0 pid/thread 9196/1 80000145 dd= 0 locks held 2 write locks 2 pid/thread 9196/1 80000145 WRITE 1 HELD 0x39548 len: 5 data: 0000000x0100 80000145 WRITE 1 HELD id2entry.bdb page 1 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 80000145 WRITE 1 HELD 0x39548 len: 5 data: 0000000x0100 80000145 WRITE 1 HELD id2entry.bdb page 1 85 READ 1 HELD id2entry.bdb handle 0 87 READ 1 HELD dn2id.bdb handle 0

1 0

Re: RE24 testing call (2.4.17)
by ghenry＠OpenLDAP.org 09 Jun '09

09 Jun '09

Jaunty - 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux all good. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

BDB / HDB Implementaion Internals
by Lorenzo Pastrana 09 Jun '09

09 Jun '09

Hello, I'm diving into the BDB backend code, and I was wondering if there was any specification document accessible, ideally that (those) document(s) would describe two things : one would be the openldap engine -> backend interface the other the interface -> cache -> db4 rationnale. Thanks Lorenzo Pastrana R&D Head @ Happy End -------------------------- Web Shop Multimédia Design Visual Communication & Publishing -------------------------- Tél.: +33 1 42 47 83 09 Fax.: +33 1 47 70 70 19 E-mail : lorenzo.pastrana(a)happyend.fr

2 2

Re: RE24 testing call (2.4.17)
by Gavin Henry 08 Jun '09

08 Jun '09

2009/6/8 Quanah Gibson-Mount <quanah(a)zimbra.com>: > Please test RE24 as we prepare for 2.4.17. Thanks! All good here on i386, will test 64 bit shortly. Did get the expected: No race errors found after 10 iterations Found 2 errors >>>>>> Exiting with a false success status for now >>>>> ./scripts/test058-syncrepl-asymmetric completed OK. -- http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

Admin guide version mix?
by Michael Ströder 04 Jun '09

04 Jun '09

HI! This admin guide page http://www.openldap.org/doc/admin23/overlays.html has title "OpenLDAP Software 2.4 Administrator's Guide: Overlays". Any clue what's the reason for this version number mix? Ciao, Michael.

2 2

Re: commit: openldap-guide/admin appendix-upgrading.sdf
by Gavin Henry 02 Jun '09

02 Jun '09

----- hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/openldap-guide/admin > > Modified Files: > appendix-upgrading.sdf 1.4 -> 1.5 > > Log Message: > ITS#6130 delete temporary note about back-monitor Thanks. I'm totally behind on my tickets as May has been really busy! Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

cn=config: sharing, conditionals
by Howard Chu 29 May '09

29 May '09

So, while we can fully replicate cn=config for the case where all syncrepl participants are masters/peers, things are still a bit sticky if we only want the replicas to remain in slave mode. Instead of going thru complicated mapping/virtual directory redirections, it seems to me that all we need is to tag certain config objects with the serverIDs to which they apply. As such, I'm considering adding an olcServerMatch attribute to the olcDatabaseConfig and olcOverlayConfig objectclasses. This would take a regexp to match against the current server ID; if the pattern matches then the config entry is processed otherwise it is ignored. This attribute would be absent/empty by default, making the entry always enabled. Likewise it may be useful to add a boolean olcDisabled attribute to these classes, to allow databases and overlays to be switched on and off without needing to delete them. Again, it would default to absent/FALSE... We'd also want these controls for syncrepl stanzas. (Too bad the patch to turn syncrepl into an overlay was never committed....) For example, we may have a cluster of servers in MMR with a pool of other servers operating as slaves. We'd want the syncprov overlay active on all of the masters, the syncrepl consumer active on all of the servers, and the chain overlay active on all of the slaves. Setting olcServerMatch on the syncprov and chain overlays would allow things to behave as desired, without needing to create a parallel config tree just for the slaves. Comments? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

7 19

Re: cn=config: sharing, conditionals
by Raphaël Ouazana-Sustowski 29 May '09

29 May '09

Hi, Le Ven 29 mai 2009 16:11, Howard Chu a écrit : > Rein Tollevik wrote: >> Howard Chu wrote: >>> Howard Chu wrote: >>>> Since there is currently no support at all, I think it's important to >>>> get >>>> something usable first, and worry about those other cases later. >>> >>> The other alternative, which is much simpler to implement, is just to >>> add a suffixmassage/rewrite keyword to the syncrepl config, allowing it >>> to pull from a particular remote base and map it to the local base. >>> Then >>> it's up to the sysadmin to create a complete cn=config hierarchy >>> somewhere else on the master server and let the slaves pick it up. That >>> would address all of the issues of differentiation, at the cost of a >>> little bit of redundancy on the master. >> >> I'm not too fond of the proposed olcServerMatch, it appears to me to >> create a cluttered config database that requires you to match these >> attribute values to see the currently active configuration. Should it >> be added though, then I would prefer it to be defined as range(s) of >> serverIDs rather than a pattern to match. Regexp matching of integer >> ranges is always awkward.. > > Yes, I agree, it would make things cluttered and the complexity could > easily > get out of hand. In retrospect I'm not so fond of the idea. Wouldn't it be possible to simply extend the attribute name to make it match a server? Eg: olcAccess;server1: ... olcAccess;server2: ... That would be IMHO more clear than any related regexp-attribute. Regards, Raphaël Ouazana.

2 1

Invalid DN after schema change
by Michael Ströder 29 May '09

29 May '09

HI! If one plays around with schema and an attribute type used in the RDN of an entry is no longer present then this entry is no longer readable because whenever a request is sent to slapd invalidDNSyntax is returned. This leads to the situation that a client can't even explicitly delete this offending entry anymore. I'd vote for relaxing the schema-based DN checking in case of search, rename (only old DN), modify and delete requests a bit so that after a schema change the data can be corrected with normal client tools without server down-time. Any thoughts on this? Ciao, Michael.

3 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel