[389-devel] Re: Groups are not accessible by filter

[William Brown]

> On 9 May 2019, at 14:52, Anuj Borah  wrote:
> 
> @William Brown
>  
> Its not relevant to this subject line , but its related to lib389 .
> 
> Question : Does get_attrs_vals_utf8 and all get_attrs_vals types should case 
> sensitive ?? 
> 
> Look at bellow result:
> 
> with search_s:
> 
> (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4, ['cn', 
> 'Cn', 'CN'])
> [dn: uid=bhall,ou=People,dc=example,dc=com
> cn: Benjamin Hall
> ]
> 
> 
> with filter:
> 
> (Pdb) Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter(F4)[0].get_attrs_vals_utf8(['cn', 'Cn', 'CN'])
> {'cn': ['Benjamin Hall'], 'Cn': ['Benjamin Hall'], 'CN': ['Benjamin Hall']}

Indeed - this appears to be a bug in the library. It should probably do 
something like:

attrs = list(set([x.lower() for x in attrs]))

So first you would make everything lower:

lower = [x.lower() for x in attrs]

then you remove the duplicates by converting to set, as sets don't allow dupes:

lower_no_dup = set(lower)

finally convert back to a list for the ldap calls as they only accept list, not 
iterables:

list(lower_no_dup)

and then, on one-line it would be:

attrs = list(set([x.lower() for x in attrs]))


I'm happy for you to fix this, but it must be a new issue and seperate PR, not 
part of a test case you are updating. Keep in mind there are a few functions 
that take attrs as lists, so making this function generic like:

def normalise_attrlist(attrs):
return ...

Would be best.


