Hey folks, I'm trying to debug the cause of faulty module behavior (autogroup) which has eluded both strace and 'slapd -d 16383' (and, just as a point of reference, it's slapd 2.4.18 and autogroup 1.8 on Ubuntu 8.04). So, I'd like to use gdb to figure out what's going on, but I'm not quite sure how to attack the problem. I've tried several different approaches to debug what's going wrong during the ldapsearch with gdb, but I can't seem to capture what I'm looking for. Rather than paste what I've tried, since it's ineffective, I'd instead like to ask how you all would approach it. So again, the scenario is: - slapd is running without any errors in the logs (about slapd or the failed autogroup expansions) - dynlist works, so I know that modules as a whole and dynamic searches work - autogroup doesn't generate any errors, but fails to perform any expansions during ldapsearches How can I attack this problem with gdb such that I'll be able to step through what's going on from the moment slapd begins parsing the entry requested by the ldapsearch in which there's supposed to be an expansion occurring? Many thanks in advance for your insight. Regards, Ryan

On Wed, 16 Sep 2009, omalleys(a)msu.edu wrote: You can try that, but unless the fault is a memory error of some sort, I don't know that valgrind has the right tools for it (or maybe I just don't use it the right way). It really sounds like the bigger issue is a logic issue. And honestly, in that case, a locally hacked version of the module with Debug() statements probably wouldn't hurt. Of course you can do same in gdb, and that has advantages that we like like not needing a recompile, but I think the concept of "put a print statement in" is a bit easier when getting started.

Howard Chu wrote: So, you're saying that dynlist should perform the expansion, and autogroup just allows you to filter it? The autogroup man page makes no mention of needing the dynlist module (only the dynlist schema), which to me seems to imply that it's intended to supersede, not complement, dynlist. However, I could certainly have subjectively misinterpreted the documentation, or it might just not be documented at all (in which case I'm happy to submit a patch after having inquired with the two major developers of the module as to the patch's accuracy. Several previous on-list postings about this aren't clear as to whether or not they use autogroup instead of or in addition to dynlist. And, when I tested the use of both together, the results aren't what I expect; e.g., the following query returns nothing: ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup,ou=Groups,dc=example,dc=com" -LLL '(uid=user1)' ... whereas the same query without the trailing '(uid=user1)' returns a group full of member uid's: ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup ou=Groups,dc=example,dc=com" -LLL dn: cn=testgroup,ou=Groups,dc=example,dc=com ou: Groups cn: testgroup objectClass: groupOfURLs memberURL: ldap:///ou=Users,dc=example,dc=com?uid?sub?(&(employeeType=Developer )(objectClass=exampleEmployee)) member: uid=user1,ou=Users,dc=example,dc=com member: uid=user2,ou=Users,dc=example,dc=com member: uid=user3,ou=Users,dc=example,dc=com If I use autogroup alone, it does not work either. So, I assumed this to be a problem in the module with whatever is supposed to trigger the expansion and was hoping to try and ferret it out with gdb instead of bothering the list with several posts full of output without having tried to debug it myself first. But, if I've interpreted it incorrectly and the premise for my investigation is invalid, I'm happy to be told exactly how to achieve the ability to filter dynamically created groups using one or both of those overlays before assuming and investigating a bug! For reference, the following posts are examples of what I'm referring to: http://www.openldap.org/lists/openldap-software/200802/msg00211.html http://www.openldap.org/lists/openldap-software/200812/msg00030.html As always, I appreciate any and all advice! Regards, Ryan

Howard Chu wrote: That wasn't a statement, it was a question, denoted by the question mark punctuation. And, if the answer is no, can you elaborate on what you did mean? Or, perhaps answer the question I asked at the end of the post, which was regarding how to achieve the desired affect, as you alluded to in http://www.openldap.org/lists/openldap-software/200802/msg00211.html, which reads: Pierangelo Masarati wrote: You might want to look at the autogroup overlay http://www.openldap.org/its/index.cgi/Contrib?id=5145 which will be included in OpenLDAP 2.4.8. -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ I have read the README. I'm interested in the behavior mentioned in that post, if you could be so kind to elaborate on the statement you made in it? Thanks, Ryan

Hey Andreas, Andreas Hasenack wrote: Thanks for the advice - I think you're right about filtering on the 'member' attribute. However, doing so still returns the entire list, not the individual member I'm filtering for. E.g., the same results as: ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup,ou=Groups,dc=example,dc=com" -LLL '(member=*)' At an even more basic level, something like this should work too, but it returns nothing: ldapsearch -x -w SECRET -D "cn=admin,dc=example,dc=com" -b "cn=testgroup,ou=Groups,dc=example,dc=com" -LLL member I'm not quite sure how to explain this behavior, given the implications made in the following two posts which indicate that I should be able to use dynamically generated attributes as filter expressions: http://www.openldap.org/lists/openldap-software/200802/msg00211.html http://www.openldap.org/lists/openldap-software/200812/msg00038.html Also, in the earlier ITS filed for the autogroup contrib overlay, it states that for searches and compares, it should behave like a static group, bolstering that supposition: http://www.openldap.org/lists/openldap-bugs/200709/msg00128.html So, should I be searching for a bug (which was the premise for the OP), or has the behavior of autogroup changed since its inception? As always, many thanks for any and all advice! Respectfully, Ryan

To expand on this a little bit more: LDAP filters are used to limit the number of entries returned. They do not limit attr=value pairs. Generally, with groups, the most common operation is the ldapcompare operation. It lets you "ask" whether or not a given value is assigned to an attribute in a specific entry. I.e., I can ask "Is uid=user1,ou=users,dc=example,dc=com a value for the member attribute in the group cn=testgroup ou=Groups,dc=example,dc=com" using the ldapcompare operation. It will answer one of three ways: TRUE, FALSE, or UNDEFINED. <http://www.openldap.org/software/man.cgi?query=ldapcompare&apropos=0&... --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

Ryan Steele wrote: attribute. However, doing so still returns That is the way LDAP search filters work, as Quanah explained in his followup. And yes, this comment deserves an RTFM response. Note that there is a ValuesReturnFilter control (RFC3876) which can be used to only return specific values in a result. expressions: The posts you reference make no such implication. States quite clearly "the dynamic members are not present in the entry during search, when the filter is evaluated. You can only filter for static data." Or again, for clarity: You cannot use dynamically generated attributes as filter expressions. The suggestion to use the autogroup overlay is precisely because autogroup does not use dynamically generated attributes, and therefore doesn't run into this constraint. How does "behaves like a static group" in any way support the notion that *dynamic* content is supported? You should be re-checking the enormous logical leaps you have made based on the material you have read. Another reason questions go un-answered is because the person asking them has already demonstrated such poor reading comprehension that the time spent writing an answer would be wasted; the answer will obviously be misunderstood. "static" and "dynamic" are clearly antonyms in this context but you have conflated the two together and are asking why you aren't seeing the behavior you expect. Since we can only communicate in English on this list, if you don't even understand this basic semantic in English then you're beyond our ability to help. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

On Tue, 15 Sep 2009, Ronie Gilberto Henrich wrote: No, I mean "slapd -d acl", not to say that slapacl isn't useful too. The key to slapacl is knowing what the proper input should be, and history has shown that "slapd -d acl" often proves enlightening to discovering the actual input to the ACL rules. Also, if you post relevant parts of "slapd -d acl" output to the list, it'll be a LOT easier than us having to try to divine (possibly quite relevant) DIT details.

Ronie Gilberto Henrich wrote: Try access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set.regex="user/allowedDomain & [$2]" write since the domain, after regex expansion, should be treated as a literal. Moreover, access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set.expand="user/allowedDomain & [$2]" write should be more appropriate. p.

On Wed, 16 Sep 2009, Ronie Gilberto Henrich wrote: Yes, that should have the same effect... As Pierangelo pointed out, that's the next thing to tweak.