openldap-devel

openldap-devel@openldap.org

2 participants
1419 discussions

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

NUMA-aware tcmalloc
by Howard Chu 24 May '09

24 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel