openldap-devel

openldap-devel@openldap.org

1443 discussions

minor test stuff
by Howard Chu 18 Nov '08

18 Nov '08

The long fixed-length waits in the syncrepl tests always annoy me. Is anyone actually testing on hardware that takes longer than 1 second to sync? (The last time I tested on such a slow machine was the z/OS partition I ported to back in 2002/2003.) Would anyone object to dropping the all syncrepl intervals to say, 2 seconds, and setting the delays to around 5 seconds? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

RE24 testing again
by Quanah Gibson-Mount 18 Nov '08

18 Nov '08

Please test current RE24, it has been synch'd with the fixes found for the last round of testing. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

8 7

Please test RE24
by Quanah Gibson-Mount 17 Nov '08

17 Nov '08

Please test RE24. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

7 16

Re: commit: ldap/servers/slapd/overlays dynlist.c
by Hallvard B Furuseth 17 Nov '08

17 Nov '08

quanah(a)OpenLDAP.org writes: > dynlist.c 1.58 -> 1.59 > Fix prev commit Still using the wrong length. Should both be soc_cname, or both ad_cname? -- Hallvard

1 0

Re: commit: ldap/servers/slapd/overlays dynlist.c
by Hallvard B Furuseth 16 Nov '08

16 Nov '08

ando(a)OpenLDAP.org wrote: > dynlist.c 1.57 -> 1.58 > add optional URI to allow restricting the scope of application of a > specific dynamic list expansion rule (ITS#5761) Bug: Third arg here should be an integer, not a string. + ptr = lutil_strncopy( ptr, dli->dli_oc->soc_cname.bv_val, dli->dli_ad->ad_cname.bv_val ); -- Hallvard

2 1

IDL bit vectors
by Howard Chu 16 Nov '08

16 Nov '08

Seems like I keep poking at this idea again every couple years. If we use a <base,vector> we can cover a much wider range without losing any precision. For a 32 bit machine, 32 bits per word would cover 5 bits worth of entry IDs. So 27 bits would comprise the base, and the next 32 bits would represent up to 32 entry IDs. To avoid wasting those 5 unneeded bits in the base, we could use them as a run-length counter and use multiple vectors per base. But it might be better to slide things over and use just a 24 bit base, and use the bottom 8 bits of the word as a bitmask to represent which following vectors are present. E.g. ......01 means 1 vector follows, representing base+ 0-31. ......02 means 1 vector follows, representing base+32-63. ......05 means 2 vectors follow, base+0-31 then base+64-95. That allows us to represent up to 256 entryIDs in only 288 bits (instead of the 16384 bits we currently need). That would allow us to track about 1.86M entryIDs in the same space we currently use to track only 64K entryIDs. It seems we would still need some kind of range representation to handle IDLs with more than 1.86M entries. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 5

"widely supported scripting language" for make test (was ITS#5809)
by Michael Ströder 16 Nov '08

16 Nov '08

Redirected this to openldap-devel list. ando(a)sys-net.it wrote: > Quanah Gibson-Mount wrote: > >>> I'm hitting an issue like this in some of the replication tests I'm >>> currently performing. For this purpose, I think we could hack >>> ldapsearch (or add a new prog, or use a script on ldapsearch output) >>> that sorts entries content attribute-wise and, within each attribute, >>> value-wise. Something like "sort" applied entry-wise after unwrapping >>> line folding, optionally case-insensitive would probably suffice. >> I have a script somewhere from Matt Backes @ Symas that sorts LDIF >> files. It was useful for seeing if it made any difference in slapadd (it >> didn't). > > Well, if it were distributable, and written in a widely supported > scripting language, it would be quite useful... What do you consider a "widely supported scripting language"? During some discussions about the test suite I felt that having a more powerful scripting language would help dealing with some of the problems in a more elegant way. Ciao, Michael.

3 4

Matching rule against IP subnet
by manu＠netbsd.org 16 Nov '08

16 Nov '08

Hello As far as I know, it is not possible to match an IP subnet. For instance, if I have an object like this: dn: cn=foo,o=example managedAddr: 192.0.2.0/24 And this kind of thing does not seems available: ldapsearch 'managedAddr:addressInSubnetMatch:=192.0.2.1' I can think of a few useful matching rules: addressInSubnetMatch subnetInSubnetMatch subnetContainsSubnetMatch subnetContainsAddressMatch subnetExactMatch (192.0.2.5/24 and 192.0.2.10/24 are the same) Questions: - can someone confirm this cannot be done yet? - is there a RFC to implement that does this? Or should I start with what I have though about and presented above? - is this functionnality welcome? - where do I start to implement it? The thing happen in schema_init.c and schema_prep.c, but I need to select an OID. How? The motivation is DNS configuration stored in LDAP. That feature could enable the delegation of subnet management to different administrators, the access being enforced by slapd ACL. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

4 9

Re: commit: ldap/servers/slapd acl.c aclparse.c proto-slap.h
by Hallvard B Furuseth 15 Nov '08

15 Nov '08

manu(a)OpenLDAP.org wrote: > acl.c 1.342 -> 1.343 > Add ACL <who> regex-substitution from attribute value submatches. Cf ITS#5804 This change: acl_string_expand( struct berval *bv, struct berval *pat, - char *match, - int nmatch, - regmatch_t *matches) + char *dn_match, + char *val_match, + AclRegexMatches *matches) needs to update the acl_string_expand() call at aci.c:406 to match. -- Hallvard

1 0

Re: commit: ldap/servers/slapd syncrepl.c
by Howard Chu 15 Nov '08

15 Nov '08

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > syncrepl.c 1.422 -> 1.423 > > Log Message: > ITS#5809 fix 1.421, avoid modrdn falling thru to modify unnecessarily This passes test019 but it's still not quite right. It will break if an entry is renamed followed by a genuine modify that alters the naming attribute, changing values that were not related to the modrdn values. -- -- 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:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel