Re: Debugging a module
Hi Quanah, Quanah Gibson-Mount wrote: This is how filters work in LDAP. It sounds to me like things are working correctly. I.e., if I search for objectClass=joe objectClass, it will return every entry that has an objectClass value of joe, and all the values for objectClass. If I search for (member=uid=user1,ou=users,dc=example,dc=com), it will return to me every group that has a member attribute matching that value. I see nothing wrong in the behavior here, just in the understanding of how filters work. Let me know if you have further questions. 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=ldapcompareapropos=0sektion=0manpath=OpenLDAP+2.4-Releaseformat=html Ah, your responses have been most helpful, thank you! The ldapcompare operation might actually satisfy the end-goals I was hoping to achieve by returning the dn or uid explicitly. Cheers! Respectfully, Ryan
Re: Debugging a module
Hey Andreas, Andreas Hasenack wrote: On Wed, Sep 16, 2009 at 17:42, Ryan Steele ry...@aweber.com wrote: 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)' This filter doesn't look right. Try (member=uid=user1,ou=Users,dc=example,dc=com) 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 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
Re: Debugging a module
--On Friday, September 18, 2009 2:13 PM -0400 Ryan Steele ry...@aweber.com wrote: This filter doesn't look right. Try (member=uid=user1,ou=Users,dc=example,dc=com) 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=*)' Ryan, This is how filters work in LDAP. It sounds to me like things are working correctly. I.e., if I search for objectClass=joe objectClass, it will return every entry that has an objectClass value of joe, and all the values for objectClass. If I search for (member=uid=user1,ou=users,dc=example,dc=com), it will return to me every group that has a member attribute matching that value. I see nothing wrong in the behavior here, just in the understanding of how filters work. Let me know if you have further questions. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: Debugging a module
This is how filters work in LDAP. It sounds to me like things are working correctly. I.e., if I search for objectClass=joe objectClass, it will return every entry that has an objectClass value of joe, and all the values for objectClass. If I search for (member=uid=user1,ou=users,dc=example,dc=com), it will return to me every group that has a member attribute matching that value. I see nothing wrong in the behavior here, just in the understanding of how filters work. Let me know if you have further questions. 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=ldapcompareapropos=0sektion=0manpath=OpenLDAP+2.4-Releaseformat=html --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: Debugging a module
Ryan Steele wrote: Hey Andreas, Andreas Hasenack wrote: On Wed, Sep 16, 2009 at 17:42, Ryan Steelery...@aweber.com wrote: 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)' This filter doesn't look right. Try (member=uid=user1,ou=Users,dc=example,dc=com) 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 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. 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. 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: The posts you reference make no such implication. http://www.openldap.org/lists/openldap-software/200802/msg00211.html 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. 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 How does behaves like a static group in any way support the notion that *dynamic* content is supported? 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! 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/
Re: Debugging a module
Howard Chu wrote: autogroup isn't supposed to perform any expansion during searches. That's not what it does. 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
Re: Debugging a module
Howard Chu wrote: Ryan Steele wrote: Howard Chu wrote: autogroup isn't supposed to perform any expansion during searches. That's not what it does. So, you're saying that dynlist should perform the expansion, and autogroup just allows you to filter it? I'm quite certain I never said any such thing. 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: Guy Deleeuw wrote: All work fine, I can retrieve the two group entries. Now, I try to retrieve the group which have a particular member (ExoMemberShipMember): ldapsearch -x -LLL -b ou=groups,ou=portal,ou=www,ou=Exo,o=Eurofer,c=be -s sub (((objectClass=ExoMemberShip)(ExoMemberShipURL=*))(ExoMemberShipMember=cn=De Leeuw Guy,br=Internal,o=Eurofer,c=be)) And I receive an empty respond. Could you give me your advice about the feasibility of this kind of query ? This occurs because you can't filter for dynamically created members, as they get added to the entry while it's being returned. So the dynamic members are not present in the entry during search, when the filter is evaluated. You can only filter for static data. 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 Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ The autogroup Readme clearly states: 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
Re: Debugging a module
On Wed, Sep 16, 2009 at 17:42, Ryan Steele ry...@aweber.com wrote: 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)' This filter doesn't look right. Try (member=uid=user1,ou=Users,dc=example,dc=com) 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
Re: Debugging a module
On Wed, 16 Sep 2009, omall...@msu.edu wrote: The ISCA answer is:? You might try run everything under Valgrind instead of gdb as it might be easier. 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.
Re: Debugging a module
Ryan Steele wrote: 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 autogroup isn't supposed to perform any expansion during searches. That's not what it does. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Debugging a module
Ryan Steele wrote: Howard Chu wrote: autogroup isn't supposed to perform any expansion during searches. That's not what it does. So, you're saying that dynlist should perform the expansion, and autogroup just allows you to filter it? I'm quite certain I never said any such thing. 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. The autogroup Readme clearly states: DESCRIPTION The autogroup overlay allows automated updates of group memberships which meet the requirements of any filter contained in the group definition. The filters are built from LDAP URI-valued attributes. Any time an object is added/deleted/updated, it is tested for compliance with the filters, and its membership is accordingly updated. For searches and compares it behaves like a static group. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
