April 2010 - openldap-devel

by Volker Lendecke

Hi! Out of several rumors I've heard that OpenLDAP converted it source repo to git. Is that true? www.openldap.org still speaks about cvs. If you changed to git, is the repo publically available? Thanks, Volker

12 years, 6 months

5
12
0 / 0

slapo-allowed: allowedChildClasses and allowedChildClassesEffective (was: Seg faults with 2.4.22)

by Michael Ströder

Redirected this to openldap-devel... masarati(a)aero.polimi.it wrote: > slapo-allowed was modified between 2.4.21 and 2.4.22; support for > allowedChildClasses and allowedChildClassesEffective was added. The semantics you've implemented seems to be incompatible with my implementation in web2ldap which works correctly with MS AD. I do not claim to know the *exact* semantics of these attributes though. web2ldap only uses the attribute 'allowedChildClasses'. In the object class select form web2ldap now only shows an empty list of STRUCTURAL object classes to be usable for a new entry. AUXILIARY object classes are shown. At first glance it seems STRUCTURAL object classes are not returned by slapo-allowed in the search result at all. Ciao, Michael.

13 years, 5 months

2
5
0 / 0

OpenLDAP 2.5

by Howard Chu

With 2.4.21 out, and hopefully stable enough to promote to the next Stable release, it's time to feature-freeze 2.4 and prepare for the 2.5 branch. As I already announced to the OpenLDAP-Committers, we're also planning to switch from CVS to GIT in mid-January. Commits for 2.5 will begin after we've settled into GIT. We haven't really laid out a formal roadmap for 2.5 yet, but I think most of it has been discussed here or in Development ITSs already. I would like to be able to resolve all outstanding Development ITSs - we will either implement them or reject/close them. There are 42 outstanding at the moment. Likewise for all outstanding ITSs in Software Bugs - many of them have been deferred because a proper fix would require invasive changes to large parts of the code base. There are 26 outstanding. With 2.5 beginning we are free to make these large scale changes. We should also walk thru the Software Enhancement requests and decide which to accept and which to reject. Currently there are 37 outstanding. I also have a number of specific areas I want to see worked on; some of these are included in the above ITSs but I'll outline them here: syncrepl config - this is pretty unwieldy already; syncrepl needs to be moved outside of the slapd core and into an overlay. That will allow us a lot more flexibility in configuring while also eliminating a lot of redundant parsing code. suffixmassage - we at the very least need to be able to point a consumer at some non-homogeneous suffix in the provider. We may go for complete librewrite support as well, although at this point I don't see as strong a need. config TLS certs and keys should be stored as LDAP attributes, not pointers to filesystem locations. This is a prereq to using some of the dynamic cert generation features of the CA overlay. (This can be troublesome as there may not be clean APIs for reading certs from memory in all of the TLS APIs we support.) Disabling individual config attribute values and entries. At the moment I'm thinking of adding an ";x-disabled" tag to those values. back-mdb Using a single-level store for Entries will impact all of the schema engine as well. I think the simplest solution here is going to be using an mmap'd file for all of the schema elements. The actual design of back-mdb still needs to be defined in several areas. The single-level store approach exposes us to some new failure modes that the current multi-level backends don't have. (E.g., corruptions due to bad RAM / wild pointer writes are very likely to get persisted on disk, implicitly.) The solution I'm considering is based on a mirroring strategy. Every database will be stored twice on disk: once in the file that is actively mmap'd into the process, and once in a write-only file. On every intentional update of a memory page, we will also store a checksum of the page, and manually write the page to the mirror. If we detect a checksum failure on any in-memory page we can still retrieve a valid copy from the mirror file. This of course doubles our potential I/O load, but I don't believe it's any worse than the load from performing write-ahead logging on a traditional database. (And yes, mirroring will take the place of writing transaction log files.) Some of these same considerations apply to the schema storage, but not entirely. At runtime, the schema is effectively read-only. When we do dynamic schema changes thru cn=config, all other threads are suspended. For the mmap purposes, we can mark all of the schema pages as read-only during runtime, and only make them read-write when cn=config is actually trying to perform an update. As such, the only sticky issue is dealing with changes made to the back-config internal files by plain text editors and such. These are the things I'm interested in. But as always, this Project is driven forward by the particular interests of each individual contributor. If you have other ideas you want to pursue, speak up. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

13 years, 5 months

9
13
0 / 0

RE24 call for testing (round 1)

by Quanah Gibson-Mount

Please test RE24 in preparation for 2.4.22. Currently it all builds for me, and the only test failure I've had is for test022 (ppolicy). It happened in 36/100 runs, not sure what is going on there. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

13 years, 5 months

5
5
0 / 0

Some "long" standing ITSes

by masarati＠aero.polimi.it

I think there are a few "long" standing ITSes, or candidate ones, that need some discussion as they have -devel implications. ITS#6505: add "const" to attrs in libldap search API: not a big deal, it would change a consolidated API, but the change should be harmless. ITS#6482: the issue is not easily reproducible; the proposed patch sounds a bit naive; perhaps bi_tool_entry_next() could be strengthened by trying a bit harder to get the next ID. Not sure how, the first guess would be to increment the last ID and use DB_SET instead of DB_NEXT until something is found (as naive as the proposed one). Suggestions for better strategies? In any case, I think backend-specific issues should be hidden in the backend tool helpers rather than attempted by slaptools themselves. ITS#6477: the reported case story can be dealt with by detecting the error and re-running slaptest with -d; however, there might be cases where the exact knowledge of the cause of a TLS error may be useful in syslog's logs; this would require to change the way those errors are logged by the client library. Comments? p.

13 years, 5 months

2
1
0 / 0

Re: commit: ldap/servers/slapd syncrepl.c

by masarati＠aero.polimi.it

> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > syncrepl.c 1.505 -> 1.506 > > Log Message: > alreadyExists is a legitimate result code (further improve ITS#6472 > commit; also fix ITS#6528) Two comments: 1) syncrepl_add_glue() and syncrepl_add_glue_ancestors() should be renamed slapd_add_glue() and slapd_add_glue_ancestors(); the latter should be exposed as well, as it may be useful to other modules. 2) syncrepl_add_glue_ancestors() returning alreadyExists when the immediate parent entry exists is pointless, as it does not indicate an error, while the existence of a non-immediate ancestor would not be notified to the caller. BTW, this caused ITS#6528 (my fault, of course). p.

13 years, 5 months

2
2
0 / 0

Re: commit: ldap/servers/slapd/back-ldap chain.c

by masarati＠aero.polimi.it

> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-ldap > > Modified Files: > chain.c 1.76 -> 1.77 > > Log Message: > add support for don't use copy in SASL auxprops lookup/store (ITS#6475; > TODO: document new directives) Please note that the relatively minor modifications to slapo-chain(5) are not conditioned on #define SLAP_AUXPROP_DONTUSECOPY, because I think they are generally useful, and I've checked they don't break anything (I could check so far). Please report any inconvenience. p.

13 years, 5 months

1
0
0 / 0

Re: commit: ldap/servers/slapd sl_malloc.c zn_malloc.c

by Quanah Gibson-Mount

--On Friday, January 15, 2010 5:53 PM +0000 hallvard(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > sl_malloc.c 1.67 -> 1.68 > zn_malloc.c 1.14 -> 1.15 > > Log Message: > Gentler message when falling back to ch_malloc > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/sl_malloc.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/zn_malloc.c > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. The new error message doesn't make sense, English wise. It doesn't even parse. - "slap_sl_malloc of %lu bytes failed, using ch_malloc\n", + "slap_sl_malloc of %lu bytes falling back to ch_malloc\n", I.e., what would get logged is: slap_sl_malloc of 700 bytes falling back to ch_malloc Which really gives the end user no idea what is wrong. I would suggest something like: + "slap_sl_malloc of %lu bytes failed, falling back to ch_malloc\n", Similar with the slap_zn_malloc error message. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

13 years, 5 months

2
2
0 / 0

Re: commit: ldap/libraries/libldap tls.c

by Quanah Gibson-Mount

--On Sunday, January 24, 2010 6:16 PM +0000 ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > tls.c 1.167 -> 1.168 > > Log Message: > skip the serial, whatever its length (ITS#6460) > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/ > http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/tls.c > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. This fix is wrong. tls.c is deprecated and no longer used. In RE24, there is: tls2.c tls_g.c (gnutls) tls_m.c (moznss) tls_o.c (openssl) I am re-opening the ITS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

13 years, 5 months

1
0
0 / 0

nssov change proposal

by Kean Johnston

If this is the incorrect list to discuss nssov on please accept my apologies and point me in the right direction. the docs don't indicate a better place. First let me start with saying what I am trying to achieve. If there is an alternate way to do this using memberof/dynlist I have not been able to figure it out. I am trying to get host access based on group membership working. Consider the following definition for 2 hosts: dn: cn=host1,ou=hosts,dc=example,dc=com objectClass: ipHost objectClass: myHostAccessObject cn: host1 ipHostNumber: 10.1.2.3 hostAccessGroup: admins hostAccessGroup: dbas authorizedService: sshd dn: cn=host2,ou=hosts,dc=example,dc=com objectClass: ipHost objectClass: myHostAccessObject cn: host2 ipHostNumber: 10.2.3.4 hostAccessGroup: hrpeople hostAccessGroup: dbas authorizedService: sshd The hostAccessGroup refers to the name of a group whose users can access the machine. For example: dn: cn=admins,ou=access,dc=example,dc=com objectClass: groupOfNames cn: admins member: uid=user1,ou=people,dc=example,dc=com member: uid=user2,ou=people,dc=example,dc=com dn: cn=dbas,ou=access,dc=example,dc=com objectClass: groupOfNames cn: dbas member: uid=user1,ou=people,dc=example,dc=com member: uid=user3,ou=people,dc=example,dc=com dn: cn=hrpeople,ou=access,dc=example,dc=com objectClass: groupOfNames cn: hrpeople member: uid=user1,ou=people,dc=example,dc=com member: uid=user4,ou=people,dc=example,dc=com Given the above, user1, user2 and user3 will be able to access host1, and user1 and user4 will be able to access host2. It seems to me access based on group membership should be easy to do but I have struggled with it immensely. I am new to LDAP so it is most likely a lack of knowledge on my behalf but I have done a lot of research and have not been able to find a way to do what I want. I know the nssov documentation says the prefered mechanism is to use hostservice, and I would like to, but I can't see how to create an ACL that would implement the above. An alternative would be to use some existing group entry, such as a posixGroup but that has even more complications as the memberUid is just the UID and not a DN for a person. Given that I can't see a way I would like to propose either extending nssov or perhaps writing a dynacl module that could help implement this. Before I rush off and attempt a design I would like input from this list to see if you think its a worthwhile idea. Thank you for your time. Kean.

13 years, 5 months

3
3
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel April 2010