openldap-devel

openldap-devel@openldap.org

1416 discussions

NUMA-aware tcmalloc
by Howard Chu 23 May '09

23 May '09

For those of you running multi-socket Opteron servers (and eventually, multi-socket Nehalem servers), AMD published a whitepaper last week on their work adapting Google's tcmalloc to be NUMA-aware. The whitepaper includes links to their source code / diffs. It appears to be quite a performance boost in their (very artificial) benchmark. I'll be trying it out soon myself. -- -- 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 3

current RE24 experience
by Aaron Richton 14 May '09

14 May '09

I've had a spurt of bad luck with 2.4.16 (it appears Quanah and a few others may share that opinion). The seg faults inspired me to run under libumem, which has some interesting features that give you "moderate" debug ability in exchange for moderate performance hit -- small enough that I can run it hot safely, unlike full-featured memory debuggers. At this point a RE24 checkout from late Saturday has been good for me in production, with some moderate libumem checks enabled. Is everybody else starting to see RE24 shape up? Bottom line...I think I'm now +1 for encouraging a 2.4.17 train, for what it's worth...

4 6

Negated ACL fields?
by Rein Tollevik 11 May '09

11 May '09

I have some ACLs where the same <who> statements are included in all the <by> fields. Rather than re-evaluating them each time I would like to quickly skip the entire ACL by negating the statements. I.e, rather than: access to * by <who1> <who2> ... by <who1> <who3> ... I'd like to say: access to * by !<who1> break by <who2> ... by <who3> ... And, I would like to negate the individual <who> statements, not necessarily all of them. This would also immediately make it useful to include the same type of <who> statement more than once in a <by> field, i.e: access to * by !dn=something !dn=something-else ... Neither of these can be easily implemented with the current internal representation of the <who> statements, as each type is now an element in the Access struct that represents the entire <by> field. To do it this would have to be changed into a struct which includes a list of <who> statements, evaluated in the order they are defined. Making this change is likely to alter the order in which existing ACL <who> statements are evaluated, but their combined effect should be the same since they are effectively and'ed together. Unless evaluating any of them have other side-effects that is, which they don't have as far as I know. This would also give the administrator full control of the order in which the statements are evaluated, which I find to be a Good Thing. As of now relatively "cheap" statements like testing the security strength factors are evaluated after potential "costly" operations like set statements. If the <who> statements are to be changed like this it makes sense to do the same to the <what> fields as well. Which again raises the question as to how regexp captions should be handled. For negated fields it is meaningless to capture any regexp fields, so they should not define nor alter any already captured sub-matches. For the other I find it most natural that the last evaluated <what> field defines the sub-matches for that <what> type, and making the sub-matches immediately accessible in the <what> fields that follows them. Allowing <what> fields to be negated would also eliminate the need to define "artificial" objectclasses to allow negated "attrs" lists. I.e, assuming the "attrlistClass" objectclass allows "attr1" and "attr2", the following would be equivalent: access to attrs=@attrlistClass by ... access to !attrs=!attrlistClass by ... access to attrs=attr1,attr2 by ... as would: access to attrs=!attrlistClass by ... access to !attrs=@attrlistClass by ... access to !attrs=attr1,attr2 by ... Assuming the "sufficient" control discussed in my previous posting is also accepted I could quickly grant read access to all attributes in an entry, leaving the actual choice at to whether they can be read to the access granted to the entry itself, using the following (after other ACLs that protects any non-readable attributes): access to !attrs=entry,children by * read sufficient Attempting the same with write would be disastrous though, as write access to an attribute do not require write access to the "entry" pseudo attribute, whereas read access to the "entry" is required to read its attributes. Comments? -- Rein Tollevik Basefarm AS

1 0

ACL decisions based on requested access
by Rein Tollevik 11 May '09

11 May '09