> (Pdb) Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter(F4)[0]._unsafe_raw_entry()
> dn: uid=bhall,ou=People,dc=example,dc=com
> cn: Benjamin Hall
> gidNumber: 2000
> givenName: Benjamin
> homeDirectory: /home/bhall
> l: sunnyvale
> mail: bh...@anuj.com
> manager: uid=trigden,ou=People,dc=example,dc=com
> objectClass: top
> objectClass: account
> objectClass: posixaccount
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: nsMemberOf
> objectClass: nsAccount
> objectClass: person
> ou: Product Development
> ou: People
> roomNumber: 2511
> sn: Hall
> telephoneNumber: +1 408 555 6067
> uid: bhall
> uidNumber: 1000
> userPassword: 
> {PBKDF2_SHA256}AAAIAC03kM8if/x5GVc9teHEpMTOvB67mfH6NZYEmazAev2n6eoN2X+3JKu13ZpIG+WCPGWZH0niBxc7xvvqFsMkNPoRlBvmx23fWM+5VYcTCJs+iWQRxTb0FV/hheEU9a+Tqdj6fa0lL1aJTiOkKKk/mJdAHUiRvh8M6BtZmmc3pD0KNDwHQK/k/tuP1X7+nA+6ioT5WCb2NjjR4jFuNO681Ko6nG/wAWz/T+lYsVHdFV84MfBX81dgRDGmGyAew2YwNDeuEEmFH9EFYS9iczs241/3oA9igvCPuiSc7hoI/EOsRm4c6IhikouebRVCvX9eiZfjPSIBwXJTFHLi93r7xxNC4q3WWZZh2I01A09SOoQZPhXDXMkL6nuAJawG0wkU3JFeJecTSsk3EPgg+xX15X52Ayt7yKMRfTlYRtp45uku
> 
> (Pdb) Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter(F4)[0].get_attr_val_utf8('CN')
> 'Benjamin Hall'
> (Pdb) Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter(F4)[0].get_attr_val_utf8('cn')
> 'Benjamin Hall'
> (Pdb) Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter(F4)[0].get_attr_val_utf8('Cn')
> 'Benjamin Hall'
> 
> 
> Regards
> Anuj Borah
> 
> On Thu, May 9, 2019 at 9:00 AM Anuj Borah  wrote:
> @William Brown 
> 
> Thank you for the clarification. 
> 
> Regards
> Anuj Borah
> 
> On Thu, May 9, 2019 at 8:57 AM William Brown  wrote:
> 
> 
> > On 9 May 2019, at 12:47, Anuj Borah  wrote:
> > 
> > @William Brown
> > 
> > I am attaching the main script where i am facing the problem .
> > 
> > F4 gives me the following :
> > 
> > With search_s:
> > 
> > (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4)
> > [dn: uid=bhall,ou=People,dc=example,dc=com
> > cn: Benjamin Hall
> > gidNumber: 2000
> > givenName: Benjamin
> > homeDirectory: /home/bhall
> > l: sunnyvale
> > mail: bh...@anuj.com
> > manager: uid=trigden,ou=People,dc=example,dc=com
> > objectClass: top
> > objectClass: account
> > objectClass: posixaccount
> > objectClass: inetOrgPerson
> > objectClass: organizationalPerson
> > objectClass: nsMemberOf
> > objectClass: nsAccount
> > objectClass: person
> > ou: Product Development
> > ou: People
> > roomNumber: 2511
> > sn: Hall
> > telephoneNumber: +1 408 555 6067
> > uid: bhall
> > uidNumber: 1000
> > userPassword: 
> > {PBKDF2_SHA256}AAAIAAlpB8Yaw03XDVfXkH++eiCaugb3D660gbb6xBE3dkSCXOiCVqvM80dTPhPuSBISkY8IWJZgZXXoDt54brqRweEpqZ4YPrMTtqBAd/2kCsX+ZRM9phJLZFd9k7bIAM3joCnxVPFwyR1ETDSHkes0RSql7Isi+oKb8dloC+m5vzj1NG1M/o0TxdICTMxIBvuln+BdANOS9waGyqJgZfZBnQfw2t3lHOKXFxiduaWSZJvwVV8JtYkHt/ofdmqKItayc00eG6EM44qPS19XZa+3drTADPkL7HNAVhMHg1Y8iIWIXKvlZ7WJ1V/ySrHL6SU6XzcXtMNjBT/qi+GCHpu2Bc+Ka2C0iUZwY5ZiJ7YUANa3UYxh6oIVUgKNVmX+4CkJczJLcEgoI43zFCFnFsjtNHYwflPuIPFtwaXvgeBojItZ
> > 
> > ]
> > 
> > With filter:
> > 
> > (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(F4)[0].dn
> > 'uid=bhall,ou=People,dc=example,dc=com'
> > (Pdb) Accounts(topo.standalone, 
> > DEFAULT_SUFFIX).filter(F4)[0]._unsafe_raw_entry()
> > dn: uid=bhall,ou=People,dc=example,dc=com
> > cn: Benjamin Hall
> > gidNumber: 2000
> > givenName: Benjamin
> > homeDirectory: /home/bhall
> > l: sunnyvale
> > mail: bh...@anuj.com
> > manager: 

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

@William Brown 

Its not relevant to this subject line , but its related to lib389 .

Question : Does get_attrs_vals_utf8 and all get_attrs_vals types should
case sensitive ??

Look at bellow result:

with search_s:

(Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4,
['cn', 'Cn', 'CN'])
[dn: uid=bhall,ou=People,dc=example,dc=com
cn: Benjamin Hall
]


with filter:

(Pdb) Accounts(topo.standalone,
DEFAULT_SUFFIX).filter(F4)[0].get_attrs_vals_utf8(['cn', 'Cn', 'CN'])
{'cn': ['Benjamin Hall'], 'Cn': ['Benjamin Hall'], 'CN': ['Benjamin Hall']}
(Pdb) Accounts(topo.standalone,
DEFAULT_SUFFIX).filter(F4)[0]._unsafe_raw_entry()
dn: uid=bhall,ou=People,dc=example,dc=com
cn: Benjamin Hall
gidNumber: 2000
givenName: Benjamin
homeDirectory: /home/bhall
l: sunnyvale
mail: bh...@anuj.com
manager: uid=trigden,ou=People,dc=example,dc=com
objectClass: top
objectClass: account
objectClass: posixaccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: nsMemberOf
objectClass: nsAccount
objectClass: person
ou: Product Development
ou: People
roomNumber: 2511
sn: Hall
telephoneNumber: +1 408 555 6067
uid: bhall
uidNumber: 1000
userPassword:
{PBKDF2_SHA256}AAAIAC03kM8if/x5GVc9teHEpMTOvB67mfH6NZYEmazAev2n6eoN2X+3JKu13ZpIG+WCPGWZH0niBxc7xvvqFsMkNPoRlBvmx23fWM+5VYcTCJs+iWQRxTb0FV/hheEU9a+Tqdj6fa0lL1aJTiOkKKk/mJdAHUiRvh8M6BtZmmc3pD0KNDwHQK/k/tuP1X7+nA+6ioT5WCb2NjjR4jFuNO681Ko6nG/wAWz/T+lYsVHdFV84MfBX81dgRDGmGyAew2YwNDeuEEmFH9EFYS9iczs241/3oA9igvCPuiSc7hoI/EOsRm4c6IhikouebRVCvX9eiZfjPSIBwXJTFHLi93r7xxNC4q3WWZZh2I01A09SOoQZPhXDXMkL6nuAJawG0wkU3JFeJecTSsk3EPgg+xX15X52Ayt7yKMRfTlYRtp45uku

(Pdb) Accounts(topo.standalone,
DEFAULT_SUFFIX).filter(F4)[0].get_attr_val_utf8('CN')
'Benjamin Hall'
(Pdb) Accounts(topo.standalone,
DEFAULT_SUFFIX).filter(F4)[0].get_attr_val_utf8('cn')
'Benjamin Hall'
(Pdb) Accounts(topo.standalone,
DEFAULT_SUFFIX).filter(F4)[0].get_attr_val_utf8('Cn')
'Benjamin Hall'


Regards
Anuj Borah

On Thu, May 9, 2019 at 9:00 AM Anuj Borah  wrote:

> @William Brown 
>
> Thank you for the clarification.
>
> Regards
> Anuj Borah
>
> On Thu, May 9, 2019 at 8:57 AM William Brown  wrote:
>
>>
>>
>> > On 9 May 2019, at 12:47, Anuj Borah  wrote:
>> >
>> > @William Brown
>> >
>> > I am attaching the main script where i am facing the problem .
>> >
>> > F4 gives me the following :
>> >
>> > With search_s:
>> >
>> > (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4)
>> > [dn: uid=bhall,ou=People,dc=example,dc=com
>> > cn: Benjamin Hall
>> > gidNumber: 2000
>> > givenName: Benjamin
>> > homeDirectory: /home/bhall
>> > l: sunnyvale
>> > mail: bh...@anuj.com
>> > manager: uid=trigden,ou=People,dc=example,dc=com
>> > objectClass: top
>> > objectClass: account
>> > objectClass: posixaccount
>> > objectClass: inetOrgPerson
>> > objectClass: organizationalPerson
>> > objectClass: nsMemberOf
>> > objectClass: nsAccount
>> > objectClass: person
>> > ou: Product Development
>> > ou: People
>> > roomNumber: 2511
>> > sn: Hall
>> > telephoneNumber: +1 408 555 6067
>> > uid: bhall
>> > uidNumber: 1000
>> > userPassword:
>> {PBKDF2_SHA256}AAAIAAlpB8Yaw03XDVfXkH++eiCaugb3D660gbb6xBE3dkSCXOiCVqvM80dTPhPuSBISkY8IWJZgZXXoDt54brqRweEpqZ4YPrMTtqBAd/2kCsX+ZRM9phJLZFd9k7bIAM3joCnxVPFwyR1ETDSHkes0RSql7Isi+oKb8dloC+m5vzj1NG1M/o0TxdICTMxIBvuln+BdANOS9waGyqJgZfZBnQfw2t3lHOKXFxiduaWSZJvwVV8JtYkHt/ofdmqKItayc00eG6EM44qPS19XZa+3drTADPkL7HNAVhMHg1Y8iIWIXKvlZ7WJ1V/ySrHL6SU6XzcXtMNjBT/qi+GCHpu2Bc+Ka2C0iUZwY5ZiJ7YUANa3UYxh6oIVUgKNVmX+4CkJczJLcEgoI43zFCFnFsjtNHYwflPuIPFtwaXvgeBojItZ
>> >
>> > ]
>> >
>> > With filter:
>> >
>> > (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(F4)[0].dn
>> > 'uid=bhall,ou=People,dc=example,dc=com'
>> > (Pdb) Accounts(topo.standalone,
>> DEFAULT_SUFFIX).filter(F4)[0]._unsafe_raw_entry()
>> > dn: uid=bhall,ou=People,dc=example,dc=com
>> > cn: Benjamin Hall
>> > gidNumber: 2000
>> > givenName: Benjamin
>> > homeDirectory: /home/bhall
>> > l: sunnyvale
>> > mail: bh...@anuj.com
>> > manager: uid=trigden,ou=People,dc=example,dc=com
>> > objectClass: top
>> > objectClass: account
>> > objectClass: posixaccount
>> > objectClass: inetOrgPerson
>> > objectClass: organizationalPerson
>> > objectClass: nsMemberOf
>> > objectClass: nsAccount
>> > objectClass: person
>> > ou: Product Development
>> > ou: People
>> > roomNumber: 2511
>> > sn: Hall
>> > telephoneNumber: +1 408 555 6067
>> > uid: bhall
>> > uidNumber: 1000
>> > userPassword:
>> {PBKDF2_SHA256}AAAIAAlpB8Yaw03XDVfXkH++eiCaugb3D660gbb6xBE3dkSCXOiCVqvM80dTPhPuSBISkY8IWJZgZXXoDt54brqRweEpqZ4YPrMTtqBAd/2kCsX+ZRM9phJLZFd9k7bIAM3joCnxVPFwyR1ETDSHkes0RSql7Isi+oKb8dloC+m5vzj1NG1M/o0TxdICTMxIBvuln+BdANOS9waGyqJgZfZBnQfw2t3lHOKXFxiduaWSZJvwVV8JtYkHt/ofdmqKItayc00eG6EM44qPS19XZa+3drTADPkL7HNAVhMHg1Y8iIWIXKvlZ7WJ1V/ySrHL6SU6XzcXtMNjBT/qi+GCHpu2Bc+Ka2C0iUZwY5ZiJ7YUANa3UYxh6oIVUgKNVmX+4CkJczJLcEgoI43zFCFnFsjtNHYwflPuIPFtwaXvgeBojItZ
>> >
>> > Now consider the following condition ,
>> >
>> > (Pdb) 

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

@William Brown 

Thank you for the clarification.

Regards
Anuj Borah

On Thu, May 9, 2019 at 8:57 AM William Brown  wrote:

>
>
> > On 9 May 2019, at 12:47, Anuj Borah  wrote:
> >
> > @William Brown
> >
> > I am attaching the main script where i am facing the problem .
> >
> > F4 gives me the following :
> >
> > With search_s:
> >
> > (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4)
> > [dn: uid=bhall,ou=People,dc=example,dc=com
> > cn: Benjamin Hall
> > gidNumber: 2000
> > givenName: Benjamin
> > homeDirectory: /home/bhall
> > l: sunnyvale
> > mail: bh...@anuj.com
> > manager: uid=trigden,ou=People,dc=example,dc=com
> > objectClass: top
> > objectClass: account
> > objectClass: posixaccount
> > objectClass: inetOrgPerson
> > objectClass: organizationalPerson
> > objectClass: nsMemberOf
> > objectClass: nsAccount
> > objectClass: person
> > ou: Product Development
> > ou: People
> > roomNumber: 2511
> > sn: Hall
> > telephoneNumber: +1 408 555 6067
> > uid: bhall
> > uidNumber: 1000
> > userPassword:
> {PBKDF2_SHA256}AAAIAAlpB8Yaw03XDVfXkH++eiCaugb3D660gbb6xBE3dkSCXOiCVqvM80dTPhPuSBISkY8IWJZgZXXoDt54brqRweEpqZ4YPrMTtqBAd/2kCsX+ZRM9phJLZFd9k7bIAM3joCnxVPFwyR1ETDSHkes0RSql7Isi+oKb8dloC+m5vzj1NG1M/o0TxdICTMxIBvuln+BdANOS9waGyqJgZfZBnQfw2t3lHOKXFxiduaWSZJvwVV8JtYkHt/ofdmqKItayc00eG6EM44qPS19XZa+3drTADPkL7HNAVhMHg1Y8iIWIXKvlZ7WJ1V/ySrHL6SU6XzcXtMNjBT/qi+GCHpu2Bc+Ka2C0iUZwY5ZiJ7YUANa3UYxh6oIVUgKNVmX+4CkJczJLcEgoI43zFCFnFsjtNHYwflPuIPFtwaXvgeBojItZ
> >
> > ]
> >
> > With filter:
> >
> > (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(F4)[0].dn
> > 'uid=bhall,ou=People,dc=example,dc=com'
> > (Pdb) Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter(F4)[0]._unsafe_raw_entry()
> > dn: uid=bhall,ou=People,dc=example,dc=com
> > cn: Benjamin Hall
> > gidNumber: 2000
> > givenName: Benjamin
> > homeDirectory: /home/bhall
> > l: sunnyvale
> > mail: bh...@anuj.com
> > manager: uid=trigden,ou=People,dc=example,dc=com
> > objectClass: top
> > objectClass: account
> > objectClass: posixaccount
> > objectClass: inetOrgPerson
> > objectClass: organizationalPerson
> > objectClass: nsMemberOf
> > objectClass: nsAccount
> > objectClass: person
> > ou: Product Development
> > ou: People
> > roomNumber: 2511
> > sn: Hall
> > telephoneNumber: +1 408 555 6067
> > uid: bhall
> > uidNumber: 1000
> > userPassword:
> {PBKDF2_SHA256}AAAIAAlpB8Yaw03XDVfXkH++eiCaugb3D660gbb6xBE3dkSCXOiCVqvM80dTPhPuSBISkY8IWJZgZXXoDt54brqRweEpqZ4YPrMTtqBAd/2kCsX+ZRM9phJLZFd9k7bIAM3joCnxVPFwyR1ETDSHkes0RSql7Isi+oKb8dloC+m5vzj1NG1M/o0TxdICTMxIBvuln+BdANOS9waGyqJgZfZBnQfw2t3lHOKXFxiduaWSZJvwVV8JtYkHt/ofdmqKItayc00eG6EM44qPS19XZa+3drTADPkL7HNAVhMHg1Y8iIWIXKvlZ7WJ1V/ySrHL6SU6XzcXtMNjBT/qi+GCHpu2Bc+Ka2C0iUZwY5ZiJ7YUANa3UYxh6oIVUgKNVmX+4CkJczJLcEgoI43zFCFnFsjtNHYwflPuIPFtwaXvgeBojItZ
> >
> > Now consider the following condition ,
> >
> > (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
> F4,['modifiersName','modifyTimestamp'])
> > [dn: uid=bhall,ou=People,dc=example,dc=com
> > modifiersName: cn=directory manager
> > modifyTimestamp: 20190509030743Z
> >
> > ]
> >
> > Problem is :
> > modifiersName and modifyTimestamp can never get with filter .
>
>
> This is not the fault of the filter, but the fault of how you are treating
> these objects. Filter tells you *what entries to find* not what attributes
> to get from them. To get specific attributes you have to interact with the
> results of the filter search.
>
> I have formerly mentioned you can assign the results of searches such as:
>
> bhall_account = Accounts(...).filter(F4)[0]
>
> bhall_account is now an Instance of the Account object, which itself is
> DSLdapObject. Now you have the entry, you can access attributes of it.
>
> values =
> bhall_account.get_attrs_vals_utf8(['modifiersName','modifyTimestamp'])
> print(values)
>
> Should be:
>
> {
>"modifiersName": '...',
>"modifyTimestamp": '...',
> }
>
> I don't know why you still are afraid to assign results from the searches.
> Fundamentally: DSLdapObjects (and it's subclasses) is the SET of all
> possible entries, and the gateway to searching. It returns instances of
> DSLdapObject, that allow direct inspection and manipulation of that
> data from the entry. I am worried that there is a still a deep
> misunderstanding of the API and how to use it, which is causing these
> problems (and odd accusations ...) and I don't understand how to explain it
> or help you to get past this barrier because this topic has been circled
> and discussed for months. How can I help you to understand how to use this
> properly and correctly?
>
>
> PS: There is a reason that function has the word "unsafe" in it, so please
> don't use things marked unsafe in tests or code  :(
>
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
>
>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 

[389-devel] Re: Groups are not accessible by filter

[William Brown]

> On 7 May 2019, at 22:35, Ludwig Krispenz  wrote:
> 
> 
> On 05/07/2019 02:08 PM, William Brown wrote:
>> 
>>> On 7 May 2019, at 22:03, Viktor Ashirov  wrote:
>>> 
>>> On Mon, Apr 29, 2019 at 6:48 AM William Brown  wrote:
 
 
> On 29 Apr 2019, at 12:33, Anuj Borah  wrote:
> 
> @William Brown
> 
> Thanks for the tip!
> 
> (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX, 
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
>  ['attrlist=cn:sn:uid:testUserAccountControl']))
> 6
> (Pdb) len(Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
> 6
> 
> We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with 
> filter , like we do with search_s .
> 
> (Pdb) len(Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
>  ['attrlist=cn:sn:uid:testUserAccountControl']))
> *** TypeError: filter() takes 2 positional arguments but 3 were given
> (Pdb) len(Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
>  ['attrlist=cn:sn:uid:testUserAccountControl']"))
> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 
> 'No such file or directory'}
> 
> Again i have to use "re" module for the same .
> 
> 
 What are you trying to achieve?
>>> Test case is very simple: search for entries using different filters
>>> and request specific attributes.
>> But those entries have types and classes - you know what you are expecting 
>> to get.
>> 
>>> The problem that Anuj is facing is that filter() doesn't support
>>> attrlist. Moreover, _unsafe_raw_entry() doesn't return *all*
>>> attributes, it omits operational attributes (like nsRoleDN).
>>> IMHO, search_s is good enough here.
>> If you want to avoid any of the "magic" use DSLdapObjects(instance).filter() 
>> then because that doesn't prescribe any classes. But it does take a lot of 
>> the safety out of the library, and I still think that there is something 
>> missing in the approach here.
> but we are testing ldap clients and need to be able to do anything the 
> protocol allows, not only what you declare safe

And there are still ways to do that, you can use search_s if you mark that you 
are aware it's not safe. And in many cases, the tests being written don't need 
that kind of access, which is why I keep asking what he's trying to achieve. 

Half the issue isn't the safety, it's the huge amount of techdebt inside of 
DirSrv and Entry that are problems to the framework, and violate good python 
design.




>> 
>> 
 
 Sincerely,
 
 William Brown
 
 Senior Software Engineer, 389 Directory Server
 SUSE Labs
 ___
 389-devel mailing list -- 389-devel@lists.fedoraproject.org
 To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
 Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
 List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
 List Archives: 
 https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>>> 
>>> 
>>> --
>>> Viktor
>>> ___
>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>> —
>> Sincerely,
>> 
>> William Brown
>> 
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs
>> ___
>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> 
> -- 
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, 
> Eric Shander
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> 

[389-devel] Re: Groups are not accessible by filter

[William Brown]

> On 7 May 2019, at 23:56, Viktor Ashirov  wrote:
> 
> On Tue, May 7, 2019 at 2:09 PM William Brown  wrote:
>> 
>> 
>> 
>>> On 7 May 2019, at 22:03, Viktor Ashirov  wrote:
>>> 
>>> On Mon, Apr 29, 2019 at 6:48 AM William Brown  wrote:
 
 
 
> On 29 Apr 2019, at 12:33, Anuj Borah  wrote:
> 
> @William Brown
> 
> Thanks for the tip!
> 
> (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX, 
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
>  ['attrlist=cn:sn:uid:testUserAccountControl']))
> 6
> (Pdb) len(Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
> 6
> 
> We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with 
> filter , like we do with search_s .
> 
> (Pdb) len(Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
>  ['attrlist=cn:sn:uid:testUserAccountControl']))
> *** TypeError: filter() takes 2 positional arguments but 3 were given
> (Pdb) len(Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
>  ['attrlist=cn:sn:uid:testUserAccountControl']"))
> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 
> 'No such file or directory'}
> 
> Again i have to use "re" module for the same .
> 
> 
 
 What are you trying to achieve?
>>> Test case is very simple: search for entries using different filters
>>> and request specific attributes.
>> 
>> But those entries have types and classes - you know what you are expecting 
>> to get.
>> 
>>> The problem that Anuj is facing is that filter() doesn't support
>>> attrlist. Moreover, _unsafe_raw_entry() doesn't return *all*
>>> attributes, it omits operational attributes (like nsRoleDN).
>>> IMHO, search_s is good enough here.
>> 
>> If you want to avoid any of the "magic" use DSLdapObjects(instance).filter() 
>> then because that doesn't prescribe any classes. But it does take a lot of 
>> the safety out of the library, and I still think that there is something 
>> missing in the approach here.
> I have a problem with DSLdapObjects(instance).filter() is that it
> takes way more effort to write *test* code with a very little benefit.
> Consider this example: I need to fetch all regular attributes,
> operational attributes and entry state information from the server.
> With DSLdapObjects I had to do the following:
> (Pdb) _ = Accounts(topo.standalone, DEFAULT_SUFFIX)
> (Pdb) _._filterattrs=["*", "+", "nscpEntryWSI"]
> (Pdb) _.filter(F10)[0].get_all_attrs()
> 
> get_all_attrs() doesn't return nscpEntryWSI at all, and, as a bonus,
> lowercases some of the attribute names.
> 
> vs.
> 
> (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
> attrlist=["*", "+", "nscpEntryWSI"])
> 
> Safety here is not a main concern, since it's a test code. In tests we
> need more than often to have a raw LDAP access without too much
> abstractions. Main concern is precision and certainty.
> Abstractions are good when they increase clarity and make things
> certain. In case of the very common search pattern above, DSLdapObject
> doesn't work really well. For me at least.

And that's fine, search_s can still work - the issue here is that Anuj has not 
articulated what he's trying to achieve, and has previously misunderstood the 
api :(. So honestly, I need to see this in a test case, with proper code 
structures to comment more.

The main reason to avoid search_s is that today in DirSrv it uses a really 
horrid hack to get Entry, which I have wanted to purge with fire for a long 
time - so the main reason to minimise it's use is to limit damage when I do 
eventually change that api.


>> 
>> 
 
 
 Sincerely,
 
 William Brown
 
 Senior Software Engineer, 389 Directory Server
 SUSE Labs
 ___
 389-devel mailing list -- 389-devel@lists.fedoraproject.org
 To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
 Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
 List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
 List Archives: 
 https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>>> 
>>> 
>>> 
>>> --
>>> Viktor
>>> ___
>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>> 
>> —
>> Sincerely,
>> 
>> William Brown
>> 
>> Senior Software 

[389-devel] Re: Groups are not accessible by filter

[Viktor Ashirov]

On Tue, May 7, 2019 at 2:09 PM William Brown  wrote:
>
>
>
> > On 7 May 2019, at 22:03, Viktor Ashirov  wrote:
> >
> > On Mon, Apr 29, 2019 at 6:48 AM William Brown  wrote:
> >>
> >>
> >>
> >>> On 29 Apr 2019, at 12:33, Anuj Borah  wrote:
> >>>
> >>> @William Brown
> >>>
> >>> Thanks for the tip!
> >>>
> >>> (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX, 
> >>> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> >>>  ['attrlist=cn:sn:uid:testUserAccountControl']))
> >>> 6
> >>> (Pdb) len(Accounts(topo.standalone, 
> >>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
> >>> 6
> >>>
> >>> We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with 
> >>> filter , like we do with search_s .
> >>>
> >>> (Pdb) len(Accounts(topo.standalone, 
> >>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> >>>  ['attrlist=cn:sn:uid:testUserAccountControl']))
> >>> *** TypeError: filter() takes 2 positional arguments but 3 were given
> >>> (Pdb) len(Accounts(topo.standalone, 
> >>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> >>>  ['attrlist=cn:sn:uid:testUserAccountControl']"))
> >>> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 
> >>> 'No such file or directory'}
> >>>
> >>> Again i have to use "re" module for the same .
> >>>
> >>>
> >>
> >> What are you trying to achieve?
> > Test case is very simple: search for entries using different filters
> > and request specific attributes.
>
> But those entries have types and classes - you know what you are expecting to 
> get.
>
> > The problem that Anuj is facing is that filter() doesn't support
> > attrlist. Moreover, _unsafe_raw_entry() doesn't return *all*
> > attributes, it omits operational attributes (like nsRoleDN).
> > IMHO, search_s is good enough here.
>
> If you want to avoid any of the "magic" use DSLdapObjects(instance).filter() 
> then because that doesn't prescribe any classes. But it does take a lot of 
> the safety out of the library, and I still think that there is something 
> missing in the approach here.
I have a problem with DSLdapObjects(instance).filter() is that it
takes way more effort to write *test* code with a very little benefit.
Consider this example: I need to fetch all regular attributes,
operational attributes and entry state information from the server.
With DSLdapObjects I had to do the following:
(Pdb) _ = Accounts(topo.standalone, DEFAULT_SUFFIX)
(Pdb) _._filterattrs=["*", "+", "nscpEntryWSI"]
(Pdb) _.filter(F10)[0].get_all_attrs()

get_all_attrs() doesn't return nscpEntryWSI at all, and, as a bonus,
lowercases some of the attribute names.

vs.

(Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
attrlist=["*", "+", "nscpEntryWSI"])

Safety here is not a main concern, since it's a test code. In tests we
need more than often to have a raw LDAP access without too much
abstractions. Main concern is precision and certainty.
Abstractions are good when they increase clarity and make things
certain. In case of the very common search pattern above, DSLdapObject
doesn't work really well. For me at least.
>
>
> >>
> >>
> >> Sincerely,
> >>
> >> William Brown
> >>
> >> Senior Software Engineer, 389 Directory Server
> >> SUSE Labs
> >> ___
> >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> >> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: 
> >> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> >
> >
> >
> > --
> > Viktor
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org



-- 
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of 

[389-devel] Re: Groups are not accessible by filter

[Ludwig Krispenz]

On 05/07/2019 02:08 PM, William Brown wrote:



On 7 May 2019, at 22:03, Viktor Ashirov  wrote:

On Mon, Apr 29, 2019 at 6:48 AM William Brown  wrote:




On 29 Apr 2019, at 12:33, Anuj Borah  wrote:

@William Brown

Thanks for the tip!

(Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX, 
ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608", 
['attrlist=cn:sn:uid:testUserAccountControl']))
6
(Pdb) len(Accounts(topo.standalone, 
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
6

We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with filter , 
like we do with search_s .

(Pdb) len(Accounts(topo.standalone, 
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
 ['attrlist=cn:sn:uid:testUserAccountControl']))
*** TypeError: filter() takes 2 positional arguments but 3 were given
(Pdb) len(Accounts(topo.standalone, 
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608), 
['attrlist=cn:sn:uid:testUserAccountControl']"))
*** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 'No 
such file or directory'}

Again i have to use "re" module for the same .



What are you trying to achieve?

Test case is very simple: search for entries using different filters
and request specific attributes.

But those entries have types and classes - you know what you are expecting to 
get.


The problem that Anuj is facing is that filter() doesn't support
attrlist. Moreover, _unsafe_raw_entry() doesn't return *all*
attributes, it omits operational attributes (like nsRoleDN).
IMHO, search_s is good enough here.

If you want to avoid any of the "magic" use DSLdapObjects(instance).filter() 
then because that doesn't prescribe any classes. But it does take a lot of the safety out 
of the library, and I still think that there is something missing in the approach here.
but we are testing ldap clients and need to be able to do anything the 
protocol allows, not only what you declare safe





Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org



--
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[William Brown]

> On 7 May 2019, at 22:03, Viktor Ashirov  wrote:
> 
> On Mon, Apr 29, 2019 at 6:48 AM William Brown  wrote:
>> 
>> 
>> 
>>> On 29 Apr 2019, at 12:33, Anuj Borah  wrote:
>>> 
>>> @William Brown
>>> 
>>> Thanks for the tip!
>>> 
>>> (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX, 
>>> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
>>>  ['attrlist=cn:sn:uid:testUserAccountControl']))
>>> 6
>>> (Pdb) len(Accounts(topo.standalone, 
>>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
>>> 6
>>> 
>>> We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with 
>>> filter , like we do with search_s .
>>> 
>>> (Pdb) len(Accounts(topo.standalone, 
>>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
>>>  ['attrlist=cn:sn:uid:testUserAccountControl']))
>>> *** TypeError: filter() takes 2 positional arguments but 3 were given
>>> (Pdb) len(Accounts(topo.standalone, 
>>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
>>>  ['attrlist=cn:sn:uid:testUserAccountControl']"))
>>> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 
>>> 'No such file or directory'}
>>> 
>>> Again i have to use "re" module for the same .
>>> 
>>> 
>> 
>> What are you trying to achieve?
> Test case is very simple: search for entries using different filters
> and request specific attributes.

But those entries have types and classes - you know what you are expecting to 
get.

> The problem that Anuj is facing is that filter() doesn't support
> attrlist. Moreover, _unsafe_raw_entry() doesn't return *all*
> attributes, it omits operational attributes (like nsRoleDN).
> IMHO, search_s is good enough here.

If you want to avoid any of the "magic" use DSLdapObjects(instance).filter() 
then because that doesn't prescribe any classes. But it does take a lot of the 
safety out of the library, and I still think that there is something missing in 
the approach here. 


>> 
>> 
>> Sincerely,
>> 
>> William Brown
>> 
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs
>> ___
>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> 
> 
> 
> --
> Viktor
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[Viktor Ashirov]

On Mon, Apr 29, 2019 at 6:48 AM William Brown  wrote:
>
>
>
> > On 29 Apr 2019, at 12:33, Anuj Borah  wrote:
> >
> > @William Brown
> >
> > Thanks for the tip!
> >
> > (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX, 
> > ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> >  ['attrlist=cn:sn:uid:testUserAccountControl']))
> > 6
> > (Pdb) len(Accounts(topo.standalone, 
> > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
> > 6
> >
> > We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with 
> > filter , like we do with search_s .
> >
> > (Pdb) len(Accounts(topo.standalone, 
> > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> >  ['attrlist=cn:sn:uid:testUserAccountControl']))
> > *** TypeError: filter() takes 2 positional arguments but 3 were given
> > (Pdb) len(Accounts(topo.standalone, 
> > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> >  ['attrlist=cn:sn:uid:testUserAccountControl']"))
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 
> > 'No such file or directory'}
> >
> > Again i have to use "re" module for the same .
> >
> >
>
> What are you trying to achieve?
Test case is very simple: search for entries using different filters
and request specific attributes.
The problem that Anuj is facing is that filter() doesn't support
attrlist. Moreover, _unsafe_raw_entry() doesn't return *all*
attributes, it omits operational attributes (like nsRoleDN).
IMHO, search_s is good enough here.
>
>
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org



--
Viktor
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

Ok, I will check.

Thanks

On Tue, May 7, 2019 at 8:21 AM William Brown  wrote:

>
> > On 7 May 2019, at 11:31, Anuj Borah  wrote:
> >
> > @William Brown
> >
> > Actually my concern was as bellow:
> >
> > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4, ['cn',
> 'cn', 'cn'])
> > >>[dn: uid=bhall,ou=People,dc=example,dc=com
> > cn: Benjamin Hall
> >
> > ]
> >
> > Question:  Can we use these filter directly in filter module. --->>
>  like Accounts().filter(F4, ['cn', 'cn', 'cn'])
> >
> > As this works :
> > (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(F4)
> > []
> >
> > But this does not work:
> > (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter((&(F4)(['cn',
> 'cn', 'cn'])))
> > *** SyntaxError: invalid syntax
>
> ^ it says invalid syntax because your F4, (...) is not vaild. You should
> rethink this part of the statement ...
>
> >
> >
> > And these filter as bellow.
> >
> > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F10,
> ['mailquota', 'nsRoleDN'])
> > >> [dn: uid=mtyler,ou=People,dc=example,dc=com
> > mailquota: 600
> > nsRoleDN: cn=new managed role,ou=People,dc=example,dc=com
> >
> > ]
> >
> > Question these filter also:   Accounts(...).filter(F10,
> ['mailquota', 'nsRoleDN'])
>
> As above.
>
> Try doing:
>
> next_filter = F4, (...)
> Account(...).filter(next_filter).
>
> Is that valid? Why? Why not? What do you need to do to make it valid?
>
> >
> > Regards
> > Anuj Borah
> >
> > On Tue, May 7, 2019 at 5:22 AM William Brown  wrote:
> > You are missing a key part of the question again: "Is there any chance
> we can use these filters TO GET lib389 objects of the type X".
> >
> > So for example:
> >
> > > On 3 May 2019, at 17:12, Anuj Borah  wrote:
> > >
> > > @William Brown
> > >
> > > Are there any chance we can use these filter with filter module
> directly .
> > >
> > > F1 = "(sn=Hall)"
> >
> > If you do:
> >
> > Groups(...).filter("sn=hall")
> >
> > No because it doesn't make sense for a group to match this.
> >
> > If you did:
> >
> > Person(...).filter("sn=hall")
> >
> > Yes! it would work.
> >
> > > F2 = "(nsRoleDN=cn=new managed role)"
> >
> > Groups(...).filter(nsRoleDn=...)
> >
> > Again, doesn't make sense. But:
> >
> > Accounts(...).filter(nsRoleDn=...)
> >
> > Would make sense, to show all Accounts that are part of the role.
> >
> > > F3 = "(l=sunnyvale)"
> >
> > Here, l= would make sense on things like:
> >
> > OrganisationUnits().filter("l=...")
> > Person("l=...")
> >
> > > F4 = "(& (| {} {}) {})".format(F2, F1, F3)
> > > F10 = "(& {} {})".format(F6, F9)
> >
> > Provdide the type you WANT would satisfy these conditions, yes.
> >
> > But you would be better to do:
> >
> > F4 = (&(cond)(cond)(cond))
> >
> > Rather than str sub. Alternately, use gen_filter.
> >
> >
> >
> > So again - you are missing a key element of the question, which is "is
> this filter suitable to get objects of the type I need to work with".
> Lib389 doesn't think like "just search and get generic things" it thinks as
> "search and get strongly typed objects".
> >
> > >
> > > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4,
> ['cn', 'cn', 'cn'])
> > > >>[dn: uid=bhall,ou=People,dc=example,dc=com
> > > cn: Benjamin Hall
> > >
> > > ]
> > >
> > > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F10,
> ['mailquota', 'nsRoleDN'])
> > > >> [dn: uid=mtyler,ou=People,dc=example,dc=com
> > > mailquota: 600
> > > nsRoleDN: cn=new managed role,ou=People,dc=example,dc=com
> > >
> > > ]
> > >
> > > Regards
> > > Anuj Borah
> > >
> > > On Mon, Apr 29, 2019 at 12:29 PM Anuj Borah  wrote:
> > > Yes, it is.
> > >
> > > On Mon, Apr 29, 2019 at 11:17 AM William Brown  wrote:
> > >
> > >
> > > > On 29 Apr 2019, at 15:00, Anuj Borah  wrote:
> > > >
> > > > @William Brown
> > > >
> > > > Sorry my bad , syntax was wrong .
> > > >
> > > > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
> ['attrlist=cn:sn:uid:testUserAccountControl'])"))
> > > > 6
> > > >
> > > > Thanks .
> > > >
> > > >
> > > > On Mon, Apr 29, 2019 at 10:26 AM Anuj Borah 
> wrote:
> > > > @William Brown
> > > >
> > > > This is the filter :
> "testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl']
> > > >
> > > > len(topo.standalone.search_s(DEFAULT_SUFFIX,
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
> > > > > 6
> > > >
> > > > But the full filter does not fit with filter module .
> > > >
> > > > > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> > > > > *** TypeError: filter() takes 2 positional arguments but 3 were
> given
> > > > > (Pdb) len(Accounts(topo.standalone,
> 

[389-devel] Re: Groups are not accessible by filter

[William Brown]

> On 7 May 2019, at 11:31, Anuj Borah  wrote:
> 
> @William Brown
>  
> Actually my concern was as bellow:
> 
> topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4, ['cn', 'cn', 
> 'cn'])
> >>[dn: uid=bhall,ou=People,dc=example,dc=com
> cn: Benjamin Hall
> 
> ]
> 
> Question:  Can we use these filter directly in filter module. --->>   like 
> Accounts().filter(F4, ['cn', 'cn', 'cn'])
> 
> As this works :   
> (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(F4)
> []
> 
> But this does not work:
> (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter((&(F4)(['cn', 'cn', 
> 'cn'])))
> *** SyntaxError: invalid syntax

^ it says invalid syntax because your F4, (...) is not vaild. You should 
rethink this part of the statement ... 

> 
> 
> And these filter as bellow.
> 
> topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F10, 
> ['mailquota', 'nsRoleDN'])
> >> [dn: uid=mtyler,ou=People,dc=example,dc=com
> mailquota: 600
> nsRoleDN: cn=new managed role,ou=People,dc=example,dc=com
> 
> ]
> 
> Question these filter also:   Accounts(...).filter(F10, ['mailquota', 
> 'nsRoleDN'])

As above.

Try doing:

next_filter = F4, (...)
Account(...).filter(next_filter).

Is that valid? Why? Why not? What do you need to do to make it valid? 

> 
> Regards
> Anuj Borah
> 
> On Tue, May 7, 2019 at 5:22 AM William Brown  wrote:
> You are missing a key part of the question again: "Is there any chance we can 
> use these filters TO GET lib389 objects of the type X".
> 
> So for example:
> 
> > On 3 May 2019, at 17:12, Anuj Borah  wrote:
> > 
> > @William Brown
> > 
> > Are there any chance we can use these filter with filter module directly .
> > 
> > F1 = "(sn=Hall)"
> 
> If you do:
> 
> Groups(...).filter("sn=hall")
> 
> No because it doesn't make sense for a group to match this.
> 
> If you did:
> 
> Person(...).filter("sn=hall")
> 
> Yes! it would work. 
> 
> > F2 = "(nsRoleDN=cn=new managed role)"
> 
> Groups(...).filter(nsRoleDn=...)
> 
> Again, doesn't make sense. But:
> 
> Accounts(...).filter(nsRoleDn=...)
> 
> Would make sense, to show all Accounts that are part of the role.
> 
> > F3 = "(l=sunnyvale)"
> 
> Here, l= would make sense on things like:
> 
> OrganisationUnits().filter("l=...")
> Person("l=...")
> 
> > F4 = "(& (| {} {}) {})".format(F2, F1, F3)
> > F10 = "(& {} {})".format(F6, F9)
> 
> Provdide the type you WANT would satisfy these conditions, yes.
> 
> But you would be better to do:
> 
> F4 = (&(cond)(cond)(cond))
> 
> Rather than str sub. Alternately, use gen_filter. 
> 
> 
> 
> So again - you are missing a key element of the question, which is "is this 
> filter suitable to get objects of the type I need to work with". Lib389 
> doesn't think like "just search and get generic things" it thinks as "search 
> and get strongly typed objects". 
> 
> > 
> > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4, ['cn', 
> > 'cn', 'cn'])
> > >>[dn: uid=bhall,ou=People,dc=example,dc=com
> > cn: Benjamin Hall
> > 
> > ]
> > 
> > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F10, 
> > ['mailquota', 'nsRoleDN'])
> > >> [dn: uid=mtyler,ou=People,dc=example,dc=com
> > mailquota: 600
> > nsRoleDN: cn=new managed role,ou=People,dc=example,dc=com
> > 
> > ]
> > 
> > Regards
> > Anuj Borah
> > 
> > On Mon, Apr 29, 2019 at 12:29 PM Anuj Borah  wrote:
> > Yes, it is. 
> > 
> > On Mon, Apr 29, 2019 at 11:17 AM William Brown  wrote:
> > 
> > 
> > > On 29 Apr 2019, at 15:00, Anuj Borah  wrote:
> > > 
> > > @William Brown 
> > > 
> > > Sorry my bad , syntax was wrong .
> > > 
> > > (Pdb) len(Accounts(topo.standalone, 
> > > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
> > >  ['attrlist=cn:sn:uid:testUserAccountControl'])"))
> > > 6
> > > 
> > > Thanks .
> > > 
> > > 
> > > On Mon, Apr 29, 2019 at 10:26 AM Anuj Borah  wrote:
> > > @William Brown 
> > > 
> > > This is the filter :
> > > "testUserAccountControl:1.2.840.113556.1.4.803:=8388608", 
> > > ['attrlist=cn:sn:uid:testUserAccountControl']
> > > 
> > > len(topo.standalone.search_s(DEFAULT_SUFFIX, 
> > > ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> > >  ['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
> > > > 6
> > > 
> > > But the full filter does not fit with filter module .
> > > 
> > > > (Pdb) len(Accounts(topo.standalone, 
> > > > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> > > >  ['attrlist=cn:sn:uid:testUserAccountControl']))
> > > > *** TypeError: filter() takes 2 positional arguments but 3 were given
> > > > (Pdb) len(Accounts(topo.standalone, 
> > > > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> > > >  ['attrlist=cn:sn:uid:testUserAccountControl']"))
> > > > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 
> > > > 'info': 'No such file or directory'}
> > > 
> > > 
> > > Regards
> > > Anuj Borah
> > > 
> > 
> > That 

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

@William Brown 

Are there any chance we can use these filter with filter module directly .

F1 = "(sn=Hall)"
F2 = "(nsRoleDN=cn=new managed role)"
F3 = "(l=sunnyvale)"
F4 = "(& (| {} {}) {})".format(F2, F1, F3)
F10 = "(& {} {})".format(F6, F9)

topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4, ['cn',
'cn', 'cn'])
>>[dn: uid=bhall,ou=People,dc=example,dc=com
cn: Benjamin Hall

]

topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F10,
['mailquota', 'nsRoleDN'])
>> [dn: uid=mtyler,ou=People,dc=example,dc=com
mailquota: 600
nsRoleDN: cn=new managed role,ou=People,dc=example,dc=com

]

Regards
Anuj Borah

On Mon, Apr 29, 2019 at 12:29 PM Anuj Borah  wrote:

> Yes, it is.
>
> On Mon, Apr 29, 2019 at 11:17 AM William Brown  wrote:
>
>>
>>
>> > On 29 Apr 2019, at 15:00, Anuj Borah  wrote:
>> >
>> > @William Brown
>> >
>> > Sorry my bad , syntax was wrong .
>> >
>> > (Pdb) len(Accounts(topo.standalone,
>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
>> ['attrlist=cn:sn:uid:testUserAccountControl'])"))
>> > 6
>> >
>> > Thanks .
>> >
>> >
>> > On Mon, Apr 29, 2019 at 10:26 AM Anuj Borah  wrote:
>> > @William Brown
>> >
>> > This is the filter :
>> "testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
>> ['attrlist=cn:sn:uid:testUserAccountControl']
>> >
>> > len(topo.standalone.search_s(DEFAULT_SUFFIX,
>> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
>> ['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
>> > > 6
>> >
>> > But the full filter does not fit with filter module .
>> >
>> > > (Pdb) len(Accounts(topo.standalone,
>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
>> ['attrlist=cn:sn:uid:testUserAccountControl']))
>> > > *** TypeError: filter() takes 2 positional arguments but 3 were given
>> > > (Pdb) len(Accounts(topo.standalone,
>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
>> ['attrlist=cn:sn:uid:testUserAccountControl']"))
>> > > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2,
>> 'info': 'No such file or directory'}
>> >
>> >
>> > Regards
>> > Anuj Borah
>> >
>>
>> That filter string seems really … uhh, interesting. You are testing:
>>
>> (testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
>> ['attrlist=cn:sn:uid:testUserAccountControl’])
>>
>> Is that really a valid filter?
>>
>>
>> —
>> Sincerely,
>>
>> William Brown
>>
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs
>>
>>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

Yes, it is.

On Mon, Apr 29, 2019 at 11:17 AM William Brown  wrote:

>
>
> > On 29 Apr 2019, at 15:00, Anuj Borah  wrote:
> >
> > @William Brown
> >
> > Sorry my bad , syntax was wrong .
> >
> > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
> ['attrlist=cn:sn:uid:testUserAccountControl'])"))
> > 6
> >
> > Thanks .
> >
> >
> > On Mon, Apr 29, 2019 at 10:26 AM Anuj Borah  wrote:
> > @William Brown
> >
> > This is the filter :
> "testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl']
> >
> > len(topo.standalone.search_s(DEFAULT_SUFFIX,
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
> > > 6
> >
> > But the full filter does not fit with filter module .
> >
> > > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> > > *** TypeError: filter() takes 2 positional arguments but 3 were given
> > > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> ['attrlist=cn:sn:uid:testUserAccountControl']"))
> > > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2,
> 'info': 'No such file or directory'}
> >
> >
> > Regards
> > Anuj Borah
> >
>
> That filter string seems really … uhh, interesting. You are testing:
>
> (testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
> ['attrlist=cn:sn:uid:testUserAccountControl’])
>
> Is that really a valid filter?
>
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
>
>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[William Brown]

> On 29 Apr 2019, at 15:00, Anuj Borah  wrote:
> 
> @William Brown 
> 
> Sorry my bad , syntax was wrong .
> 
> (Pdb) len(Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
>  ['attrlist=cn:sn:uid:testUserAccountControl'])"))
> 6
> 
> Thanks .
> 
> 
> On Mon, Apr 29, 2019 at 10:26 AM Anuj Borah  wrote:
> @William Brown 
> 
> This is the filter :
> "testUserAccountControl:1.2.840.113556.1.4.803:=8388608", 
> ['attrlist=cn:sn:uid:testUserAccountControl']
> 
> len(topo.standalone.search_s(DEFAULT_SUFFIX, 
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608", 
> ['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
> > 6
> 
> But the full filter does not fit with filter module .
> 
> > (Pdb) len(Accounts(topo.standalone, 
> > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> >  ['attrlist=cn:sn:uid:testUserAccountControl']))
> > *** TypeError: filter() takes 2 positional arguments but 3 were given
> > (Pdb) len(Accounts(topo.standalone, 
> > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> >  ['attrlist=cn:sn:uid:testUserAccountControl']"))
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 
> > 'No such file or directory'}
> 
> 
> Regards
> Anuj Borah
> 

That filter string seems really … uhh, interesting. You are testing:

(testUserAccountControl:1.2.840.113556.1.4.803:=8388608, 
['attrlist=cn:sn:uid:testUserAccountControl’])

Is that really a valid filter? 


—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

@William Brown 

Sorry my bad , syntax was wrong .

(Pdb) len(Accounts(topo.standalone,
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
['attrlist=cn:sn:uid:testUserAccountControl'])"))
6

Thanks .


On Mon, Apr 29, 2019 at 10:26 AM Anuj Borah  wrote:

> @William Brown 
>
> This is the filter :
> "testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl']
>
> len(topo.standalone.search_s(DEFAULT_SUFFIX,
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
> > 6
>
> But the full filter does not fit with filter module .
>
> > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> > *** TypeError: filter() takes 2 positional arguments but 3 were given
> > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> ['attrlist=cn:sn:uid:testUserAccountControl']"))
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
> 'No such file or directory'}
>
>
> Regards
> Anuj Borah
>
>
>
>
>
>
> On Mon, Apr 29, 2019 at 10:17 AM William Brown  wrote:
>
>>
>>
>> > On 29 Apr 2019, at 12:33, Anuj Borah  wrote:
>> >
>> > @William Brown
>> >
>> > Thanks for the tip!
>> >
>> > (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX,
>> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
>> ['attrlist=cn:sn:uid:testUserAccountControl']))
>> > 6
>> > (Pdb) len(Accounts(topo.standalone,
>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
>> > 6
>> >
>> > We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with
>> filter , like we do with search_s .
>> >
>> > (Pdb) len(Accounts(topo.standalone,
>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
>> ['attrlist=cn:sn:uid:testUserAccountControl']))
>> > *** TypeError: filter() takes 2 positional arguments but 3 were given
>> > (Pdb) len(Accounts(topo.standalone,
>> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
>> ['attrlist=cn:sn:uid:testUserAccountControl']"))
>> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2,
>> 'info': 'No such file or directory'}
>> >
>> > Again i have to use "re" module for the same .
>> >
>> >
>>
>> What are you trying to achieve?
>>
>>
>> Sincerely,
>>
>> William Brown
>>
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs
>>
>>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

@William Brown 

This is the filter :
"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
['attrlist=cn:sn:uid:testUserAccountControl']

len(topo.standalone.search_s(DEFAULT_SUFFIX,
ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
> 6

But the full filter does not fit with filter module .

> (Pdb) len(Accounts(topo.standalone,
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
['attrlist=cn:sn:uid:testUserAccountControl']))
> *** TypeError: filter() takes 2 positional arguments but 3 were given
> (Pdb) len(Accounts(topo.standalone,
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
['attrlist=cn:sn:uid:testUserAccountControl']"))
> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
'No such file or directory'}


Regards
Anuj Borah






On Mon, Apr 29, 2019 at 10:17 AM William Brown  wrote:

>
>
> > On 29 Apr 2019, at 12:33, Anuj Borah  wrote:
> >
> > @William Brown
> >
> > Thanks for the tip!
> >
> > (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX,
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> > 6
> > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
> > 6
> >
> > We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with
> filter , like we do with search_s .
> >
> > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> > *** TypeError: filter() takes 2 positional arguments but 3 were given
> > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> ['attrlist=cn:sn:uid:testUserAccountControl']"))
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
> 'No such file or directory'}
> >
> > Again i have to use "re" module for the same .
> >
> >
>
> What are you trying to achieve?
>
>
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
>
>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[William Brown]

> On 29 Apr 2019, at 12:33, Anuj Borah  wrote:
> 
> @William Brown 
> 
> Thanks for the tip! 
> 
> (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX, 
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608", 
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> 6
> (Pdb) len(Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
> 6
> 
> We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with filter 
> , like we do with search_s .
> 
> (Pdb) len(Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
>  ['attrlist=cn:sn:uid:testUserAccountControl']))
> *** TypeError: filter() takes 2 positional arguments but 3 were given
> (Pdb) len(Accounts(topo.standalone, 
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
>  ['attrlist=cn:sn:uid:testUserAccountControl']"))
> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 'No 
> such file or directory'}
> 
> Again i have to use "re" module for the same .
> 
> 

What are you trying to achieve?


Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[William Brown]

> On 29 Apr 2019, at 12:15, Anuj Borah  wrote:
> 
> @William Brown 
> 
> Thank you for the clarification. Same thing was writing in the second mail of 
> this mail chain . I was missing the use case UniqueGroup(…).filter().
> 
> What about bellow filters . Can we use filter here also .
> 
> topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (| 
> (nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['cn', 'cn', 'cn'])
> topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (| 
> (nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['*', 'cn’]

If you are filtering again accounts that are in a roll, then you would do:

Accounts().filter(conditions) ...



> )
> 

> And This one .
> 
> topo.standalone.search_s(DEFAULT_SUFFIX, 
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.804:=16777216",['attrlist=cn:sn:uid:testUserAccountControl’]
> )
> 

I think you need to think about this problem as “I want to run this filter and 
I expect to get these specific types back”. You aren’t simply doing a search, 
you are telling lib389 “find all accounts that match these conditions”.

So if you do the nsRoleDN search against accounts, you’ll get all accounts in 
that nsroledn. If you do the nsroledn search agains groups, you’ll get all 
groups that are in that nsroledn. 

Perhaps you need to think of it that way, that you are expressing not just the 
conditions you want to find, but what types of things you expect them to be. If 
you can answer that question, youll have the answer to “how” to use filter for 
those searches. 

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

@William Brown 

Thank you for the clarification. Same thing was writing in the second mail
of this mail chain . I was missing the use case UniqueGroup(…).filter().

What about bellow filters . Can we use filter here also .

topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (|
(nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['cn', 'cn',
'cn'])
topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (|
(nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['*', 'cn'])

And This one .

topo.standalone.search_s(DEFAULT_SUFFIX,
ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.804:=16777216",['attrlist=cn:sn:uid:testUserAccountControl'])

Regards
Anuj Borah




On Mon, Apr 29, 2019 at 7:38 AM William Brown  wrote:

>
>
> > On 29 Apr 2019, at 11:53, Anuj Borah  wrote:
> >
> > @William Brown
> >
> > The space did not make any difference . Look at bellow result .
> >
> > (Pdb) i
> > '(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)'
> > (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(i)
>
> ^ Because you are using the wrong class.
>
> Filter will wrap your call because you are filtering over the set of
> Accounts, not “generic searching”. If you want to search a group
> OfUniqueNames, you need:
>
> UniqueGroup(…).filter().
>
> Have a look at _mapped_object.py in def filter and youll see it does:
>
> def filter(self, search):
> # This will yield and & filter for objectClass with as many terms
> as needed.
> search_filter = _gen_and([self._get_objectclass_filter(),search])
>
> IE, your search of “uniqueMember=…” is then inserted such that:
>
> (&(objectClass=groupOfUniqueNames)(uniqueMember=…))
>
> Because you are using Accounts, this is doing:
>
> (&(|(objectClass=nsAccount)(objectClass=person)…) (uniqueMember=…))
>
> Which of course won’t find anything in a group, because Accounts are not
> Groups.
>
>
> So in fact, lib389 is doing exactly the right thing here, by saying “no,
> your search is not safe or sane, so you don’t get any results”. Lib389 is
> designed to prevent you making mistakes, and so will error or do nothing in
> the cases where something is wrong, rather than allow a corruption or odd
> behaviour to occur.
>
>
>
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
>
>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[William Brown]

> On 29 Apr 2019, at 11:53, Anuj Borah  wrote:
> 
> @William Brown
>  
> The space did not make any difference . Look at bellow result .
> 
> (Pdb) i
> '(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)'
> (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(i)

^ Because you are using the wrong class. 

Filter will wrap your call because you are filtering over the set of Accounts, 
not “generic searching”. If you want to search a group OfUniqueNames, you need:

UniqueGroup(…).filter().

Have a look at _mapped_object.py in def filter and youll see it does:

def filter(self, search):
# This will yield and & filter for objectClass with as many terms as 
needed.
search_filter = _gen_and([self._get_objectclass_filter(),search])

IE, your search of “uniqueMember=…” is then inserted such that:

(&(objectClass=groupOfUniqueNames)(uniqueMember=…))

Because you are using Accounts, this is doing:

(&(|(objectClass=nsAccount)(objectClass=person)…) (uniqueMember=…))

Which of course won’t find anything in a group, because Accounts are not Groups.


So in fact, lib389 is doing exactly the right thing here, by saying “no, your 
search is not safe or sane, so you don’t get any results”. Lib389 is designed 
to prevent you making mistakes, and so will error or do nothing in the cases 
where something is wrong, rather than allow a corruption or odd behaviour to 
occur. 




—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

@William Brown 

The space did not make any difference . Look at bellow result .

(Pdb) i
'(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)'
(Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(i)
[]
(Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, i)
[dn: cn=Accounting Managers,ou=Groups,dc=example,dc=com
cn: Accounting Managers
description: People who can manage accounting entries
objectClass: top
objectClass: groupOfUniqueNames
ou: groups
uniqueMember: cn=Directory Manager
uniqueMember: uid=scarter,ou=People,dc=example,dc=com
uniqueMember: uid=tmorris,ou=People,dc=example,dc=com
uniqueMember: uid=kvaughan,ou=People,dc=example,dc=com
uniqueMember: uid=rdaugherty,ou=People,dc=example,dc=com
uniqueMember: uid=hmiller,ou=People,dc=example,dc=com

, dn: cn=HR Managers,ou=Groups,dc=example,dc=com
cn: HR Managers
description: People who can manage HR entries
objectClass: top
objectClass: groupOfUniqueNames
ou: groups
uniqueMember: cn=Directory Manager
uniqueMember: uid=kvaughan,ou=People,dc=example,dc=com
uniqueMember: uid=cschmith,ou=People,dc=example,dc=com

]


My point of this mail is that we need to make some modification  to the
filter module so that it can completely replace search_s , till now we cant
use filter as replacement of search_s. Check out bellow condition also .

topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (|
(nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['cn', 'cn',
'cn'])
topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, '(& (|
(nsRoleDN=cn=new managed role) (sn=Hall)) (l=sunnyvale))', ['*', 'cn'])

And This one .

topo.standalone.search_s(DEFAULT_SUFFIX,
ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.804:=16777216",['attrlist=cn:sn:uid:testUserAccountControl'])


There is no way we can use filter for the above cases .


Regards
Anuj Borah



On Mon, Apr 29, 2019 at 4:41 AM William Brown  wrote:

>
>
> > On 26 Apr 2019, at 01:56, Anuj Borah  wrote:
> >
> > @Ludwig
> >
> > Under the same condition .
> >
> > Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter('(uniquemember=uid=kvaughan, ou=People,
> dc=example,dc=com)')   >>>   gives 0 result . (From filter script)
> >
> >
> > (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
> '(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)')  >>>   gives
> 2 result  (From search_s script)
>
>
>
> These filters are not the same. There is a “ “ between , and ou=People.
>
>
> >
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[William Brown]

> On 26 Apr 2019, at 01:56, Anuj Borah  wrote:
> 
> @Ludwig
> 
> Under the same condition .
> 
> Accounts(topo.standalone, DEFAULT_SUFFIX).filter('(uniquemember=uid=kvaughan, 
> ou=People, dc=example,dc=com)')   >>>   gives 0 result . (From filter 
> script)
> 
> 
> (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, 
> '(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)')  >>>   gives 2 
> result  (From search_s script)



These filters are not the same. There is a “ “ between , and ou=People. 


> 

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

@Ludwig 

Under the same condition .

Accounts(topo.standalone,
DEFAULT_SUFFIX).filter('(uniquemember=uid=kvaughan, ou=People,
dc=example,dc=com)')   >>>   gives 0 result . (From filter script)


(Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
'(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)')  >>>   gives
2 result  (From search_s script)
[dn: cn=Accounting Managers,ou=Groups,dc=example,dc=com
cn: Accounting Managers
description: People who can manage accounting entries
objectClass: top
objectClass: groupOfUniqueNames
ou: groups
uniqueMember: cn=Directory Manager
uniqueMember: uid=scarter,ou=People,dc=example,dc=com
uniqueMember: uid=tmorris,ou=People,dc=example,dc=com
uniqueMember: uid=kvaughan,ou=People,dc=example,dc=com
uniqueMember: uid=rdaugherty,ou=People,dc=example,dc=com
uniqueMember: uid=hmiller,ou=People,dc=example,dc=com

, dn: cn=HR Managers,ou=Groups,dc=example,dc=com
cn: HR Managers
description: People who can manage HR entries
objectClass: top
objectClass: groupOfUniqueNames
ou: groups
uniqueMember: cn=Directory Manager
uniqueMember: uid=kvaughan,ou=People,dc=example,dc=com
uniqueMember: uid=cschmith,ou=People,dc=example,dc=com


This is the problem .

Regards


On Thu, Apr 25, 2019 at 9:14 PM Ludwig  wrote:

>
>
> On 04/25/2019 05:38 PM, Anuj Borah wrote:
>
> @Ludwig 
>
> Try running these Two scrips one is with filter and other is with
> search_s.
>
> I will then also get different results, but you need to clarify what is
> "correct" and what not, if it is in what is sent to the server or what is
> done with handling the results
>
>
> Problem is with search_s i am getting correct result , where with filter
> wrong result.
>
> Regards
> Anuj Borah
>
>
>
>
> On Thu, Apr 25, 2019 at 8:30 PM Ludwig  wrote:
>
>> what is your problem ? the searches in both access logs produce the same
>> results:
>>
>>
>> grep nentries /tmp/access_with* | grep tag=101
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.560467098 +] conn=1
>> op=148 RESULT err=0 tag=101 nentries=3 etime=0.399837
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.562926674 +] conn=1
>> op=149 RESULT err=0 tag=101 nentries=9 etime=0.452772
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.565416724 +] conn=1
>> op=150 RESULT err=0 tag=101 nentries=8 etime=0.416033
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.567629593 +] conn=1
>> op=151 RESULT err=0 tag=101 nentries=2 etime=0.350486
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.569782885 +] conn=1
>> op=152 RESULT err=0 tag=101 nentries=4 etime=0.350236
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.571945045 +] conn=1
>> op=153 RESULT err=0 tag=101 nentries=7 etime=0.367961
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.53550 +] conn=1
>> op=154 RESULT err=0 tag=101 nentries=7 etime=0.0004031631
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.579866766 +] conn=1
>> op=155 RESULT err=0 tag=101 nentries=3 etime=0.274951
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.581771337 +] conn=1
>> op=156 RESULT err=0 tag=101 nentries=3 etime=0.312338
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.583848484 +] conn=1
>> op=157 RESULT err=0 tag=101 nentries=3 etime=0.1999656509
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.587570224 +] conn=1
>> op=158 RESULT err=0 tag=101 nentries=121 etime=0.0001897405
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.591514384 +] conn=1
>> op=159 RESULT err=0 tag=101 nentries=2 etime=0.319819
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.593657986 +] conn=1
>> op=160 RESULT err=0 tag=101 nentries=3 etime=0.285626
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.595880861 +] conn=1
>> op=161 RESULT err=0 tag=101 nentries=4 etime=0.356436
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.602518935 +] conn=1
>> op=162 RESULT err=0 tag=101 nentries=120 etime=0.0004828401
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.611163994 +] conn=1
>> op=163 RESULT err=0 tag=101 nentries=120 etime=0.0004651831
>> /tmp/access_with_filter:[25/Apr/2019:08:36:36.640014117 +] conn=1
>> op=166 RESULT err=0 tag=101 nentries=2 etime=0.711662
>> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.910324404 +] conn=1
>> op=148 RESULT err=0 tag=101 nentries=3 etime=0.351385
>> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.912317892 +] conn=1
>> op=149 RESULT err=0 tag=101 nentries=9 etime=0.358365
>> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.914679657 +] conn=1
>> op=150 RESULT err=0 tag=101 nentries=8 etime=0.430844
>> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.916847641 +] conn=1
>> op=151 RESULT err=0 tag=101 nentries=2 etime=0.332474
>> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.918878872 +] conn=1
>> op=152 RESULT err=0 tag=101 nentries=4 etime=0.341456
>> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.920965290 +] conn=1
>> op=153 RESULT err=0 

[389-devel] Re: Groups are not accessible by filter

[Ludwig]

On 04/25/2019 05:38 PM, Anuj Borah wrote:

@Ludwig 
Try running these Two scrips one is with filter and other is with 
search_s.
I will then also get different results, but you need to clarify what is 
"correct" and what not, if it is in what is sent to the server or what 
is done with handling the results


Problem is with search_s i am getting correct result , where with 
filter wrong result.


Regards
Anuj Borah




On Thu, Apr 25, 2019 at 8:30 PM Ludwig > wrote:


what is your problem ? the searches in both access logs produce
the same results:


grep nentries /tmp/access_with* | grep tag=101
/tmp/access_with_filter:[25/Apr/2019:08:36:36.560467098 +]
conn=1 op=148 RESULT err=0 tag=101 nentries=3 etime=0.399837
/tmp/access_with_filter:[25/Apr/2019:08:36:36.562926674 +]
conn=1 op=149 RESULT err=0 tag=101 nentries=9 etime=0.452772
/tmp/access_with_filter:[25/Apr/2019:08:36:36.565416724 +]
conn=1 op=150 RESULT err=0 tag=101 nentries=8 etime=0.416033
/tmp/access_with_filter:[25/Apr/2019:08:36:36.567629593 +]
conn=1 op=151 RESULT err=0 tag=101 nentries=2 etime=0.350486
/tmp/access_with_filter:[25/Apr/2019:08:36:36.569782885 +]
conn=1 op=152 RESULT err=0 tag=101 nentries=4 etime=0.350236
/tmp/access_with_filter:[25/Apr/2019:08:36:36.571945045 +]
conn=1 op=153 RESULT err=0 tag=101 nentries=7 etime=0.367961
/tmp/access_with_filter:[25/Apr/2019:08:36:36.53550 +]
conn=1 op=154 RESULT err=0 tag=101 nentries=7 etime=0.0004031631
/tmp/access_with_filter:[25/Apr/2019:08:36:36.579866766 +]
conn=1 op=155 RESULT err=0 tag=101 nentries=3 etime=0.274951
/tmp/access_with_filter:[25/Apr/2019:08:36:36.581771337 +]
conn=1 op=156 RESULT err=0 tag=101 nentries=3 etime=0.312338
/tmp/access_with_filter:[25/Apr/2019:08:36:36.583848484 +]
conn=1 op=157 RESULT err=0 tag=101 nentries=3 etime=0.1999656509
/tmp/access_with_filter:[25/Apr/2019:08:36:36.587570224 +]
conn=1 op=158 RESULT err=0 tag=101 nentries=121 etime=0.0001897405
/tmp/access_with_filter:[25/Apr/2019:08:36:36.591514384 +]
conn=1 op=159 RESULT err=0 tag=101 nentries=2 etime=0.319819
/tmp/access_with_filter:[25/Apr/2019:08:36:36.593657986 +]
conn=1 op=160 RESULT err=0 tag=101 nentries=3 etime=0.285626
/tmp/access_with_filter:[25/Apr/2019:08:36:36.595880861 +]
conn=1 op=161 RESULT err=0 tag=101 nentries=4 etime=0.356436
/tmp/access_with_filter:[25/Apr/2019:08:36:36.602518935 +]
conn=1 op=162 RESULT err=0 tag=101 nentries=120 etime=0.0004828401
/tmp/access_with_filter:[25/Apr/2019:08:36:36.611163994 +]
conn=1 op=163 RESULT err=0 tag=101 nentries=120 etime=0.0004651831
/tmp/access_with_filter:[25/Apr/2019:08:36:36.640014117 +]
conn=1 op=166 RESULT err=0 tag=101 nentries=2 etime=0.711662
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.910324404 +]
conn=1 op=148 RESULT err=0 tag=101 nentries=3 etime=0.351385
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.912317892 +]
conn=1 op=149 RESULT err=0 tag=101 nentries=9 etime=0.358365
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.914679657 +]
conn=1 op=150 RESULT err=0 tag=101 nentries=8 etime=0.430844
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.916847641 +]
conn=1 op=151 RESULT err=0 tag=101 nentries=2 etime=0.332474
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.918878872 +]
conn=1 op=152 RESULT err=0 tag=101 nentries=4 etime=0.341456
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.920965290 +]
conn=1 op=153 RESULT err=0 tag=101 nentries=7 etime=0.374608
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.926723170 +]
conn=1 op=154 RESULT err=0 tag=101 nentries=7 etime=0.0004056591
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.928637310 +]
conn=1 op=155 RESULT err=0 tag=101 nentries=3 etime=0.299780
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.930719687 +]
conn=1 op=156 RESULT err=0 tag=101 nentries=3 etime=0.296688
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.932751416 +]
conn=1 op=157 RESULT err=0 tag=101 nentries=3 etime=0.318958
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.936312042 +]
conn=1 op=158 RESULT err=0 tag=101 nentries=121 etime=0.0001861409
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.939996595 +]
conn=1 op=159 RESULT err=0 tag=101 nentries=2 etime=0.340760
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.942122456 +]
conn=1 op=160 RESULT err=0 tag=101 nentries=3 etime=0.309626
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.944215749 +]
conn=1 op=161 RESULT err=0 tag=101 nentries=4 etime=0.340311
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.950446188 +]
   

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

@Ludwig 

Try running these Two scrips one is with filter and other is with search_s.

Problem is with search_s i am getting correct result , where with filter
wrong result.

Regards
Anuj Borah




On Thu, Apr 25, 2019 at 8:30 PM Ludwig  wrote:

> what is your problem ? the searches in both access logs produce the same
> results:
>
>
> grep nentries /tmp/access_with* | grep tag=101
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.560467098 +] conn=1
> op=148 RESULT err=0 tag=101 nentries=3 etime=0.399837
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.562926674 +] conn=1
> op=149 RESULT err=0 tag=101 nentries=9 etime=0.452772
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.565416724 +] conn=1
> op=150 RESULT err=0 tag=101 nentries=8 etime=0.416033
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.567629593 +] conn=1
> op=151 RESULT err=0 tag=101 nentries=2 etime=0.350486
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.569782885 +] conn=1
> op=152 RESULT err=0 tag=101 nentries=4 etime=0.350236
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.571945045 +] conn=1
> op=153 RESULT err=0 tag=101 nentries=7 etime=0.367961
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.53550 +] conn=1
> op=154 RESULT err=0 tag=101 nentries=7 etime=0.0004031631
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.579866766 +] conn=1
> op=155 RESULT err=0 tag=101 nentries=3 etime=0.274951
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.581771337 +] conn=1
> op=156 RESULT err=0 tag=101 nentries=3 etime=0.312338
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.583848484 +] conn=1
> op=157 RESULT err=0 tag=101 nentries=3 etime=0.1999656509
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.587570224 +] conn=1
> op=158 RESULT err=0 tag=101 nentries=121 etime=0.0001897405
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.591514384 +] conn=1
> op=159 RESULT err=0 tag=101 nentries=2 etime=0.319819
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.593657986 +] conn=1
> op=160 RESULT err=0 tag=101 nentries=3 etime=0.285626
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.595880861 +] conn=1
> op=161 RESULT err=0 tag=101 nentries=4 etime=0.356436
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.602518935 +] conn=1
> op=162 RESULT err=0 tag=101 nentries=120 etime=0.0004828401
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.611163994 +] conn=1
> op=163 RESULT err=0 tag=101 nentries=120 etime=0.0004651831
> /tmp/access_with_filter:[25/Apr/2019:08:36:36.640014117 +] conn=1
> op=166 RESULT err=0 tag=101 nentries=2 etime=0.711662
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.910324404 +] conn=1
> op=148 RESULT err=0 tag=101 nentries=3 etime=0.351385
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.912317892 +] conn=1
> op=149 RESULT err=0 tag=101 nentries=9 etime=0.358365
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.914679657 +] conn=1
> op=150 RESULT err=0 tag=101 nentries=8 etime=0.430844
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.916847641 +] conn=1
> op=151 RESULT err=0 tag=101 nentries=2 etime=0.332474
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.918878872 +] conn=1
> op=152 RESULT err=0 tag=101 nentries=4 etime=0.341456
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.920965290 +] conn=1
> op=153 RESULT err=0 tag=101 nentries=7 etime=0.374608
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.926723170 +] conn=1
> op=154 RESULT err=0 tag=101 nentries=7 etime=0.0004056591
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.928637310 +] conn=1
> op=155 RESULT err=0 tag=101 nentries=3 etime=0.299780
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.930719687 +] conn=1
> op=156 RESULT err=0 tag=101 nentries=3 etime=0.296688
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.932751416 +] conn=1
> op=157 RESULT err=0 tag=101 nentries=3 etime=0.318958
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.936312042 +] conn=1
> op=158 RESULT err=0 tag=101 nentries=121 etime=0.0001861409
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.939996595 +] conn=1
> op=159 RESULT err=0 tag=101 nentries=2 etime=0.340760
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.942122456 +] conn=1
> op=160 RESULT err=0 tag=101 nentries=3 etime=0.309626
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.944215749 +] conn=1
> op=161 RESULT err=0 tag=101 nentries=4 etime=0.340311
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.950446188 +] conn=1
> op=162 RESULT err=0 tag=101 nentries=120 etime=0.0004499138
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.957921166 +] conn=1
> op=163 RESULT err=0 tag=101 nentries=120 etime=0.0004453710
> /tmp/access_with_search_s:[25/Apr/2019:08:56:30.968401791 +] conn=1
> op=166 RESULT err=0 tag=101 nentries=2 etime=0.215050
>
>
>
> On 04/25/2019 10:59 AM, Anuj Borah wrote:
>
> @Ludwig 
>
> Attached the 

