@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: bhall@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: bhall@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 .


Regards
Anuj Borah



On Wed, May 8, 2019 at 6:08 AM William Brown <wbrown@suse.de> wrote:


> On 7 May 2019, at 23:56, Viktor Ashirov <vashirov@redhat.com> wrote:
>
> On Tue, May 7, 2019 at 2:09 PM William Brown <wbrown@suse.de> wrote:
>>
>>
>>
>>> On 7 May 2019, at 22:03, Viktor Ashirov <vashirov@redhat.com> wrote:
>>>
>>> On Mon, Apr 29, 2019 at 6:48 AM William Brown <wbrown@suse.de> wrote:
>>>>
>>>>
>>>>
>>>>> On 29 Apr 2019, at 12:33, Anuj Borah <aborah@redhat.com> 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-leave@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-leave@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-leave@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-leave@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