I have a fairly complicated ACL set which I need to optimize the evaluation of. To do this I need to make decisions based on the requested access level, which currently isn't possible (as far as I know that is). E.g, most of my ACLs are concerned with whether the entries and attributes should be read or writable or not, and I would like to quickly grant search access when that is all that is requested. One possibility I have considered is to add a new optional <requested access> field between the existing <who> and the <access> clauses, but I'm not very happy with that solution as it could easily be mixed with the existing <access>. So far my preferred solution is to add two new ACL controls, which I currently think of as "sufficient" and "requested". The "sufficient" control should act like "stop" (i.e grant access) if the effective <access> is sufficient for the requested access level, "continue" otherwise. The "requested" control should act like "continue" if the effective <access> matches what is requested, "break" otherwise. I initially thought that "break" should be the non-match action in both controls, but I think "continue" is the best for "sufficient" as that allows further decisions to be made in the same ACL without repeating the <to> part in a following ACL. At the cost of repeating the <who> part in a new condition in the same ACL if "break" was really needed.. I.e, both choices have their ups and downs, and I can live with both. I also though that "stop" should be the non-match case for "requested" to make the controls more symmetric. But that removes the ability to make further decisions in the succeeding rules, which I find highly unsatisfactory. These controls would allow access rules like the following to quickly grant search access if that is all that is requested, while keep on processing for other access types: access to <what> by <who> =s sufficient by * break An access rule where the <who> clauses are only evaluated when write access is requested could be written like: access to <what> by * =w requested by <who> =w Comments? It should be fairly easy to implement these controls, and I'll volunteer to do it if they are acceptable. -- Rein Tollevik Basefarm AS

4 4

configurable keepalive setting through libldap?
by Ralf Haferkamp 07 May '09

07 May '09