[389-devel] Re: Groups are not accessible by filter

[Ludwig]

what is your problem ? the searches in both access logs produce the same 
results:



grep nentries /tmp/access_with* | grep tag=101
/tmp/access_with_filter:[25/Apr/2019:08:36:36.560467098 +] conn=1 
op=148 RESULT err=0 tag=101 nentries=3 etime=0.399837
/tmp/access_with_filter:[25/Apr/2019:08:36:36.562926674 +] conn=1 
op=149 RESULT err=0 tag=101 nentries=9 etime=0.452772
/tmp/access_with_filter:[25/Apr/2019:08:36:36.565416724 +] conn=1 
op=150 RESULT err=0 tag=101 nentries=8 etime=0.416033
/tmp/access_with_filter:[25/Apr/2019:08:36:36.567629593 +] conn=1 
op=151 RESULT err=0 tag=101 nentries=2 etime=0.350486
/tmp/access_with_filter:[25/Apr/2019:08:36:36.569782885 +] conn=1 
op=152 RESULT err=0 tag=101 nentries=4 etime=0.350236
/tmp/access_with_filter:[25/Apr/2019:08:36:36.571945045 +] conn=1 
op=153 RESULT err=0 tag=101 nentries=7 etime=0.367961
/tmp/access_with_filter:[25/Apr/2019:08:36:36.53550 +] conn=1 
op=154 RESULT err=0 tag=101 nentries=7 etime=0.0004031631
/tmp/access_with_filter:[25/Apr/2019:08:36:36.579866766 +] conn=1 
op=155 RESULT err=0 tag=101 nentries=3 etime=0.274951
/tmp/access_with_filter:[25/Apr/2019:08:36:36.581771337 +] conn=1 
op=156 RESULT err=0 tag=101 nentries=3 etime=0.312338
/tmp/access_with_filter:[25/Apr/2019:08:36:36.583848484 +] conn=1 
op=157 RESULT err=0 tag=101 nentries=3 etime=0.1999656509
/tmp/access_with_filter:[25/Apr/2019:08:36:36.587570224 +] conn=1 
op=158 RESULT err=0 tag=101 nentries=121 etime=0.0001897405
/tmp/access_with_filter:[25/Apr/2019:08:36:36.591514384 +] conn=1 
op=159 RESULT err=0 tag=101 nentries=2 etime=0.319819
/tmp/access_with_filter:[25/Apr/2019:08:36:36.593657986 +] conn=1 
op=160 RESULT err=0 tag=101 nentries=3 etime=0.285626
/tmp/access_with_filter:[25/Apr/2019:08:36:36.595880861 +] conn=1 
op=161 RESULT err=0 tag=101 nentries=4 etime=0.356436
/tmp/access_with_filter:[25/Apr/2019:08:36:36.602518935 +] conn=1 
op=162 RESULT err=0 tag=101 nentries=120 etime=0.0004828401
/tmp/access_with_filter:[25/Apr/2019:08:36:36.611163994 +] conn=1 
op=163 RESULT err=0 tag=101 nentries=120 etime=0.0004651831
/tmp/access_with_filter:[25/Apr/2019:08:36:36.640014117 +] conn=1 
op=166 RESULT err=0 tag=101 nentries=2 etime=0.711662
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.910324404 +] conn=1 
op=148 RESULT err=0 tag=101 nentries=3 etime=0.351385
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.912317892 +] conn=1 
op=149 RESULT err=0 tag=101 nentries=9 etime=0.358365
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.914679657 +] conn=1 
op=150 RESULT err=0 tag=101 nentries=8 etime=0.430844
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.916847641 +] conn=1 
op=151 RESULT err=0 tag=101 nentries=2 etime=0.332474
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.918878872 +] conn=1 
op=152 RESULT err=0 tag=101 nentries=4 etime=0.341456
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.920965290 +] conn=1 
op=153 RESULT err=0 tag=101 nentries=7 etime=0.374608
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.926723170 +] conn=1 
op=154 RESULT err=0 tag=101 nentries=7 etime=0.0004056591
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.928637310 +] conn=1 
op=155 RESULT err=0 tag=101 nentries=3 etime=0.299780
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.930719687 +] conn=1 
op=156 RESULT err=0 tag=101 nentries=3 etime=0.296688
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.932751416 +] conn=1 
op=157 RESULT err=0 tag=101 nentries=3 etime=0.318958
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.936312042 +] conn=1 
op=158 RESULT err=0 tag=101 nentries=121 etime=0.0001861409
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.939996595 +] conn=1 
op=159 RESULT err=0 tag=101 nentries=2 etime=0.340760
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.942122456 +] conn=1 
op=160 RESULT err=0 tag=101 nentries=3 etime=0.309626
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.944215749 +] conn=1 
op=161 RESULT err=0 tag=101 nentries=4 etime=0.340311
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.950446188 +] conn=1 
op=162 RESULT err=0 tag=101 nentries=120 etime=0.0004499138
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.957921166 +] conn=1 
op=163 RESULT err=0 tag=101 nentries=120 etime=0.0004453710
/tmp/access_with_search_s:[25/Apr/2019:08:56:30.968401791 +] conn=1 
op=166 RESULT err=0 tag=101 nentries=2 etime=0.215050




On 04/25/2019 10:59 AM, Anuj Borah wrote:

@Ludwig 
Attached the logs .

I have noticed , it happening due to _get_objectclass_filter() method 
in filter of DSLdapObjects .


Accounts(topo.standalone, DEFAULT_SUFFIX)._objectclasses
['nsAccount', 'nsPerson', 'simpleSecurityObject', 'organization', 
'person', 'account', 'organizationalUnit', 'netscapeServer', 'domain', 
'posixAccount', 

[389-devel] Re: Groups are not accessible by filter

[Anuj Borah]

@Ludwig 

Attached the logs .

I have noticed , it happening due to _get_objectclass_filter() method in
filter of DSLdapObjects .

Accounts(topo.standalone, DEFAULT_SUFFIX)._objectclasses
['nsAccount', 'nsPerson', 'simpleSecurityObject', 'organization', 'person',
'account', 'organizationalUnit', 'netscapeServer', 'domain',
'posixAccount', 'shadowAccount', 'posixGroup', 'mailRecipient']


but the cn=Accounting Managers,ou=Groups,dc=example,dc=com has objectClass:
groupOfUniqueNames .

This may be the problem . You can  not find any error in access logs as
naturally it does not have any error , its just empty results .

Regards
Anuj Borah


On Thu, Apr 25, 2019 at 12:39 PM Ludwig  wrote:

> can you provide the access logs to show what searches were really done
>
> On 04/24/2019 12:23 PM, Anuj Borah wrote:
>
> Hi all,
>
> Please consider bellow condition .
>
> UserAccount(topo.standalone, 'cn=Accounting 
> Managers,ou=groups,dc=example,dc=com').add('uniquemember', [
> 'uid=scarter, ou=People, dc=example,dc=com', 'uid=tmorris, ou=People, 
> dc=example,dc=com', 'uid=kvaughan, ou=People, dc=example,dc=com',
> 'uid=rdaugherty, ou=People, dc=example,dc=com', 'uid=hmiller, ou=People, 
> dc=example,dc=com'])
>
> UserAccount(topo.standalone, 'cn=HR 
> Managers,ou=groups,dc=example,dc=com').add('uniquemember', [
> 'uid=kvaughan, ou=People, dc=example,dc=com', 'uid=cschmith, ou=People, 
> dc=example,dc=com'])
>
>
> And try to add filter:
>
> With Filter: It fails gives 0 result for those involves Group
> 'cn=Accounting Managers,ou=groups,dc=example,dc=com' .
>
> for i in ['(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)',  
>  '(uniquemember=uid=rdaugherty, ou=People, dc=example,dc=com)',  
> '(uniquemember=uid=hmiller, ou=People, dc=example,dc=com)',   
> '(&(objectclass=inetorgperson)(uid=scarter))',  
> '(&(objectclass=organizationalperson)(uid=scarter))',   
> '(objectclass=inetorgperson)',   
> '(&(objectclass=organizationalPerson)(sn=Jensen))',  
> '(&(mail=*)(objectclass=organizationalPerson))',   '(mail=*)',
>'(&(sn=Rentz)(objectclass=organizationalPerson))',  
> '(&(sn=Ward)(sn=Ward))',   '(sn=Jensen)',   '(sn=*)', 
>   '(sn=*utz)']:
> assert Accounts(topo.standalone, DEFAULT_SUFFIX).filter(i)
>
>
> with search_s(Old Way): I gives correct results .
>
> for i in ['(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)',  
> '(uniquemember=uid=rdaugherty, ou=People, dc=example,dc=com)',  
> '(uniquemember=uid=hmiller, ou=People, dc=example,dc=com)',  
> '(&(objectclass=inetorgperson)(uid=scarter))',  
> '(&(objectclass=organizationalperson)(uid=scarter))',  
> '(objectclass=inetorgperson)',  
> '(&(objectclass=organizationalPerson)(sn=Jensen))',  
> '(&(mail=*)(objectclass=organizationalPerson))',  '(mail=*)', 
>  '(&(sn=Rentz)(objectclass=organizationalPerson))',  
> '(&(sn=Ward)(sn=Ward))',  '(sn=Jensen)',  '(sn=*)',  
> '(sn=*utz)']:
> assert topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, i)
>
>
>
> I have attached the test script too . Test
> test_various_combinations_of_filters_and_idlistscanlimit
>
> Regards
> Anuj Borah
>
>
>
>
>
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>
>
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>


access_with_filter
Description: Binary data


access_with_search_s
Description: Binary data
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Re: Groups are not accessible by filter

[Ludwig]

can you provide the access logs to show what searches were really done


On 04/24/2019 12:23 PM, Anuj Borah wrote:

Hi all,

Please consider bellow condition .

UserAccount(topo.standalone, 'cn=Accounting 
Managers,ou=groups,dc=example,dc=com').add('uniquemember', [
 'uid=scarter, ou=People, dc=example,dc=com', 'uid=tmorris, ou=People, 
dc=example,dc=com', 'uid=kvaughan, ou=People, dc=example,dc=com', 
'uid=rdaugherty, ou=People, dc=example,dc=com', 'uid=hmiller, 
ou=People, dc=example,dc=com'])


UserAccount(topo.standalone, 'cn=HR 
Managers,ou=groups,dc=example,dc=com').add('uniquemember', [
 'uid=kvaughan, ou=People, dc=example,dc=com', 'uid=cschmith, 
ou=People, dc=example,dc=com'])


And try to add filter:

With Filter: It fails gives 0 result for those involves Group 
'cn=Accounting Managers,ou=groups,dc=example,dc=com' .


for iin ['(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)', 
'(uniquemember=uid=rdaugherty, ou=People, dc=example,dc=com)', 
'(uniquemember=uid=hmiller, ou=People, dc=example,dc=com)', 
'(&(objectclass=inetorgperson)(uid=scarter))', 
'(&(objectclass=organizationalperson)(uid=scarter))', 
'(objectclass=inetorgperson)', 
'(&(objectclass=organizationalPerson)(sn=Jensen))', 
'(&(mail=*)(objectclass=organizationalPerson))', '(mail=*)', 
'(&(sn=Rentz)(objectclass=organizationalPerson))', 
'(&(sn=Ward)(sn=Ward))', '(sn=Jensen)', '(sn=*)', '(sn=*utz)']:

 assert Accounts(topo.standalone, DEFAULT_SUFFIX).filter(i)

with search_s(Old Way): I gives correct results .

for iin ['(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)', 
'(uniquemember=uid=rdaugherty, ou=People, dc=example,dc=com)', 
'(uniquemember=uid=hmiller, ou=People, dc=example,dc=com)', 
'(&(objectclass=inetorgperson)(uid=scarter))', 
'(&(objectclass=organizationalperson)(uid=scarter))', 
'(objectclass=inetorgperson)', 
'(&(objectclass=organizationalPerson)(sn=Jensen))', 
'(&(mail=*)(objectclass=organizationalPerson))', '(mail=*)', 
'(&(sn=Rentz)(objectclass=organizationalPerson))', 
'(&(sn=Ward)(sn=Ward))', '(sn=Jensen)', '(sn=*)', '(sn=*utz)']:

 assert topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, i)


I have attached the test script too . Test 
test_various_combinations_of_filters_and_idlistscanlimit


Regards
Anuj Borah





___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org