Hi, since quite some time libldap enables tcp-keepalive, e.g. to detected dangling syncrepl connections. However the default timeout of two hours that most systems are using might be a bit too long for some applications (e.g. I had a problem lately were nscd didn't answer queries anymore because nss_ldap was blocking in SSL_read() while the underlying connection has been cut off). On the other hand messing with the system wide settings might no be a good idea either. On Linux it is possible to configure the keepalive settings on a per socket basis through the TCP_KEEP* socket options. Would it be worth adding ldap_set_option() support for those, even if they are not really portable? -- regards, Ralf

5 9

Re: commit: ldap/contrib/slapd-modules/nssov README nssov.c nssov.h pam.c
by Howard Chu 04 May '09

04 May '09

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/contrib/slapd-modules/nssov > > Modified Files: > README 1.5 -> 1.6 > nssov.c 1.10 -> 1.11 > nssov.h 1.6 -> 1.7 > pam.c 1.7 -> 1.8 > > Log Message: > More for sessions, working. TODO: configure list of sessions to record For anyone interested, this is essentially code-complete. It works for me, but there are several areas I want to tweak still. Feedback on usability would be helpful at this point. If anyone wants to jump in and get a real manpage started, that would be nice too. The main objective here was to eliminate the libldap dependencies/clashes that the current pam_ldap/nss_ldap solutions all suffer from. A secondary objective was to allow for the possibility of more sophisticated caching than nscd provides. (E.g., run slapd back-ldap + pcache on each node.) Of course, you can also completey eliminate cache staleness considerations by running a regular database with syncrepl. And of course, another major objective was to allow all security policy to be administered centrally via LDAP, instead of having fragile rules scattered across multiple flat files. As such, there is no client-side configuration at all for the pam/nss stub libraries. (They talk to the server via a Unix domain socket whose path is hardcoded to /var/run/nslcd/). As a side benefit, this can finally eliminate the perpetual confusion over /etc/ldap.conf vs /etc/openldap/ldap.conf. User authentication is performed by internal simple Binds. User authorization leverages the slapd ACL engine, which offers much more power and flexibility than the simple group/hostname checks in the old pam_ldap code. At this point some cleanup is probably still needed, and merging the nslcd bits back into Arthur de Jong's code base is still underway. (Which means this code will be showing up in Debian soon, and I will be recommending it to the Ubuntu guys next month as well.) -- -- 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 3

Re: commit: ldap/libraries/liblber memory.c
by Howard Chu 01 May '09

01 May '09

hallvard(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/liblber > > Modified Files: > memory.c 1.74 -> 1.75 > > Log Message: > Fix previous fix: Don't #ifdef HAVE_STRNLEN before portable.h #defines that Since we're just talking about a simple for-loop, why are we even bothering to look for strnlen() at all? -- -- 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

ITS#4829, creating olcDbDirectory
by Howard Chu 30 Apr '09

30 Apr '09

I thought I had a good idea for this, although upon further reflection it still has holes. But it may still be a good starting point for discussion: For backends that support the olcDbDirectory keyword, we should also define a write-only olcDbMkdir attribute. If it's provided when ldapadd'ing an olcDatabase entry, or when ldapmodifying, then its values are treated as pathnames that we will attempt to create before processing any other parts of the request. This attribute would not be persisted in the cn=config backing store, so it will only take effect on dynamic operations, not when reloading the config on a subsequent startup. If the target directory already exists and is owned by the current uid, then it's a no-op. If the owner doesn't match, or the target pathname is not a directory, the request will fail. Otherwise, we try the mkdirs and proceed if they succeed. No cleanup will be performed on a failure - it would be pretty rude to "rm -rf" an existing database here. It may still be worthwhile to provide a global setting defining the filesystem locations that are allowed to be used. (Of course, anyone with back-config's rootdn credentials can set it to anything they want, anyway.) 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/

3 2

Re: ITS#4829, creating olcDbDirectory
by ghenry＠OpenLDAP.org 30 Apr '09

30 Apr '09

----- "Howard Chu" <hyc(a)symas.com> wrote: > I thought I had a good idea for this, although upon further reflection > it > still has holes. But it may still be a good starting point for > discussion: > > For backends that support the olcDbDirectory keyword, we should also > define a > write-only olcDbMkdir attribute. If it's provided when ldapadd'ing an > > olcDatabase entry, or when ldapmodifying, then its values are treated > as > pathnames that we will attempt to create before processing any other > parts of > the request. This attribute would not be persisted in the cn=config > backing > store, so it will only take effect on dynamic operations, not when > reloading > the config on a subsequent startup. > > If the target directory already exists and is owned by the current > uid, then > it's a no-op. If the owner doesn't match, or the target pathname is > not a > directory, the request will fail. Otherwise, we try the mkdirs and > proceed if > they succeed. No cleanup will be performed on a failure - it would be > pretty > rude to "rm -rf" an existing database here. > > It may still be worthwhile to provide a global setting defining the > filesystem > locations that are allowed to be used. (Of course, anyone with > back-config's > rootdn credentials can set it to anything they want, anyway.) So if slapd is run as root, the uid is 0 then the olcDbMkdir can create a dir anywhere on the file system? The obvious thing to do there then is not run slapd as root and as an ldap user and make this very clear in the docs. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: Build farm central node
by ghenry＠OpenLDAP.org 12 Apr '09

12 Apr '09

----- "Howard Chu" <hyc(a)symas.com> wrote: > Gavin Henry wrote: > > Hi all, > > > > I now have admin privs on the projects build box, so what do we need > in a build farm? > > > > I like the Samba model with the drop down to view things: > > > > > http://build.samba.org/?host=SerNet-solaris8&tree=ldb&compiler=gcc-4.2&func… > > http://build.samba.org/about.html > > > > And I like that users can add their arch too: > > > > http://build.samba.org/instructions.html > > > > Code is at: > > > > http://cvs.samba.org/cgi-bin/cvsweb/build_farm/ > > > > I'm happy to get everything setup but I need to know what we want. > My > > first > thoughts were to have lots of VMs on the big build box we've got, > bring the > VMs up and down when needed and compile HEAD, RE24 periodically, but > that > smoke testing would just make noise. > > > > We'll need a frontend to browse results anyway and maybe an admin > panel to > issue builds or just some admin commandline tools for pre-release > testing. > E-mails could go to a new openldap-builds(a)openldap.org list or > similar. We'll > also need a tool for users to register their system/host with the > build master > to collect results and show them. And we'll need some set of standard > build > options to be uniform across platforms? > > These frontends aren't already part of the samba build farm package? I think some of them are yes. I'll download it and check. > > I think a first pass would be to get all the infrasructure up with a > single VM > as a target. And I think adding non-Linux VMs is an obvious next step > - > FreeBSD, OpenSolaris, etc. Yes, good plan. > If QEMU was further along I'd investigate that route too for non-x86 > testing > but unfortunately it seems to be fairly limited in that respect. > (E.g., QEMU > Sparc emulation still can't boot Solaris.) Yes, true. Once the right infrastructure is complete, we should hopefully get these platforms donated etc. > > Lastly, there is also: > > > > http://gcc.gnu.org/wiki/CompileFarm > > It may be worth asking. I personally don't have access to any Alpha or > MIPS > systems any more, but can generally get to the others when needed. > Running > "make test" on my G1 phone is entertaining... ;-) Will check. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel