[389-devel] lib389 lack a type for nsAdminGroup

[Anuj Borah]

Hi all,

Please correct me if subject line a wrong , as i cat not find one .


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Please review

[Anuj Borah]

@Mark Reynolds 

Thanks and welcome .

Regards
Anuj Borah

On Wed, Jul 17, 2019 at 7:31 PM Mark Reynolds  wrote:

>
> On 7/16/19 8:12 PM, Anuj Borah wrote:
>
> @Mark Reynolds 
>
> @Mark Reynolds
>
> >>> The code itself looks fine to me, but I find it odd you are testing
> matching rules by creating COS entries in two of those PRs.
>
> Cos entries are used here as part of  (
>
> objectclass: extensibleObject
>
> )
>
> As cos template has (
>
> objectclass: ['top','cosTemplate' , 'extensibleObject']
>
> )
>
> Which is the nearest one of row  extensibleObject entry.
>
> Ah okay I see.  Please add a comment that you are really just trying to
> use an entry with extensibleObject, because it is currently confusing.
>
>
>
> >>> I don't think that is actually doing anything in regards to matching
> rules.  I was under the impression that matching rules are only
> applied/enforced during searches (not Adds or Modifies).  So you are
> checking for TYPE_OR_VALUE_EXISTS errors in some of the tests, and I don't
> see what that has to do with matching rules.  Or, maybe I am just missing
> what this test is trying to do as I am not that familiar with MRs.  So if
> you can clarify that for me I would appreciate it
>
>
> Please refer bellow ldif file and TET Filter suit which is part of Filter
> test suit .  To See whats going on Please see the original TET Filter suit
> . (  test  series  mr_*()   )
>
> Filter TET Script :
> http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/testcases/DS/6.0/filter/filter.sh
> LDIF FIle:
> http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/mrsearchtests.ldif
> LDIF FIle:
> http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/booleanMatch.add.ldif
>
>
> Thanks for providing more background on this.   The rest looks good to me.
>
> Thanks,
>
> Mark
>
>
> Regards
> Anuj Borah
>
> On Wed, Jul 17, 2019 at 5:38 AM Anuj Borah  wrote:
>
>> @Mark Reynolds 
>>
>> >>> The code itself looks fine to me, but I find it odd you are testing
>> matching rules by creating COS entries in two of those PRs.
>>
>> Cos entries are used here as part of  (
>>
>> objectclass: extensibleObject
>>
>> )
>>
>> As cos template has (
>>
>> objectclass: ['top','cosTemplate' , 'extensibleObject']
>>
>> )
>>
>> Which is the nearest one of row  extensibleObject entry.
>>
>>
>> >>> I don't think that is actually doing anything in regards to matching
>> rules.  I was under the impression that matching rules are only
>> applied/enforced during searches (not Adds or Modifies).  So you are
>> checking for TYPE_OR_VALUE_EXISTS errors in some of the tests, and I don't
>> see what that has to do with matching rules.  Or, maybe I am just missing
>> what this test is trying to do as I am not that familiar with MRs.  So if
>> you can clarify that for me I would appreciate it
>>
>>
>> Please refer bellow ldif file and TET Filter suit which is part of Filter
>> test suit .  To See whats going on Please see the original TET Filter
>> suit . (  test  series  mr_*()   )
>>
>> Filter TET Script :
>> http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/testcases/DS/6.0/filter
>> LDIF FIle:
>> http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/mrsearchtests.ldif
>> LDIF FIle:
>> http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/booleanMatch.add.ldif
>>
>>
>>
>> Regards
>> Anuj Borah
>>
>> On Wed, Jul 17, 2019 at 2:21 AM Mark Reynolds 
>> wrote:
>>
>>>
>>> On 7/15/19 8:00 AM, Anuj Borah wrote:
>>>
>>> @Simon Pichugin 
>>>
>>> Please review:
>>>
>>> https://pagure.io/389-ds-base/pull-request/50468
>>> https://pagure.io/389-ds-base/pull-request/50471
>>> https://pagure.io/389-ds-base/pull-request/50482
>>>
>>>
>>> The code itself looks fine to me, but I find it odd you are testing
>>> matching rules by creating COS entries in two of those PRs.  I don't think
>>> that is actually doing anything in regards to matching rules.  I was under
>>> the impression that matching rules are only applied/enforced during
>>> searches (not Adds or Modifies).  So you are checking for
>>> TYPE_OR_VALUE_EXISTS errors in some of the tests, and I don't see what that
>>> has to do with matching rules.  Or, maybe I am just missing what this test
>>> is t

[389-devel] Re: Please review

[Anuj Borah]

@Mark Reynolds 

@Mark Reynolds

>>> The code itself looks fine to me, but I find it odd you are testing
matching rules by creating COS entries in two of those PRs.

Cos entries are used here as part of  (

objectclass: extensibleObject

)

As cos template has (

objectclass: ['top','cosTemplate' , 'extensibleObject']

)

Which is the nearest one of row  extensibleObject entry.


>>> I don't think that is actually doing anything in regards to matching
rules.  I was under the impression that matching rules are only
applied/enforced during searches (not Adds or Modifies).  So you are
checking for TYPE_OR_VALUE_EXISTS errors in some of the tests, and I don't
see what that has to do with matching rules.  Or, maybe I am just missing
what this test is trying to do as I am not that familiar with MRs.  So if
you can clarify that for me I would appreciate it


Please refer bellow ldif file and TET Filter suit which is part of Filter
test suit .  To See whats going on Please see the original TET Filter suit
. (  test  series  mr_*()   )

Filter TET Script :
http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/testcases/DS/6.0/filter/filter.sh
LDIF FIle:
http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/mrsearchtests.ldif
LDIF FIle:
http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/booleanMatch.add.ldif



Regards
Anuj Borah

On Wed, Jul 17, 2019 at 5:38 AM Anuj Borah  wrote:

> @Mark Reynolds 
>
> >>> The code itself looks fine to me, but I find it odd you are testing
> matching rules by creating COS entries in two of those PRs.
>
> Cos entries are used here as part of  (
>
> objectclass: extensibleObject
>
> )
>
> As cos template has (
>
> objectclass: ['top','cosTemplate' , 'extensibleObject']
>
> )
>
> Which is the nearest one of row  extensibleObject entry.
>
>
> >>> I don't think that is actually doing anything in regards to matching
> rules.  I was under the impression that matching rules are only
> applied/enforced during searches (not Adds or Modifies).  So you are
> checking for TYPE_OR_VALUE_EXISTS errors in some of the tests, and I don't
> see what that has to do with matching rules.  Or, maybe I am just missing
> what this test is trying to do as I am not that familiar with MRs.  So if
> you can clarify that for me I would appreciate it
>
>
> Please refer bellow ldif file and TET Filter suit which is part of Filter
> test suit .  To See whats going on Please see the original TET Filter
> suit . (  test  series  mr_*()   )
>
> Filter TET Script :
> http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/testcases/DS/6.0/filter
> LDIF FIle:
> http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/mrsearchtests.ldif
> LDIF FIle:
> http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/booleanMatch.add.ldif
>
>
>
> Regards
> Anuj Borah
>
> On Wed, Jul 17, 2019 at 2:21 AM Mark Reynolds 
> wrote:
>
>>
>> On 7/15/19 8:00 AM, Anuj Borah wrote:
>>
>> @Simon Pichugin 
>>
>> Please review:
>>
>> https://pagure.io/389-ds-base/pull-request/50468
>> https://pagure.io/389-ds-base/pull-request/50471
>> https://pagure.io/389-ds-base/pull-request/50482
>>
>>
>> The code itself looks fine to me, but I find it odd you are testing
>> matching rules by creating COS entries in two of those PRs.  I don't think
>> that is actually doing anything in regards to matching rules.  I was under
>> the impression that matching rules are only applied/enforced during
>> searches (not Adds or Modifies).  So you are checking for
>> TYPE_OR_VALUE_EXISTS errors in some of the tests, and I don't see what that
>> has to do with matching rules.  Or, maybe I am just missing what this test
>> is trying to do as I am not that familiar with MRs.  So if you can clarify
>> that for me I would appreciate it
>>
>> Thanks,
>>
>> Mark
>>
>>
>> Regards
>> AB
>> A
>>
>>
>> On Tue, May 21, 2019 at 4:17 PM Anuj Borah  wrote:
>>
>>> @Simon Pichugin 
>>>
>>> Please review:
>>>
>>> https://pagure.io/389-ds-base/pull-request/50336
>>>
>>> Regards
>>> Anuj Borah
>>>
>>>
>>> On Wed, May 15, 2019 at 8:50 PM Anuj Borah  wrote:
>>>
>>>> @Simon Pichugin 
>>>>
>>>> Please review:
>>>>
>>>> https://pagure.io/389-ds-base/pull-request/50328
>>>>
>>>> Regards
>>>> Anuj Borah
>>>>
>>>>
>>>>
>>>> On Thu, May 9, 201

[389-devel] Re: Please review

[Anuj Borah]

@Mark Reynolds 

>>> The code itself looks fine to me, but I find it odd you are testing
matching rules by creating COS entries in two of those PRs.

Cos entries are used here as part of  (

objectclass: extensibleObject

)

As cos template has (

objectclass: ['top','cosTemplate' , 'extensibleObject']

)

Which is the nearest one of row  extensibleObject entry.


>>> I don't think that is actually doing anything in regards to matching
rules.  I was under the impression that matching rules are only
applied/enforced during searches (not Adds or Modifies).  So you are
checking for TYPE_OR_VALUE_EXISTS errors in some of the tests, and I don't
see what that has to do with matching rules.  Or, maybe I am just missing
what this test is trying to do as I am not that familiar with MRs.  So if
you can clarify that for me I would appreciate it


Please refer bellow ldif file and TET Filter suit which is part of Filter
test suit .  To See whats going on Please see the original TET Filter suit
. (  test  series  mr_*()   )

Filter TET Script :
http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/testcases/DS/6.0/filter
LDIF FIle:
http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/mrsearchtests.ldif
LDIF FIle:
http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/booleanMatch.add.ldif



Regards
Anuj Borah

On Wed, Jul 17, 2019 at 2:21 AM Mark Reynolds  wrote:

>
> On 7/15/19 8:00 AM, Anuj Borah wrote:
>
> @Simon Pichugin 
>
> Please review:
>
> https://pagure.io/389-ds-base/pull-request/50468
> https://pagure.io/389-ds-base/pull-request/50471
> https://pagure.io/389-ds-base/pull-request/50482
>
>
> The code itself looks fine to me, but I find it odd you are testing
> matching rules by creating COS entries in two of those PRs.  I don't think
> that is actually doing anything in regards to matching rules.  I was under
> the impression that matching rules are only applied/enforced during
> searches (not Adds or Modifies).  So you are checking for
> TYPE_OR_VALUE_EXISTS errors in some of the tests, and I don't see what that
> has to do with matching rules.  Or, maybe I am just missing what this test
> is trying to do as I am not that familiar with MRs.  So if you can clarify
> that for me I would appreciate it
>
> Thanks,
>
> Mark
>
>
> Regards
> AB
> A
>
>
> On Tue, May 21, 2019 at 4:17 PM Anuj Borah  wrote:
>
>> @Simon Pichugin 
>>
>> Please review:
>>
>> https://pagure.io/389-ds-base/pull-request/50336
>>
>> Regards
>> Anuj Borah
>>
>>
>> On Wed, May 15, 2019 at 8:50 PM Anuj Borah  wrote:
>>
>>> @Simon Pichugin 
>>>
>>> Please review:
>>>
>>> https://pagure.io/389-ds-base/pull-request/50328
>>>
>>> Regards
>>> Anuj Borah
>>>
>>>
>>>
>>> On Thu, May 9, 2019 at 5:27 PM Anuj Borah  wrote:
>>>
>>>> @Simon Pichugin 
>>>>
>>>> This one is still pending .
>>>>
>>>> https://pagure.io/389-ds-base/pull-request/50192
>>>>
>>>> Regards
>>>> Anuj Borah
>>>>
>>>>
>>>> On Tue, Apr 30, 2019 at 4:03 PM Anuj Borah  wrote:
>>>>
>>>>> Hi Simon ,
>>>>>
>>>>> Rebsed onto master .
>>>>>
>>>>> Regards
>>>>> Anuj Borah
>>>>>
>>>>> On Tue, Apr 30, 2019 at 3:54 PM Simon Pichugin 
>>>>> wrote:
>>>>>
>>>>>> On Tue, Apr 30, 2019 at 02:15:55PM +0530, Anuj Borah wrote:
>>>>>> >Hi all,
>>>>>> Hi Anuj,
>>>>>>
>>>>>> >Please review these PRs.
>>>>>> >Pending from Long Time.
>>>>>> >[1]https://pagure.io/389-ds-base/pull-request/50180
>>>>>> >[2]https://pagure.io/389-ds-base/pull-request/50192
>>>>>> Could you please rebase them onto master?
>>>>>>
>>>>>> Thanks,
>>>>>> Simon
>>>>>>
>>>>>> >Regards
>>>>>> >Anuj Borah
>>>>>> >
>>>>>> > References
>>>>>> >
>>>>>> >1. https://pagure.io/389-ds-base/pull-request/50180
>>>>>> >2. https://pagure.io/389-ds-base/pull-request/50192
>>>>>>
>>>>>> > ___
>>>>>> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>>>

[389-devel] Re: Please review

[Anuj Borah]

@Simon Pichugin 

Please review:

https://pagure.io/389-ds-base/pull-request/50468
https://pagure.io/389-ds-base/pull-request/50471
https://pagure.io/389-ds-base/pull-request/50482

Regards
AB
A


On Tue, May 21, 2019 at 4:17 PM Anuj Borah  wrote:

> @Simon Pichugin 
>
> Please review:
>
> https://pagure.io/389-ds-base/pull-request/50336
>
> Regards
> Anuj Borah
>
>
> On Wed, May 15, 2019 at 8:50 PM Anuj Borah  wrote:
>
>> @Simon Pichugin 
>>
>> Please review:
>>
>> https://pagure.io/389-ds-base/pull-request/50328
>>
>> Regards
>> Anuj Borah
>>
>>
>>
>> On Thu, May 9, 2019 at 5:27 PM Anuj Borah  wrote:
>>
>>> @Simon Pichugin 
>>>
>>> This one is still pending .
>>>
>>> https://pagure.io/389-ds-base/pull-request/50192
>>>
>>> Regards
>>> Anuj Borah
>>>
>>>
>>> On Tue, Apr 30, 2019 at 4:03 PM Anuj Borah  wrote:
>>>
>>>> Hi Simon ,
>>>>
>>>> Rebsed onto master .
>>>>
>>>> Regards
>>>> Anuj Borah
>>>>
>>>> On Tue, Apr 30, 2019 at 3:54 PM Simon Pichugin 
>>>> wrote:
>>>>
>>>>> On Tue, Apr 30, 2019 at 02:15:55PM +0530, Anuj Borah wrote:
>>>>> >Hi all,
>>>>> Hi Anuj,
>>>>>
>>>>> >Please review these PRs.
>>>>> >Pending from Long Time.
>>>>> >[1]https://pagure.io/389-ds-base/pull-request/50180
>>>>> >[2]https://pagure.io/389-ds-base/pull-request/50192
>>>>> Could you please rebase them onto master?
>>>>>
>>>>> Thanks,
>>>>> Simon
>>>>>
>>>>> >Regards
>>>>> >Anuj Borah
>>>>> >
>>>>> > References
>>>>> >
>>>>> >1. https://pagure.io/389-ds-base/pull-request/50180
>>>>> >2. https://pagure.io/389-ds-base/pull-request/50192
>>>>>
>>>>> > ___
>>>>> > 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 mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] *** NameError: name 'ds_is_older' is not defined

[Anuj Borah]

Hi all,

Issue: https://pagure.io/389-ds-base/issue/50446

from lib389.utils import (ds_is_older) is missing in

https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/idm/account.py

users = UserAccounts(standalone, DEFAULT_SUFFIX)
for i in users.list(): i.dn
'uid=testuser,ou=People,dc=example,dc=com'
'uid=test_user_1000,ou=People,dc=example,dc=com'
'uid=test_user1,ou=People,dc=example,dc=com'

UserAccount(standalone,'uid=test_user1,ou=People,dc=example,dc=com').enroll_certificate('/etc/dirsrv/slapd-standalone1/user-test_user1.der')
*** NameError: name 'ds_is_older' is not defined



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] Re: How to create a user with certificate with lib389

[Anuj Borah]

Main aim of the test case is filter user with binary search not the base64
.

(Pdb) six.ensure_str(crt)
*** UnicodeDecodeError: 'utf-8' codec can't decode byte 0x82 in position 1:
invalid start byte

On Thu, Jun 13, 2019 at 7:05 PM William Brown  wrote:

> I'm really suspicious here that your escape bytes is not needed for ldap
> as much as to prevent python state leaking into the string and the data.
> I'm wondering if there is a better approach 
>
> Can ldap filters take base64 instead? Perhaps the issue with your filter
> atm is that you are putting a byte string into an f string so that formats
> with escapes. Have you tried ensure_str() instead?
>
>
>
> > On 13 Jun 2019, at 15:29, Anuj Borah  wrote:
> >
> > Yes, it is. but with escape_bytes function only.
> >
> > (Pdb) Accounts(standalone,
> DEFAULT_SUFFIX).filter(f"(userCertificate={crt})")
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
> 'No such file or directory'}
> >
> > And finally .
> > Accounts(standalone,
> DEFAULT_SUFFIX).filter(f"(userCertificate={escape_bytes(crt)})")  >>>
> escape_bytes(this is function i want to put in utils.py)
> > []
> >
> >
> >
> > On Thu, Jun 13, 2019 at 6:56 PM William Brown  wrote:
> > Is the test case *just* testing if binary searching of attributes works?
> >
> > > On 13 Jun 2019, at 15:25, Anuj Borah  wrote:
> > >
> > > @William Brown
> > >
> > >
> > > This is my test case in bash form . Hope this helps.
> > >
> > > dn: uid=user4F, ou=People, dc=example, dc=com
> > > uid: user4F
> > > cn: User 4F
> > > sn: 
> > > givenName: 
> > > ou: People
> > > objectClass: top
> > > objectClass: person
> > > objectClass: organizationalPerson
> > > objectClass: inetOrgPerson
> > > description: This is user4F's description
> > > mail:
> > > use...@test.com
> > >
> > > userPassword: user4F
> > > userCertificate;binary::
> MIID5zCCA1CgAwIBAgIDAIF5MA0GCSqGSIb3DQEBBQUAMF4xCzAJ
> > >
> BgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UE
> > >
> CxMDUEtJMRkwFwYDVQQDExBET0QgQ0xBU1MgMyBDQS0zMB4XDTAxMTExNDAwMDAwMFoXDTA0MTEx
> > >
> MzAwMDAwMFowdTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE
> > >
> CxMDRG9EMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAsTA1VTTjEiMCAGA1UEAxMZU0xBQ0suU1RBQ0VZ
> > >
> LkouMTAzNTQ3MjE4MTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnma4IZobULRwrDto4O/U
> > >
> mXXVtW1MDuYhooo7/5H6O+9WVWIHMKNW+TvonliezYE/N3VwHG8IFJrnjzHjtrmD/iYi+kl3jz5U
> > >
> QmaS/F1fDiP2/G9hEhc5QP6ZCpjWUjf/0m0NjwFiAxLGWNQV9oBqhWU+fwBxD4gGMWRwzGrbVK8C
> > >
> AwEAAaOCAZowggGWMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBQH4UHGgQthSDSPSnwyinB7
> > >
> UgD4MzAdBgNVHQ4EFgQUa6cO9LyOgFuZhaw2S+CKYh8W6NIwFgYDVR0gBA8wDTALBglghkgBZQIB
> > >
> CwkwfgYDVR0SBHcwdYZzbGRhcDovL2RzLTMuYzNwa2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0Ql
> > >
> MjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292
> > >
> ZXJubWVudCUyY2MlM2RVUzCBqwYDVR0fBIGjMIGgMIGdoIGaoIGXhoGUbGRhcDovL2RzLTMuYzNw
> > >
> a2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0kl
> > >
> MmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJl
> > >
> dm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOBgQB5aLv3JjaAb+eIOrW3niXs96na
> > >
> mbjDq1IbWK55YVcpCBgD2fYasSlEmnt7ykQlYW8woRORaKv9ERpTcfcg4odi9VbtzIyzYHVyY5DU
> > >
> LuaEhqNiKCnjqWXPeMHmtD2H6nBiDAo6tfyitL5E+NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==
> > >
> > >
> > >
> > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com" "(usercertificate;binary=*)"
> > >
> > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com" "(usercertificate=*)"
> > >
> > > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com"
> "(usercertificate;binary=\4d\49\49\44\35\7a\43\43\41\31\43\67\41\77\49\42\41\67\49\44\41\49\46\35\4d\41\30\47\43\53\71\47\53\49\62\33\44\51\45\42\42\51\55\41\4d\46\34\78\43\7a\41\4a\42\67\4e\56\42\41\59\54\41\6c\56\54\4d\52\67\77\46\67\59\44\56\51\51\4b\45\77\39\56\4c\6c\4d\75\49\45\64\76\64\6d\56\79\62\6d\31\6c\62\6e\51\78\44\44\41\4b\42\67\4e\56\42\41\73\54\41\30\52\76\52\44\45\4d\4d\41\6f\47\41\31\55\45\43\78\4d\44\55\45\74\4a\4d\52\6b\77\46\77\59\44\56\51

[389-devel] Re: How to create a user with certificate with lib389

[Anuj Borah]

Yes, it is. but with escape_bytes function only.

(Pdb) Accounts(standalone,
DEFAULT_SUFFIX).filter(f"(userCertificate={crt})")
*** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
'No such file or directory'}

And finally .
Accounts(standalone,
DEFAULT_SUFFIX).filter(f"(userCertificate={escape_bytes(crt)})")  >>>
escape_bytes(this is function i want to put in utils.py)
[]



On Thu, Jun 13, 2019 at 6:56 PM William Brown  wrote:

> Is the test case *just* testing if binary searching of attributes works?
>
> > On 13 Jun 2019, at 15:25, Anuj Borah  wrote:
> >
> > @William Brown
> >
> >
> > This is my test case in bash form . Hope this helps.
> >
> > dn: uid=user4F, ou=People, dc=example, dc=com
> > uid: user4F
> > cn: User 4F
> > sn: 
> > givenName: 
> > ou: People
> > objectClass: top
> > objectClass: person
> > objectClass: organizationalPerson
> > objectClass: inetOrgPerson
> > description: This is user4F's description
> > mail:
> > use...@test.com
> >
> > userPassword: user4F
> > userCertificate;binary::
> MIID5zCCA1CgAwIBAgIDAIF5MA0GCSqGSIb3DQEBBQUAMF4xCzAJ
> >
> BgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UE
> >
> CxMDUEtJMRkwFwYDVQQDExBET0QgQ0xBU1MgMyBDQS0zMB4XDTAxMTExNDAwMDAwMFoXDTA0MTEx
> >
> MzAwMDAwMFowdTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE
> >
> CxMDRG9EMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAsTA1VTTjEiMCAGA1UEAxMZU0xBQ0suU1RBQ0VZ
> >
> LkouMTAzNTQ3MjE4MTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnma4IZobULRwrDto4O/U
> >
> mXXVtW1MDuYhooo7/5H6O+9WVWIHMKNW+TvonliezYE/N3VwHG8IFJrnjzHjtrmD/iYi+kl3jz5U
> >
> QmaS/F1fDiP2/G9hEhc5QP6ZCpjWUjf/0m0NjwFiAxLGWNQV9oBqhWU+fwBxD4gGMWRwzGrbVK8C
> >
> AwEAAaOCAZowggGWMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBQH4UHGgQthSDSPSnwyinB7
> >
> UgD4MzAdBgNVHQ4EFgQUa6cO9LyOgFuZhaw2S+CKYh8W6NIwFgYDVR0gBA8wDTALBglghkgBZQIB
> >
> CwkwfgYDVR0SBHcwdYZzbGRhcDovL2RzLTMuYzNwa2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0Ql
> >
> MjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292
> >
> ZXJubWVudCUyY2MlM2RVUzCBqwYDVR0fBIGjMIGgMIGdoIGaoIGXhoGUbGRhcDovL2RzLTMuYzNw
> >
> a2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBDQS0zJTJjb3UlM2RQS0kl
> >
> MmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJl
> >
> dm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOBgQB5aLv3JjaAb+eIOrW3niXs96na
> >
> mbjDq1IbWK55YVcpCBgD2fYasSlEmnt7ykQlYW8woRORaKv9ERpTcfcg4odi9VbtzIyzYHVyY5DU
> >  LuaEhqNiKCnjqWXPeMHmtD2H6nBiDAo6tfyitL5E+NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==
> >
> >
> >
> > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com" "(usercertificate;binary=*)"
> >
> > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com" "(usercertificate=*)"
> >
> > #./ldapsearch -p 9090 -D "cn=directory manager" -w secret12 -b
> "ou=people, dc=example, dc=com"
> "(usercertificate;binary=\4d\49\49\44\35\7a\43\43\41\31\43\67\41\77\49\42\41\67\49\44\41\49\46\35\4d\41\30\47\43\53\71\47\53\49\62\33\44\51\45\42\42\51\55\41\4d\46\34\78\43\7a\41\4a\42\67\4e\56\42\41\59\54\41\6c\56\54\4d\52\67\77\46\67\59\44\56\51\51\4b\45\77\39\56\4c\6c\4d\75\49\45\64\76\64\6d\56\79\62\6d\31\6c\62\6e\51\78\44\44\41\4b\42\67\4e\56\42\41\73\54\41\30\52\76\52\44\45\4d\4d\41\6f\47\41\31\55\45\43\78\4d\44\55\45\74\4a\4d\52\6b\77\46\77\59\44\56\51\51\44\45\78\42\45\54\30\51\67\51\30\78\42\55\31\4d\67\4d\79\42\44\51\53\30\7a\4d\42\34\58\44\54\41\78\4d\54\45\78\4e\44\41\77\4d\44\41\77\4d\46\6f\58\44\54\41\30\4d\54\45\78\4d\7a\41\77\4d\44\41\77\4d\46\6f\77\64\54\45\4c\4d\41\6b\47\41\31\55\45\42\68\4d\43\56\56\4d\78\47\44\41\57\42\67\4e\56\42\41\6f\54\44\31\55\75\55\79\34\67\52\32\39\32\5a\58\4a\75\62\57\56\75\64\44\45\4d\4d\41\6f\47\41\31\55\45\43\78\4d\44\52\47\39\45\4d\51\77\77\43\67\59\44\56\51\51\4c\45\77\4e\51\53\30\6b\78\44\44\41\4b\42\67\4e\56\42\41\73\54\41\31\56\54\54\6a\45\69\4d\43\41\47\41\31\55\45\41\78\4d\5a\55\30\78\42\51\30\73\75\55\31\52\42\51\30\56\5a\4c\6b\6f\75\4d\54\41\7a\4e\54\51\33\4d\6a\45\34\4d\54\43\42\6e\7a\41\4e\42\67\6b\71\68\6b\69\47\39\77\30\42\41\51\45\46\41\41\4f\42\6a\51\41\77\67\59\6b\43\67\59\45\41\6e\6d\61\34\49\5a\6f\62\55\4c\52\77\72\44\74\6f\34\4f\2f\55\6d\58\58\56\74\57\31\4d\44\75\59\68\6f\6f\6f\37\2f\35\48\36\4f\2b\39\57\56\57\49\48\4d\4b\4e\57\2b\54\76\6f\6e\6c\69\65\7a\59\45\2f\4e\33\56\77\48\47\38\49\46\4a\72\6e\6a\7a\48\6a\74\72\6d\44\2f\69\59\69\2b\6b\6c\33\6a\7a\35\55\51\6d\61\53\2f\46\31\66\44\69\50\32\2f\47\39\68\45\68\63\35\51\50

[389-devel] Re: How to create a user with certificate with lib389

[Anuj Borah]

x100\x0e\x06\x03U\x04\n\x13\x07testing1\x110\x0f\x06\x03U\x04\x03\x13\x08testuser0\x82\x02"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x02\x0f\x000\x82\x02\n\x02\x82\x02\x01\x00\xb5\x14i\xf7\x1f0\xe8hc\xef\x02\xdc\xbf\xc8`\xf9Z\xc5\xecv\x05\xc6*m6\xc3\xf8U\xa8\x9d\x19i\xe2\x915\t\xd6[\x93\xfd\xa3w9\'t\x15L\x97\x88\x93\x17b\xf4\xfb-\xd2\xc8\xd3\xac\x1b\xc2\xe8\x9d\xb7a\xc7>[\xc7\x08s\x84:S\x04=\xf0-\xb1e\x17\x9a\xfd}\xeeUG\xb2\x9fn\x1b\xcbQ#\xe9~\xb6\xbeQ\xf8b\x178\x11>L\x88\xb5H\xba([\xdcs\xd6m\xda\xda\x17\x07\'Qi\xe7\xf4\xca<\x08\xdb+\xff\x8aW\x9e\x96\xb0\x9e\x14\xa0\xedP\xd3\xc0\x8dy\xc7\x9e\xa5\xc7\xfd\xaa\xa9\x9bw\x18c-\nZ\xacRx\xa7\xb8\x11?2\x9aG\xdf&\xcd\x93\xb2\x89\x9d\xee\x87\xe0s\x05\xadq\xee[t\xccmn\x176\xb1\x12\x1bm\xb7PD\x87\xf4\x99z\xe8\x9aE\xdf\xb4\x05\xe3M\x96\xfd\x81@,4D\x9f\xb9\x1c.\x95\x8do\x93&9-\x18T\xbc;\xae\x7f\x13+\x12z(\'\x9b{k\xaa\x0e\xb0a\xab\xb3$\x1dt\xe5\x890\xf1\x1a\x92\xe2[2\x90\xbf"\x89\xcc\x90\x97E\xea\x83g}gk\xb8Z\x81q\xf3\xf5\xa4\x1cc\x88\xdc\xf5dV\xc4\xfd{\x9d\x04A.\x1cta\xf3\n\xd1\xe6\xe9c\x1fv>\x01D\xd4R\xe8U\x9b\xb6"\xba\x8d\xb7\x07N5\x0bY`\x81SW\xa5\xe0\xb1\x91\xc60$1/%\xf4\xf3\\\xa3\xab\x80\xbd\x0f\x93~\xae\xe0Xg\xb1q_\xcd\xc5\x89\xba#\x925\xd7\xa2\x06\xd4\x8es\xaf
> \xdd\x89\x8cg\'\xe3\x08\x05\xcf\x93\xbe\xd3\x12\xaa\xe6\xf0\xa7p\x04\xa2\xe0\xf7I\xe7\xca1#b\xaa\xae0\xc2\x0f\xcc"U\xa3!\xf4rI\xb3\x03\xf5\xbc\nT8TA\xda\xbf\xac\xb8\xc7\xde\xd1:x\x9a\x1f\x97\xd7\x0bMB\xfaa\xfb\xb1\x8a7\xfa\x00Q\xa4p\x07\xe1^\xd6\xe5.
> w\x8d\xe2\xa2\xaa0\xbd\xd6\n\x96\x87\xe6\xdb]\x11H\x13\x1et.\x80\xa8\x94*9\xe6e\x00\x99\xbb\x1e\xe3?\xd15!_\x08n\x89V%\x83\xad\x18\x93\xcb\xc2\xe2\x0e\x01\x9f\x0e=\xad\x02\x03\x01\x00\x01\xa37050\x11\x06\t`\x86H\x01\x86\xf8B\x01\x01\x04\x04\x03\x02\x07\x800\x13\x06\x03U\x1d%\x04\x0c0\n\x06\x08+\x06\x01\x05\x05\x07\x03\x020\x0b\x06\x03U\x1d\x0f\x04\x04\x03\x02\x04\xf00\r\x06\t*\x86H\x86\xf7\r\x01\x01\x0b\x05\x00\x03\x82\x02\x01\x00Jj\xf5\x95\x91v\x95\xd3\x176-c\xef\xafm\x96rC\xe1\x03\x03"#\xdf\x88\xca\xce`\xac^\xf9\xd3\xe8\xb2\x1f\xbb\xa2\xb5u\x86e\xf3v\xe1,\xaa\xe2\xba\xb1fB(\xd9o\xdf\tT$\xfe\x8b\xb2\xe9
> &\xfa\x95W\rS\xd2s\xf4+V\x7f\xd7\x16N\xfaj\\\xf9GF\x04\xbe\xab\x11\x87\xf7\xab\xc8C\x83\xc3?7\x08\xecxa>\\\xfbL{n=\x8dc\x15\xd1\x7f\xbd\x8f\'l\xd7VF\xb5\xb2\x9a\xb0\x98\xc6M\xbbs\xb6\xb5\x83\x97+\x8b\x13\xf0\x82\x0b5*\xfd\xce\xcbN9_+\xf9s\xd2\x9f\x03\x9du
> @\xbf\x0ce\xb0S#\x95\xc7\xa9{\x81\x84\x17U9\xd6\x1a\xac\x05\xf8\x97\xcb\xa1\x9b\xd6\x96\xa3\xdd\x92\x81\xfb7wG=\xd9\x99B\xc1\xbddH!\x8e\xc9D\xd9&\xdaR\x9d\x97\xa6\xfc\xa1S\xa5\xd8k\xca\xbd4S\x02\x9em\x84\xd3\xb2f\xed\x1f\xd2\xa5\xa8\x7f\x82]\x18\x8a\xc7\x06\xe8S-#q\x08I\xa8\x10o\x9b\xf1
> \x94\xfdR9\xd8~?r\xec\xcb\xbfS}p@J
> ,\xf6\x99I\x1f\x13-\x15\x90cn\xe9\xab\x17\x1c\xe2\x08\x88M/4\xe0\xcd~\xfb\npp!\xd0:\xf5\xf59c$I,\xb8\x1e\xda\xe3\xba\xcc\x90[\x00r\xb2\xcf\xe1Fo?\xa5\x03\xea\x0b\x14\xc4\x98<\rLq\x16\xa0F\x97\xb9\x15\xd8E\xa1\xa8\xeb\xc1\'\xba4\x81+\x87#\x1f\x86\x01\x8b\x1e\xbe\xceA<\xe7FY*i\xf6\xa6\xb1\xb9\xf1kg\xf8\x1f5e0\x0c5\x8f\x90\x83\xe2\xe0\x9e$r\xa9\x02\xf4LoPTc\x15\xf2\xc9\x8a\xf0\xf1m.\x15\xaer\xb8\x86\xb4O2\xb5\xda\x0c\xfa\xfc\x081\\\xa3\x80\xb0\x7f\xd6\x1cg}\x89\xa9x\x84o\\\xef\x8e\x83\xfc\xa32\xa8Dl\xcd\xbd\x1bE\x1b8\x9d\xc3\'&\xd5\xc5\xa2\xfe5\xfe7un\xd9\xba\xf9[=\x16\x99\xd0(\xf2v\xef3\x1b\x1bd\xba\xdc\xd45W\xef\x8c\xe8F\xe0\x81\x1e\xdcA\xb1A\x12\xbc\xec:\xddI\xa7{\x08\xb2\xcb\x84\xd3\xa8i\xb2\xd7\x81'
> >
> >
> > (Pdb) Accounts(standalone,
> DEFAULT_SUFFIX).filter(f"(userCertificate={crt})")
> > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info':
> 'No such file or directory'}
> >
> > And finally .
> > Accounts(standalone,
> DEFAULT_SUFFIX).filter(f"(userCertificate={escape_bytes(crt)})")  >>>
> escape_bytes(this is function i want to put in utils.py)
> >
> >
> >
> > Regards
> > Anuj Borah
> >
> >
> >
> > * Consider checking:
> https://pagure.io/389-ds-base/pull-request/49579#request_diff we can
> likely pull out the python from this branch and commit to master as it adds
> a lot of TLS support.
> >
> > Thanks
> >
> > —
> > Sincerely,
> >
> > William Brown
> >
> > Senior Software Engineer, 389 Directory Server
> > SUSE Labs
> >
>
> —
> 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: How to create a user with certificate with lib389

[Anuj Borah]

On Thu, Jun 13, 2019 at 6:05 PM William Brown  wrote:

>
>
> > On 13 Jun 2019, at 14:27, Anuj Borah  wrote:
> >
> > 
>
> Okay, so:
>
> * WHAT is the test you are creating? What does it test? How? What steps
> from start to finish? Please list this exactly.
> * Use SSCA to make the user cert - it creates pem and der copies
> * Have you looked at:
> https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/idm/account.py#_103


Till this point all ok . But not ok .  Its giving error .
(Pdb) Account(standalone,
'uid=testuser,ou=People,dc=example,dc=com').enroll_certificate(tls_locs['crt_der_path'])
*** NameError: name 'ds_is_older' is not defined

Or

(Pdb) users.list()[0].enroll_certificate(tls_locs['crt_der_path'])
*** NameError: name 'ds_is_older' is not defined

Is there a problem with account.py file .

https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/idm/account.py
It did not import >>>>   from lib389.utils import (ds_is_older)


Any way after using SSCA we have got the user with userCertificate field .

(Pdb) Account(standalone,
'uid=testuser,ou=People,dc=example,dc=com')._unsafe_raw_entry()
dn: uid=testuser,ou=People,dc=example,dc=com
cn: testuser
gidNumber: 2000
homeDirectory: /home/testuser
objectClass: top
objectClass: account
objectClass: posixaccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: nsMemberOf
objectClass: nsAccount
objectClass: person
sn: user
uid: testuser
uidNumber: 1000
userCertificate;binary::
MIIFcjCCA1qgAwIBAgIFALFmh3wwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCQVUxEzARBgNVBAgTClF1ZWVuc2xhbmQxDjAMBgNVBAcTBTM4OWRzMRAwDgYDVQQKEwd0ZXN0aW5nMR8wHQYDVQQDExZzc2NhLjM4OWRzLmV4YW1wbGUuY29tMB4XDTE5MDYxMzEzMDkwM1oXDTIxMDYxMzEzMDkwM1owVzELMAkGA1UEBhMCQVUxEzARBgNVBAgTClF1ZWVuc2xhbmQxDjAMBgNVBAcTBTM4OWRzMRAwDgYDVQQKEwd0ZXN0aW5nMREwDwYDVQQDEwh0ZXN0dXNlcjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALUUafcfMOhoY+8C3L/IYPlaxex2BcYqbTbD+FWonRlp4pE1CdZbk/2jdzkndBVMl4iTF2L0+y3SyNOsG8Lonbdhxz5bxwhzhDpTBD3wLbFlF5r9fe5VR7KfbhvLUSPpfra+UfhiFzgRPkyItUi6KFvcc9Zt2toXBydRaef0yjwI2yv/ileelrCeFKDtUNPAjXnHnqXH/aqpm3cYYy0KWqxSeKe4ET8ymkffJs2Tsomd7ofgcwWtce5bdMxtbhc2sRIbbbdQRIf0mXromkXftAXjTZb9gUAsNESfuRwulY1vkyY5LRhUvDuufxMrEnooJ5t7a6oOsGGrsyQddOWJMPEakuJbMpC/IonMkJdF6oNnfWdruFqBcfP1pBxjiNz1ZFbE/XudBEEuHHRh8wrR5uljH3Y+AUTUUuhVm7Yiuo23B041C1lggVNXpeCxkcYwJDEvJfTzXKOrgL0Pk36u4FhnsXFfzcWJuiOSNdeiBtSOc68g3YmMZyfjCAXPk77TEqrm8KdwBKLg90nnyjEjYqquMMIPzCJVoyH0ckmzA/W8ClQ4VEHav6wmcLjH3tE6eJofl9cLTUL
 
6Yfuxijf6AFGkcAfhXtblLiB3jeKiqjC91gqWh+bbXRFIEx50LoColCo55mUAmbse4z/RNSFfCG6JViWDrRiTy8LiDgGfDj2tAgMBAAGjNzA1MBEGCWCGSAGG+EIBAQQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAjALBgNVHQ8EBAMCBPAwDQYJKoZIhvcNAQELBQADggIBAEpq9ZWRdpXTFzYtY++vbZZyQ+EDAyIj34jKzmCsXvnT6LIfu6K1dYZl83bhLKriurFmQijZb98JVCT+i7LpICb6lVcNU9Jz9CtWf9cWTvpqXPlHRgS+qxGH96vIQ4PDPzcI7HhhPlz7THtuPY1jFdF/vY8nbNdWRrWymrCYxk27c7a1g5crixPwggs1Kv3Oy045Xyv5c9KfA511IEC/DGWwUyOVx6l7gYQXVTnWGqwF+JfLoZvWlqPdkoH7N3dHPdmZQsG9ZEghjslE2SbaUp2XpvyhU6XYa8q9NFMCnm2E07Jm7R/Spah/gl0YiscG6FMtI3EISagQb5vxIJT9UjnYfj9y7Mu/U31wQEos9plJHxMtFZBjbumrFxziCIhNLzTgzX77CnBwIdA69fU5YyRJLLge2uO6zJBbAHKyz+FGbz+lA+oLFMSYPA1McRagRpe5FdhFoajrwSe6NIErhyMfhgGLHr7OQTznRlkqafamsbnxa2f4HzVlMAw1j5CD4uCeJHKpAvRMb1BUYxXyyYrw8W0uFa5yuIa0TzK12gz6/AgxXKOAsH/WHGd9ial4hG9c746D/KMyqERszb0bRRs4ncMnJtXFov41/jd1btm6+Vs9FpnQKPJ27zMbG2S63NQ1V++M6EbggR7cQbFBErzsOt1Jp3sIssuE06hpsteB


Now i want to filter that user with filter.

(Pdb) crt = open('/etc/dirsrv/slapd-standalone1/user-testuser.der',
'rb').read()
(Pdb) crt
b'0\x82\x05r0\x82\x03Z\xa0\x03\x02\x01\x02\x02\x05\x00\xb1f\x87|0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x0b\x05\x000e1\x0b0\t\x06\x03U\x04\x06\x13\x02AU1\x130\x11\x06\x03U\x04\x08\x13\nQueensland1\x0e0\x0c\x06\x03U\x04\x07\x13\x05389ds1\x100\x0e\x06\x03U\x04\n\x13\x07testing1\x1f0\x1d\x06\x03U\x04\x03\x13\x16ssca.389ds.example.com0\x1e\x17\r190613130903Z\x17\r210613130903Z0W1\x0b0\t\x06\x03U\x04\x06\x13\x02AU1\x130\x11\x06\x03U\x04\x08\x13\nQueensland1\x0e0\x0c\x06\x03U\x04\x07\x13\x05389ds1\x100\x0e\x06\x03U\x04\n\x13\x07testing1\x110\x0f\x06\x03U\x04\x03\x13\x08testuser0\x82\x02"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x02\x0f\x000\x82\x02\n\x02\x82\x02\x01\x00\xb5\x14i\xf7\x1f0\xe8hc\xef\x02\xdc\xbf\xc8`\xf9Z\xc5\xecv\x05\xc6*m6\xc3\xf8U\xa8\x9d\x19i\xe2\x915\t\xd6[\x93\xfd\xa3w9\'t\x15L\x97\x88\x93\x17b\xf4\xfb-\xd2\xc8\xd3\xac\x1b\xc2\xe8\x9d\xb7a\xc7>[\xc7\x08s\x84:S\x04=\xf0-\xb1e\x17\x9a\xfd}\xeeUG\xb2\x9fn\x1b\xcbQ#\xe9~\xb6\xbeQ\xf8b\x178\x11>L\x88\xb5H\xba([\xdcs\xd6m\xda\xda\x17\x07\'Qi\xe7\xf4\xca<\x08\xdb+\xff\x8aW\x9e\x96\xb0\x9e\x14\xa0\xedP\xd3\xc0\x8dy\xc7\x9e\xa5\xc7\xfd\xaa\xa9\x9bw\x18c-\nZ\xacRx\xa7\xb8\x11?2\x9aG\xdf&\xcd\x93\xb2\x89\x9d\xee\x87\xe0s\x05\xadq\xee[t\xccmn\x176\xb1\x12\x1bm\xb7PD\x87\xf4\x99z\xe8\x9aE\xdf\xb4\x05\xe3M\x96\xfd\x81@,4D\x9f\xb9\x1c.\x95\x8do\x93&9-\x18T\xbc;\xae\x7f\x13+\x12z(\'\x9b{k\xaa\x0e\xb0a\xab\xb3$\x1dt\xe5\x890\xf1\x1a\x92\xe2[2\

[389-devel] Re: How to create a user with certificate with lib389

[Anuj Borah]

@William Brown 

Please check the attached test case .

I want to put escape_bytes function to lib389 utils.py file .


Regards
Anuj Borah


On Mon, Jun 10, 2019 at 2:18 PM William Brown  wrote:

>
>
> > On 9 Jun 2019, at 03:40, Anuj Borah  wrote:
> >
> > @William Brown
> >
> > Yes, it does.
> >
> > Currently i am porting this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=170520
> >
> > I think with help of this script it will be impossible to port it .
>
> I'm not authorised to view that bug. :)
>
> I think youll need to describe, exactly, in sequence the order of events
> you want to test so I can advise properly.
>
> >
> > Do you have any advice .
> >
> > Regards
> > Anuj Borah
> >
> >
> > On Fri, Jun 7, 2019 at 2:47 PM William Brown  wrote:
> > I haven't read the link but maybe there is some confusion about TLS
> binding here. You do the create_rsa_user and that only set's up the
> certificates.
> >
> > > On 4 Jun 2019, at 17:51, Anuj Borah  wrote:
> > >
> > > @William Brown
> > >
> > > Thanks , I am doing the same . Trying to follow it . (i have make this
> script 99% pass)
> > >
> > > But its way too old . It uses some like :
> > >
> > > standalone.nss_ssl.create_rsa_user('testuser')    not valid
> (NssSsl(standalone).create_rsa_user('testuser'))
> > >
> > > standalone.nss_ssl.get_rsa_user('testuser')   -- not valid
> (NssSsl(standalone).get_rsa_user('testuser'))
> >
> > IIRC this syntax is valid, but maybe the linking type was removed.
> >
> > >
> > > standalone.openConnection ---  I dont know what is it . May be bind.
> >
> > Yes, i think this is bind now. If you grep for create_rsa_user in the
> tests you may find another example.
> >
> > >
> > > And Most importantly, after i have make this script 99% pass . I am
> not able to see the usercertificate field in the test user that was created
> during the test . while i do _unsafe_raw_entry()
> >
> > Because you don't need it. The certificate's cn is mapped to the cn in
> the directory, and then because the certificate was issued be the ca, it
> "confirms" the users identity. No userCertificate attribute required.
> >
> > There is a configuration that DOES require the certificate to not only
> be signed, but also in userCertificate for binary matching, but this is a
> configuration option, not the default. I seem to recall helping document
> all this with Marc, so it should be in the latest RHDS documentation.
> Generally though, the userCertificate attribute today would be used to
> allow a client like SSSD to read the userCertificate to allow smartCard
> authentication to a workstation.
> >
> > Does that help a bit?
> >
> > >
> > > Also mind changing the lib389 doc
> https://spichugi.fedorapeople.org/html/guidelines.html#setting-up-ssl-tls
> . Its the same test case given there , which is not relevant now .
> > >
> > > Regards
> > > Anuj Borah
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Jun 4, 2019 at 9:08 PM William Brown  wrote:
> > > I'm currently traveling at the moment, but I can have a look later to
> update this to work on latest lib389 etc.
> > >
> > > You can read it and use it as an example though, even if it doesn't
> pass ...
> > >
> > >
> > >
> > >
> > > > On 4 Jun 2019, at 16:32, Anuj Borah  wrote:
> > > >
> > > > @William Brown
> > > >
> > > > This test script does not pass . Its too old .
> > > >
> > > > Regards
> > > > Anuj Borah
> > > >
> > > > On Tue, Jun 4, 2019 at 8:00 PM William Brown  wrote:
> > > > Have a look at this test case if you want to do usercertificate
> generation and authentication :)
> > > >
> > > >
> https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/tests/tls_external_test.py
> > > >
> > > > > On 4 Jun 2019, at 14:31, Anuj Borah  wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Let say i want to create a user with userCertificate fileld. My
> user will look like bellow.
> > > > >
> > > > > users_people = UserAccounts(topo.standalone, DEFAULT_SUFFIX)
> > > > > users_people.create(properties={
> > > > > 'uid': 'certUser2

[389-devel] Re: How to create a user with certificate with lib389

[Anuj Borah]

@William Brown 

Yes, it does.

Currently i am porting this bug
https://bugzilla.redhat.com/show_bug.cgi?id=170520

I think with help of this script it will be impossible to port it .

Do you have any advice .

Regards
Anuj Borah


On Fri, Jun 7, 2019 at 2:47 PM William Brown  wrote:

> I haven't read the link but maybe there is some confusion about TLS
> binding here. You do the create_rsa_user and that only set's up the
> certificates.
>
> > On 4 Jun 2019, at 17:51, Anuj Borah  wrote:
> >
> > @William Brown
> >
> > Thanks , I am doing the same . Trying to follow it . (i have make this
> script 99% pass)
> >
> > But its way too old . It uses some like :
> >
> > standalone.nss_ssl.create_rsa_user('testuser')    not valid
> (NssSsl(standalone).create_rsa_user('testuser'))
> >
> > standalone.nss_ssl.get_rsa_user('testuser')   -- not valid
> (NssSsl(standalone).get_rsa_user('testuser'))
>
> IIRC this syntax is valid, but maybe the linking type was removed.
>
> >
> > standalone.openConnection ---  I dont know what is it . May be bind.
>
> Yes, i think this is bind now. If you grep for create_rsa_user in the
> tests you may find another example.
>
> >
> > And Most importantly, after i have make this script 99% pass . I am not
> able to see the usercertificate field in the test user that was created
> during the test . while i do _unsafe_raw_entry()
>
> Because you don't need it. The certificate's cn is mapped to the cn in the
> directory, and then because the certificate was issued be the ca, it
> "confirms" the users identity. No userCertificate attribute required.
>
> There is a configuration that DOES require the certificate to not only be
> signed, but also in userCertificate for binary matching, but this is a
> configuration option, not the default. I seem to recall helping document
> all this with Marc, so it should be in the latest RHDS documentation.
> Generally though, the userCertificate attribute today would be used to
> allow a client like SSSD to read the userCertificate to allow smartCard
> authentication to a workstation.
>
> Does that help a bit?
>
> >
> > Also mind changing the lib389 doc
> https://spichugi.fedorapeople.org/html/guidelines.html#setting-up-ssl-tls
> . Its the same test case given there , which is not relevant now .
> >
> > Regards
> > Anuj Borah
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Jun 4, 2019 at 9:08 PM William Brown  wrote:
> > I'm currently traveling at the moment, but I can have a look later to
> update this to work on latest lib389 etc.
> >
> > You can read it and use it as an example though, even if it doesn't pass
> ...
> >
> >
> >
> >
> > > On 4 Jun 2019, at 16:32, Anuj Borah  wrote:
> > >
> > > @William Brown
> > >
> > > This test script does not pass . Its too old .
> > >
> > > Regards
> > > Anuj Borah
> > >
> > > On Tue, Jun 4, 2019 at 8:00 PM William Brown  wrote:
> > > Have a look at this test case if you want to do usercertificate
> generation and authentication :)
> > >
> > >
> https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/tests/tls_external_test.py
> > >
> > > > On 4 Jun 2019, at 14:31, Anuj Borah  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > Let say i want to create a user with userCertificate fileld. My user
> will look like bellow.
> > > >
> > > > users_people = UserAccounts(topo.standalone, DEFAULT_SUFFIX)
> > > > users_people.create(properties={
> > > > 'uid': 'certUser2',
> > > > 'cn': 'CUser2',
> > > > 'sn': 'CertificateUser2',
> > > > 'givenName': 'CU2',
> > > > 'description': "This is certUser2's description",
> > > > 'mail': 'certus...@example.com',
> > > > 'userPassword': PW_DM,
> > > > 'userCertificate':
> 'some_cert_+++NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==',
> > > > 'manager': f'uid=certUser2,ou=People,{DEFAULT_SUFFIX}',
> > > > 'homeDirectory': '/home/' + 'certUser2',
> > > > 'uidNumber': '1000',
> > > > 'gidNumber': '2000'
> > > > })
> > > >
> > > > Here i have put userCertificate field manually (which i dont want to
> do). But how can i achieve this without putting userCertificate field
> manually . Like create a user and userCertificate field will be auto field
> with auto gener

[389-devel] Re: How to create a user with certificate with lib389

[Anuj Borah]

@William Brown 

Thanks , I am doing the same . Trying to follow it . (i have make this
script 99% pass)

But its way too old . It uses some like :

standalone.nss_ssl.create_rsa_user('testuser')    not valid
(NssSsl(standalone).create_rsa_user('testuser'))

standalone.nss_ssl.get_rsa_user('testuser')   -- not valid
(NssSsl(standalone).get_rsa_user('testuser'))

standalone.openConnection ---  I dont know what is it . May be bind.

And Most importantly, after i have make this script 99% pass . I am not
able to see the usercertificate field in the test user that was created
during the test . while i do _unsafe_raw_entry()

Also mind changing the lib389 doc
https://spichugi.fedorapeople.org/html/guidelines.html#setting-up-ssl-tls .
Its the same test case given there , which is not relevant now .

Regards
Anuj Borah







On Tue, Jun 4, 2019 at 9:08 PM William Brown  wrote:

> I'm currently traveling at the moment, but I can have a look later to
> update this to work on latest lib389 etc.
>
> You can read it and use it as an example though, even if it doesn't pass
> ...
>
>
>
>
> > On 4 Jun 2019, at 16:32, Anuj Borah  wrote:
> >
> > @William Brown
> >
> > This test script does not pass . Its too old .
> >
> > Regards
> > Anuj Borah
> >
> > On Tue, Jun 4, 2019 at 8:00 PM William Brown  wrote:
> > Have a look at this test case if you want to do usercertificate
> generation and authentication :)
> >
> >
> https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/tests/tls_external_test.py
> >
> > > On 4 Jun 2019, at 14:31, Anuj Borah  wrote:
> > >
> > > Hi all,
> > >
> > > Let say i want to create a user with userCertificate fileld. My user
> will look like bellow.
> > >
> > > users_people = UserAccounts(topo.standalone, DEFAULT_SUFFIX)
> > > users_people.create(properties={
> > > 'uid': 'certUser2',
> > > 'cn': 'CUser2',
> > > 'sn': 'CertificateUser2',
> > > 'givenName': 'CU2',
> > > 'description': "This is certUser2's description",
> > > 'mail': 'certus...@example.com',
> > > 'userPassword': PW_DM,
> > > 'userCertificate':
> 'some_cert_+++NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==',
> > > 'manager': f'uid=certUser2,ou=People,{DEFAULT_SUFFIX}',
> > > 'homeDirectory': '/home/' + 'certUser2',
> > > 'uidNumber': '1000',
> > > 'gidNumber': '2000'
> > > })
> > >
> > > Here i have put userCertificate field manually (which i dont want to
> do). But how can i achieve this without putting userCertificate field
> manually . Like create a user and userCertificate field will be auto field
> with auto generated certificates .
> > >
> > > 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
> >
> > —
> > 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
>
> —
> 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: How to create a user with certificate with lib389

[Anuj Borah]

@William Brown 

This test script does not pass . Its too old .

Regards
Anuj Borah

On Tue, Jun 4, 2019 at 8:00 PM William Brown  wrote:

> Have a look at this test case if you want to do usercertificate generation
> and authentication :)
>
>
> https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/tests/tls_external_test.py
>
> > On 4 Jun 2019, at 14:31, Anuj Borah  wrote:
> >
> > Hi all,
> >
> > Let say i want to create a user with userCertificate fileld. My user
> will look like bellow.
> >
> > users_people = UserAccounts(topo.standalone, DEFAULT_SUFFIX)
> > users_people.create(properties={
> > 'uid': 'certUser2',
> > 'cn': 'CUser2',
> > 'sn': 'CertificateUser2',
> > 'givenName': 'CU2',
> > 'description': "This is certUser2's description",
> > 'mail': 'certus...@example.com',
> > 'userPassword': PW_DM,
> > 'userCertificate':
> 'some_cert_+++NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==',
> > 'manager': f'uid=certUser2,ou=People,{DEFAULT_SUFFIX}',
> > 'homeDirectory': '/home/' + 'certUser2',
> > 'uidNumber': '1000',
> > 'gidNumber': '2000'
> > })
> >
> > Here i have put userCertificate field manually (which i dont want to
> do). But how can i achieve this without putting userCertificate field
> manually . Like create a user and userCertificate field will be auto field
> with auto generated certificates .
> >
> > 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
>
> —
> 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] How to create a user with certificate with lib389

[Anuj Borah]

Hi all,

Let say i want to create a user with userCertificate fileld. My user will
look like bellow.

users_people = UserAccounts(topo.standalone, DEFAULT_SUFFIX)
users_people.create(properties={
'uid': 'certUser2',
'cn': 'CUser2',
'sn': 'CertificateUser2',
'givenName': 'CU2',
'description': "This is certUser2's description",
'mail': 'certus...@example.com',
'userPassword': PW_DM,
'userCertificate': 'some_cert_+++NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==',
'manager': f'uid=certUser2,ou=People,{DEFAULT_SUFFIX}',
'homeDirectory': '/home/' + 'certUser2',
'uidNumber': '1000',
'gidNumber': '2000'
})

Here i have put userCertificate field manually (which i dont want to do).
But how can i achieve this without putting userCertificate field manually .
Like create a user and userCertificate field will be auto field with auto
generated certificates .

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] Re: Please review

[Anuj Borah]

@Simon Pichugin 

Please review:

https://pagure.io/389-ds-base/pull-request/50336

Regards
Anuj Borah


On Wed, May 15, 2019 at 8:50 PM Anuj Borah  wrote:

> @Simon Pichugin 
>
> Please review:
>
> https://pagure.io/389-ds-base/pull-request/50328
>
> Regards
> Anuj Borah
>
>
>
> On Thu, May 9, 2019 at 5:27 PM Anuj Borah  wrote:
>
>> @Simon Pichugin 
>>
>> This one is still pending .
>>
>> https://pagure.io/389-ds-base/pull-request/50192
>>
>> Regards
>> Anuj Borah
>>
>>
>> On Tue, Apr 30, 2019 at 4:03 PM Anuj Borah  wrote:
>>
>>> Hi Simon ,
>>>
>>> Rebsed onto master .
>>>
>>> Regards
>>> Anuj Borah
>>>
>>> On Tue, Apr 30, 2019 at 3:54 PM Simon Pichugin 
>>> wrote:
>>>
>>>> On Tue, Apr 30, 2019 at 02:15:55PM +0530, Anuj Borah wrote:
>>>> >Hi all,
>>>> Hi Anuj,
>>>>
>>>> >Please review these PRs.
>>>> >Pending from Long Time.
>>>> >[1]https://pagure.io/389-ds-base/pull-request/50180
>>>> >[2]https://pagure.io/389-ds-base/pull-request/50192
>>>> Could you please rebase them onto master?
>>>>
>>>> Thanks,
>>>> Simon
>>>>
>>>> >Regards
>>>> >Anuj Borah
>>>> >
>>>> > References
>>>> >
>>>> >1. https://pagure.io/389-ds-base/pull-request/50180
>>>> >2. https://pagure.io/389-ds-base/pull-request/50192
>>>>
>>>> > ___
>>>> > 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 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: Use of rust for new logging backend

[Anuj Borah]

Hi

I will also help from QA team(Test and automation ) , i started learning
"rust" 6 month ago (not regular ). I know 2% (may be).


Regards
Anuj Borah

On Wed, May 15, 2019 at 8:20 PM Simon Pichugin  wrote:

> On Tue, May 14, 2019 at 01:21:28PM +1000, William Brown wrote:
> > Hi all,
> >
> > So it's been a while since I pushed this, but again, I think I want to
> bring this up. I'd like to write the new logging backend in Rust.
> >
> > I'll start with a summary:
> >
> > Pros:
> > * Faster development time due to stricter code correctness guarantees
> > * Modern and safe language to lower number of bugs in implementation
> > * Much better libraries for interacting with things like json and thread
> safety
> >
> > Cons:
> > * Another language in the codebase ...
> > * We need to learn it to work on it
> > * Vendors need to be ready to build with the toolchain
> >
> > I've talked through some of these thoughts with Mark a bit, and I really
> think it's time we did this - or gave up on pursuing it. I have been
> running the rust enabled version of ds for a few years now with no issues.
> SUSE is also in a position where they are able to and ready to build DS
> with Rust (I'm assuming RH could easily also be brought to parity here).
> >
> > So the main barrier becomes us: the most common argument is we don't
> know enough or have enough experience. However I think this argument is
> flawed, in the fact that there are many parts of the code where we already
> only have 1 or 2 experts in that area - often when we look into a bug or a
> feature, we always have to learn new things, we have to read the code,
> understand even the unique styles of how that was written for the time, and
> then do work. This would be no different. I think we are all capable of
> learning and working with these tools.
> >
> > By this point, Gnome is looking into Rust as a mainline part of the
> desktop, Samba has started to look into it, Firefox is already shipping
> Rust components. I think that Rust is here to stay, and is not some passing
> trend.
> >
> >
> > So what do we think? I think if there are no major objections I would
> like to do this in Rust. I'll also commit to providing C-Rust FFI
> documentation for the team, resources to help understand what's going on,
> and like always, I will be sure to comment all my code thoroughly as part
> of this improvement.
> Hi William,
> I am more than interested!
>
> I'd like to learn it one day anyway.
> So if there will be no objections and we'll go forward now,
> I think, it is important to agree on some points of decreasing a bus
> factor:
>
> - As you said, it should have very detailed comments on all of the
>   language features and technics you'll use.
> - I think it will be nice to have an additional documentation which will
>   describe the basic setup for the development you use. All the toold you
>   need to develop, compile, test and debug.
> - Also, some nice links for the basic tutorials on Rust types, concepts,
> etc.
> - I think, we should have detailed unit tests. It will help to
>   understand the code better and we will have less bugs (hopefully).
>
> And the final and big point I wanted to mention:
>
> - We should be prepared for a slow review process because we have quite
> limited
>   recources in the team and a lot of work should be done (WebUI still has
> to be refactored to React,
>   and it is only a small piece of the workload).
>   Also, I think, it makes sense to have the smallest Rust PRs that can be
> put together as an independent unit.
>
> But everything is just my opinion and I don't know what others think and
> if everyone is prepared to join it. I am feeling excited though :)
>
> Thanks,
> Simon
>
> P.S. check the contribution guide please. Espesially a part about
> 'rebase-force-push'. I think it is nice not to force push during
> the review process (and rebase-squash only after you got an ACK).
>
>
> >
> >
> > —
> > 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] 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
>> > te

[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 ...)

[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 .
> > > &g

[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: Please review

[Anuj Borah]

Hi Simon ,

Rebsed onto master .

Regards
Anuj Borah

On Tue, Apr 30, 2019 at 3:54 PM Simon Pichugin  wrote:

> On Tue, Apr 30, 2019 at 02:15:55PM +0530, Anuj Borah wrote:
> >Hi all,
> Hi Anuj,
>
> >Please review these PRs.
> >Pending from Long Time.
> >[1]https://pagure.io/389-ds-base/pull-request/50180
> >[2]https://pagure.io/389-ds-base/pull-request/50192
> Could you please rebase them onto master?
>
> Thanks,
> Simon
>
> >Regards
> >Anuj Borah
> >
> > References
> >
> >1. https://pagure.io/389-ds-base/pull-request/50180
> >2. https://pagure.io/389-ds-base/pull-request/50192
>
> > ___
> > 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 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] Please review

[Anuj Borah]

Hi all,

Please review these PRs.

Pending from Long Time.

https://pagure.io/389-ds-base/pull-request/50180
https://pagure.io/389-ds-base/pull-request/50192

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] 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

[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

[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

[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

[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

[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.0004453

[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] Groups are not accessible by filter

[Anuj Borah]

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
# --- BEGIN COPYRIGHT BLOCK ---
# Copyright (C) 2019 Red Hat, Inc.
# All rights reserved.
#
# License: GPL (version 3 or any later version).
# See LICENSE for details.
# --- END COPYRIGHT BLOCK ---


import os
import re
import pytest

from lib389._constants import DEFAULT_SUFFIX, PW_DM
from lib389.topologies import topology_st as topo
from lib389.idm.user import UserAccount, UserAccounts
from lib389.idm.organizationalunit import OrganizationalUnit, OrganizationalUnits
from lib389.index import Index
from lib389.idm.account import Accounts

import ldap


GIVEN_NAME = 'cn=givenname,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
CN_NAME = 'cn=sn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
uniquemember = 'cn=uniquemember,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
objectclass = 'cn=objectclass,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
mail = 'cn=mail,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
ACLG_OU = f'ou=ACLGroup,{DEFAULT_SUFFIX}'
NESG_OU = f'ou=nestedgroup, {DEFAULT_SUFFIX}'

LIST_OF_USER_ACCOUNTING = [
f"uid=Ted Morris, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=David Miller, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Gern Farmer, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Judy Wallace, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Marcus Ward, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Judy McFarland, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Anuj Hall, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Gern Triplett, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Emanuel Johnson, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Brad Walker, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Tobias Pierce, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Randy Mills, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=David Thorud, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Elba Kohler, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Laurel Campbell, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Torrey Schneider, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Paula Rose, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Frank Albers, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Martin Schneider, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Andrew Hel, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Pete Tyler, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Randy Ulrich, ou=Accou

[389-devel] Re: UserAccounts creates users with junk sign

[Anuj Borah]

@William Brown 

Thanks for the reply .

I was wondering if UserAccount can do it , why UserAccounts cant .

Anyway now i will go for 3. (best) to solve the problem.

Thanks
Anuj Borah

On Wed, Mar 27, 2019 at 5:45 AM William Brown  wrote:

> Hi,
>
> I have previously commented a number of times on this pattern that you
> have been using and that it is incorrect in reviews.
>
> > On 26 Mar 2019, at 13:27, Anuj Borah  wrote:
> >
> > Hay everyone,
> >
> > Consider bellow condition:
> >
> > users = UserAccounts(topo.standalone, f"ou=Keywords,{DEFAULT_SUFFIX}",
> rdn=None)
> > for i in [f'NONE_2_KEY,ou=Authmethod',
> >   f'EVERYDAY_KEY,ou=Dayofweek',
> >   f'TODAY_KEY,ou=Dayofweek',
> >   f'NODAY_KEY,ou=Dayofweek',
> >   f'NETSCAPEDNS_KEY,ou=DNS',
> >   f'FULLIP_KEY,ou=IP',
> >   f'NETSCAPEIP_KEY,ou=IP',
> >   f'NOIP_KEY,ou=IP',
> >   f'FULLWORKER_KEY,ou=Timeofday',
> >   f'DAYWORKER_KEY,ou=Timeofday',
> >   f'NIGHTWORKER_KEY,ou=Timeofday',
> >   f'NOWORKER_KEY,ou=Timeofday']:
> > properties = {
> > 'uid': i,
> > 'cn': i.split(',')[0],
> > 'sn': 'user',
> > 'uidNumber': '1000',
> > 'gidNumber': '2000',
> > 'homeDirectory': '/home/' + i,
> > 'userPassword': PW_DM
> > }
> > users.create(properties=properties)
>
> ^ This is where the mistake happens. UserAccounts *already* knows that you
> have an rdn etc. So then you say “users.create(uid = “everyday_key,ou=….”).
>
> So it LITERALLY takes that, escapes the content (which is the cause of the
> \\2C and \\3D you see below) and put’s that into the field)
>
>
> >
> >
> > If you see the created users:
> >
> > for i in users.list(): i.dn
> > 'uid=NONE_2_KEY\\2Cou\\3DAuthmethod,ou=Keywords,dc=example,dc=com'
> > 'uid=EVERYDAY_KEY\\2Cou\\3DDayofweek,ou=Keywords,dc=example,dc=com'
> > 'uid=TODAY_KEY\\2Cou\\3DDayofweek,ou=Keywords,dc=example,dc=com'
> > 'uid=NODAY_KEY\\2Cou\\3DDayofweek,ou=Keywords,dc=example,dc=com'
> > 'uid=NETSCAPEDNS_KEY\\2Cou\\3DDNS,ou=Keywords,dc=example,dc=com'
> > 'uid=FULLIP_KEY\\2Cou\\3DIP,ou=Keywords,dc=example,dc=com'
> > 'uid=NETSCAPEIP_KEY\\2Cou\\3DIP,ou=Keywords,dc=example,dc=com'
> > 'uid=NOIP_KEY\\2Cou\\3DIP,ou=Keywords,dc=example,dc=com'
> > 'uid=FULLWORKER_KEY\\2Cou\\3DTimeofday,ou=Keywords,dc=example,dc=com'
> > 'uid=DAYWORKER_KEY\\2Cou\\3DTimeofday,ou=Keywords,dc=example,dc=com'
> > 'uid=NIGHTWORKER_KEY\\2Cou\\3DTimeofday,ou=Keywords,dc=example,dc=com'
> > 'uid=NOWORKER_KEY\\2Cou\\3DTimeofday,ou=Keywords,dc=example,dc=com'
> >
> > We can see users become useless to use for further operations.
> >
> > And consider bellow condition:
> >
> >
> > for i in [f'NONE_2_KEY,ou=Authmethod',
> >   f'EVERYDAY_KEY,ou=Dayofweek',
> >   f'TODAY_KEY,ou=Dayofweek',
> >   f'NODAY_KEY,ou=Dayofweek',
> >   f'NETSCAPEDNS_KEY,ou=DNS',
> >   f'FULLIP_KEY,ou=IP',
> >   f'NETSCAPEIP_KEY,ou=IP',
> >   f'NOIP_KEY,ou=IP',
> >   f'FULLWORKER_KEY,ou=Timeofday',
> >   f'DAYWORKER_KEY,ou=Timeofday',
> >   f'NIGHTWORKER_KEY,ou=Timeofday',
> >   f'NOWORKER_KEY,ou=Timeofday']:
> > properties = {
> > 'uid': i,
> > 'cn': i.split(',')[0],
> > 'sn': 'user',
> > 'uidNumber': '1000',
> > 'gidNumber': '2000',
> > 'homeDirectory': '/home/' + i,
> > 'userPassword': PW_DM
> > }
> > users = UserAccount(topo.standalone,
> f"cn={i},ou=Keywords,{DEFAULT_SUFFIX}")
> > users.create(properties=properties)
> >
> >
> > users = UserAccounts(topo.standalone, f"ou=Keywords,{DEFAULT_SUFFIX}",
> rdn=None)
> >
> > for i in users.list(): i.dn
> > 'cn=NONE_2_KEY,ou=Authmethod,ou=Keywords,dc=example,dc=com'
> > 'cn=EVERYDAY_KEY,ou=Dayofweek,ou=Keywords,dc=example,dc=com'
> > 'cn=TODAY_KEY,ou=Dayofweek,ou=Keywords,dc=example,dc=com'
> > 'cn=NODAY_KEY,ou=Dayofweek,ou=Keywords,dc=example,dc=com'
> > 'cn=NETSCAPEDNS_KEY,ou=DNS,ou=Keywords,dc=example,dc=com'
> > 'cn=FULLIP_KEY,ou=IP,ou=Keywords,dc=example,dc=com'
> > 'cn=NETSCAPEIP_KEY,ou=IP,ou=Keywords,dc=example,dc=com'
> > 'cn=NOIP_KEY,ou=IP,ou=Keywords,dc=example,dc=com'
> > 'cn=FULLWORKER_KEY,ou=Timeofday,ou=Keywords,dc=example,dc=com'
> > 'cn=DAYWORKER_KEY,ou=Timeofday,ou=Keywords,dc=example,dc=com'
> > 'cn=NIGHTWORKER

[389-devel] Please review

[Anuj Borah]

Hi all,


Please review bellow PR:

https://pagure.io/389-ds-base/pull-request/50178

Its pending from long time .

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] Re: Filter does not work with Anonymous connection

[Anuj Borah]

@Matus Honek 

Yes, I agree.

Perhaps we should open one ticket in pagur to track this issue ?

Regards
Anuj Borah




On Tue, Feb 26, 2019 at 9:12 PM Matus Honek  wrote:

> This kinda leads me to thinking we should implement ACIs management
> within the DSLdapObjects like this (probably specific to a particular
> subclass, to a degree). One that would take care of this added
> requirement for objectclass ACIs because of hidden .filter's behavour.
> Because that is currently really hard to be understood at a first
> glance, or second.
> On Tue, Feb 26, 2019 at 4:02 AM William Brown  wrote:
> >
> >
> >
> > > On 26 Feb 2019, at 12:58, Anuj Borah  wrote:
> > >
> > > @William Brown
> > >
> > > ACI syntax in test is correct,  it meant to give access to (mail = * )
> only not any thing else . In the same case as mansion bellow:
> >
> > Ummm, that’s not what I’m saying? I’m saying that you may *only* be
> giving access to the mail attribute, so as a result when the .filter
> generates and expands to (&(objectClass=account)(mail=*)), the objectClass
> is denied on the searcch, causing the test to fail (to prevent disclosure).
> >
> > That’s why I suggest changing the aci to allowing mail AND objectClass,
> and testing again. I think this is atn aci issue not a python, and I’d like
> to rule out that first.
> >
> > >
> > > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci",
> '(target="ldap:///{};)(targetattr="mail")(version 3.0; acl "Test";allow
> (read,search,compare) (userdn = "ldap:///anyone;);
> )'.format(DEFAULT_SUFFIX))
> > >
> > > conn = Anonymous(topo.standalone).bind()
> > > # filter does not works with Anonymous
> > > assert 0 == Accounts(conn, DEFAULT_SUFFIX).filter('(mail=*)')
>  -  It does not work
> > > assert 3 == len(conn.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
> "mail=*")) - it works
> > >
> > >
> > > We can clearly see sarch_s works under conn while ACI access to
> (mail=*) , in the same condition filter does not work at all . It gives 0
> result , while search_s gives 3 .
> > >
> > >
> > >
> > > On Tue, Feb 26, 2019 at 5:06 AM William Brown  wrote:
> > >
> > >
> > > > On 26 Feb 2019, at 05:09, Anuj Borah  wrote:
> > > >
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > We have recently implemented Filter and Anonymous to lib389  . But
> it seems like Filter does not work with Anonymous connection .
> > > > It actually does not work with any kind of connection whether ACI
> allow or not  rather than root  .
> > > >
> > > > My suspense is it is related to this issue which is not yet fixed:
> https://pagure.io/389-ds-base/issue/50137
> > > >
> > > > Please check attached test case .
> > >
> > > I suspect they are not related, more likely the access control in your
> test doesn’t allow anonymous to search objectClass under DEFAULT_SUFFIX. If
> you change it to:
> > >
> > > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci",
> '(target="ldap:///{};)(targetattr=“mail || objectClass")(version 3.0; acl
> "Test";allow (read,search,compare) (userdn = "ldap:///anyone;);
> )'.format(DEFAULT_SUFFIX))
> > >
> > > (I hope I have the aci syntax correct)
> > >
> > >
> > > >
> > > > 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
> > >
> > > —
> > > Sincerely,
> > >
> > > William Brown
> > > 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
>

[389-devel] Re: Fwd: Filter does not work with Anonymous connection

[Anuj Borah]

@William Brown 

ACI syntax in test is correct,  it meant to give access to (mail = * ) only
not any thing else . In the same case as mansion bellow:

Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci",
'(target="ldap:///{};)(targetattr="mail")(version 3.0; acl "Test";allow
(read,search,compare) (userdn = "ldap:///anyone;);
)'.format(DEFAULT_SUFFIX))

conn = Anonymous(topo.standalone).bind()
# filter does not works with Anonymous
assert 0 == Accounts(conn, DEFAULT_SUFFIX).filter('(mail=*)')   -
It does not work
assert 3 == len(conn.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
"mail=*")) - it works


We can clearly see sarch_s works under conn while ACI access to (mail=*) ,
in the same condition filter does not work at all . It gives 0 result ,
while search_s gives 3 .



On Tue, Feb 26, 2019 at 5:06 AM William Brown  wrote:

>
>
> > On 26 Feb 2019, at 05:09, Anuj Borah  wrote:
> >
> >
> >
> > Hi all,
> >
> > We have recently implemented Filter and Anonymous to lib389  . But it
> seems like Filter does not work with Anonymous connection .
> > It actually does not work with any kind of connection whether ACI allow
> or not  rather than root  .
> >
> > My suspense is it is related to this issue which is not yet fixed:
> https://pagure.io/389-ds-base/issue/50137
> >
> > Please check attached test case .
>
> I suspect they are not related, more likely the access control in your
> test doesn’t allow anonymous to search objectClass under DEFAULT_SUFFIX. If
> you change it to:
>
> Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci",
> '(target="ldap:///{};)(targetattr=“mail || objectClass")(version 3.0; acl
> "Test";allow (read,search,compare) (userdn = "ldap:///anyone;);
> )'.format(DEFAULT_SUFFIX))
>
> (I hope I have the aci syntax correct)
>
>
> >
> > 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
>
> —
> Sincerely,
>
> William Brown
> 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] Pleas review

[Anuj Borah]

Hi all,

Please review bellow PRs:

https://pagure.io/389-ds-base/pull-request/50180
https://pagure.io/389-ds-base/pull-request/50168

Its pending from long time.

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] Re: creating a universal class to replace "Entry"

[Anuj Borah]

@William Brown   Thanks for the reply , please
look into the PR: https://pagure.io/389-ds-base/pull-request/50171

Its to create nsfilterrole .

On Mon, Feb 11, 2019 at 1:06 PM William Brown  wrote:

>
>
> > On 11 Feb 2019, at 17:01, Anuj Borah  wrote:
> >
> > Hi,
> >
> > As 'Entry' is not allowed to use now , In replace of Entry we are
> suggested to use UserAccounts and UserAccount which is very limited to some
> object classes .
> (['account','posixaccount','inetOrgPerson','organizationalPerson’]
>
> > )
> >
>
> There are many other types than this though?
>
> src/lib389/lib389/plugins.py:23:class Plugin(DSLdapObject):
> src/lib389/lib389/plugins.py:199:class MEPConfig(DSLdapObject):
> src/lib389/lib389/plugins.py:233:class MEPTemplate(DSLdapObject):
> src/lib389/lib389/plugins.py:444:class
> ReferentialIntegrityConfig(DSLdapObject):
> src/lib389/lib389/plugins.py:758:class MemberOfSharedConfig(DSLdapObject):
> src/lib389/lib389/plugins.py:887:class
> AutoMembershipRegexRule(DSLdapObject):
> src/lib389/lib389/plugins.py:905:class
> AutoMembershipDefinition(DSLdapObject):
> src/lib389/lib389/plugins.py:1015:class
> AutoMembershipRegexRule(DSLdapObject):
> src/lib389/lib389/plugins.py:1120:class
> LinkedAttributesConfig(DSLdapObject):
> src/lib389/lib389/plugins.py:1551:class AccountPolicyConfig(DSLdapObject):
> src/lib389/lib389/plugins.py:1598:class DNAPluginConfig(DSLdapObject):
> src/lib389/lib389/idm/organizationalrole.py:17:class
> OrganizationalRole(DSLdapObject):
> src/lib389/lib389/idm/nscontainer.py:11:class nsContainer(DSLdapObject):
> src/lib389/lib389/idm/nscontainer.py:49:class
> nsHiddenContainer(DSLdapObject):
> src/lib389/lib389/idm/domain.py:11:class Domain(DSLdapObject):
> src/lib389/lib389/idm/posixgroup.py:18:class PosixGroup(DSLdapObject):
> src/lib389/lib389/idm/organization.py:17:class Organization(DSLdapObject):
> src/lib389/lib389/idm/ipadomain.py:11:class IpaDomain(DSLdapObject):
> src/lib389/lib389/idm/group.py:17:class Group(DSLdapObject):
> src/lib389/lib389/idm/group.py:104:class UniqueGroup(DSLdapObject):
> src/lib389/lib389/idm/organizationalunit.py:16:class
> OrganizationalUnit(DSLdapObject):
> src/lib389/lib389/idm/account.py:15:class Account(DSLdapObject):
> src/lib389/lib389/tombstone.py:18:class Tombstone(DSLdapObject):
> src/lib389/lib389/backend.py:393:class Backend(DSLdapObject):
> src/lib389/lib389/backend.py:831:class DatabaseConfig(DSLdapObject):
> src/lib389/lib389/tasks.py:24:class Task(DSLdapObject):
> src/lib389/lib389/pwpolicy.py:287:class PwPolicyEntry(DSLdapObject):
> src/lib389/lib389/config.py:28:class Config(DSLdapObject):
> src/lib389/lib389/config.py:205:class Encryption(DSLdapObject):
> src/lib389/lib389/config.py:233:class RSA(DSLdapObject):
> src/lib389/lib389/config.py:358:class LDBMConfig(DSLdapObject):
> src/lib389/lib389/monitor.py:16:class Monitor(DSLdapObject):
> src/lib389/lib389/monitor.py:109:class MonitorLDBM(DSLdapObject):
> src/lib389/lib389/monitor.py:143:class MonitorBackend(DSLdapObject):
> src/lib389/lib389/monitor.py:190:class MonitorChaining(DSLdapObject):
> src/lib389/lib389/saslmap.py:12:class SaslMapping(DSLdapObject):
> src/lib389/lib389/index.py:27:class Index(DSLdapObject):
> src/lib389/lib389/index.py:64:class VLVSearch(DSLdapObject):
> src/lib389/lib389/index.py:147:class VLVIndex(DSLdapObject):
> src/lib389/lib389/encrypted_attributes.py:15:class
> EncryptedAttr(DSLdapObject):
> src/lib389/lib389/_mapped_object.py:84:class DSLdapObject(DSLogging):
> src/lib389/lib389/_mapped_object.py:441:if not
> issubclass(type(obj1), DSLdapObject) or not issubclass(type(obj2),
> DSLdapObject):
> src/lib389/lib389/_mapped_object.py:442:raise
> ValueError("Invalid arguments: Expecting object types that inherits
> 'DSLdapObject' class")
> src/lib389/lib389/agreement.py:23:class Agreement(DSLdapObject):
> src/lib389/lib389/cos.py:18:class CosTemplate(DSLdapObject):
> src/lib389/lib389/cos.py:65:class CosIndirectDefinition(DSLdapObject):
> src/lib389/lib389/cos.py:111:class CosPointerDefinition(DSLdapObject):
> src/lib389/lib389/replica.py:881:class Replica(DSLdapObject):
> src/lib389/lib389/replica.py:1288:class
> BootstrapReplicationManager(DSLdapObject):
> src/lib389/lib389/mappingTree.py:381:class MappingTree(DSLdapObject):
> src/lib389/lib389/chaining.py:18:class ChainingConfig(DSLdapObject):
> src/lib389/lib389/chaining.py:59:class ChainingDefault(DSLdapObject):
> src/lib389/lib389/chaining.py:81:class ChainingLink(DSLdapObject):
> src/lib389/lib389/changelog.py:20:class Changelog5(DSLdapObject):
> src/lib389/lib389/rootdse.py:15:class RootDSE(DSLdapObject):
> src/lib389/lib389/referral.py:14:class Referral(DSLdapObject):
>

[389-devel] Re: [discuss] composable object types in lib389

[Anuj Borah]

@Ludwig Krispenz   The script i have attached in my
previous mail was ported from the TET script .

Now i am attaching the main bash script , please check it out.




On Tue, Jan 22, 2019 at 1:48 PM Ludwig  wrote:

>
>
> On 01/22/2019 08:57 AM, Anuj Borah wrote:
>
> @Ludwig Krispenz   , exactly, Please check attached
> script , how it is implemented .
>
> Filter role and aci combination .
>
>
> But this is not testing role based acis,
>
> your bind rule always is userdn=, and you are using the roles attr in
> targeting entries. See the admin guide for acis:
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/defining_bind_rules#using_the_roledn_bind_type
>
> so what you need is an aci with
>
> allow (search, read) roledn="ldap:///cn= definition>,dc=example,dc=com"
>
>
> then you need an filterdrole entry :
>
> cn=,dc=example,dc=com
> nsrolefilter: 
>
> then you need users matching this filter and users not matching that
> filter, and check the results of an ldap operation.
>
> Please follow the request and do a writeup of what you want to achieve,
> before providing new code.
>
> Ludwig
>
>
>
>
>
>
>
> On Tue, Jan 22, 2019 at 1:13 PM Ludwig  wrote:
>
>>
>>
>> On 01/21/2019 11:01 PM, William Brown wrote:
>> >
>> >> On 21 Jan 2019, at 17:08, Anuj Borah  wrote:
>> >>
>> >> One small correction here :
>> >>
>> >> using newly created nsUserAccountRole and nsUserAccountRoles ( Will be
>> used only to create filter role ) , i am creating filter roles only . This
>> is the confusion here , we should remember filter roles are nothing but
>> entries with o='something'. I am not touching any user here , but i am
>> creating roles and these roles are covering the users automatically a
>> Ludwig Krispenzs  said earlier. example-
>> >>
>> >>
>> >>
>> >>
>> >>
>> role=nsUserAccountRole(topo.standalone,'cn=tuser1,ou=People,dc=example,dc=com')
>> >> user_props={'cn':'Anuj', 'nsRoleFilter':'cn=*'}
>> >> role.create(properties=user_props, basedn=SUFFIX)
>> >>
>> >>
>> >>
>> >> In above example just created one filer role which will cover all
>> users having 'cn=*' in 'ou=People'. Here
>> 'cn=tuser1,ou=People,dc=example,dc=com' is nothing but a filter role which
>> will cover all users having 'cn=*' in 'ou=People'.
>> >>
>> >> Another example as given bellow:
>> >>
>> >> dn: cn=FILTERROLEENGROLE,o=acivattr1,dc=example,dc=com
>> >> cn: FILTERROLEENGROLE
>> >> nsRoleFilter: cn=*
>> >> objectClass: top
>> >> objectClass: LDAPsubentry
>> >> objectClass: nsRoleDefinition
>> >> objectClass: nsComplexRoleDefinition
>> >> objectClass: nsFilteredRoleDefinition
>> >>
>> >> This above entry is nothing but filter role entry , which will cover
>> all users in 'o=acivattr1' which has sub entries that begins with 'cn'. And
>> this is the property of filter role .
>> >>
>> >> Yes , i must say that newly created nsUserAccountRole and
>> nsUserAccountRoles  which i renamed to  nsFilterAccountRole and
>> nsFilterAccountRoles will only cover filter role as you cant create Filter
>> role and other roles like Manage role all together . For my porting stuff
>> newly created nsFilterAccountRole and nsFilterAccountRoles is more than
>> enough because i need filter roles only .
>> >>
>> >> Hope it clears all of your doubts.
>> >>
>> > So I think the idea of composing this with nsUsers/nsAccount is so that
>> the nsRoleFilter becomes:
>> >
>> > &(objectClass=account)(cn=*)
>> but this filter would probably match all accounts, to properly test role
>> based acis you need to have a set of user matching the filter and get
>> access granted and a set of user not matching the filter and access
>> rejected.
>> >
>> > This way it’s limited to just those types. Else we would have just
>> “nsFilteredRole” lib389 type (which could be simpler, given that this idea
>> seems to have caused so much confusion already … :( )
>> >
>> > I still think it would be good to see a write of “how it works” by
>> hand, where you make the role, add the filter, show the roles on the users,
>> then how that translates to the lib389.
>> +1
>> >
>> > Thanks,
>> >
>> >
>> > —
>> > 

[389-devel] Re: [discuss] composable object types in lib389

[Anuj Borah]

@Ludwig Krispenz   , exactly, Please check attached
script , how it is implemented .

Filter role and aci combination .






On Tue, Jan 22, 2019 at 1:13 PM Ludwig  wrote:

>
>
> On 01/21/2019 11:01 PM, William Brown wrote:
> >
> >> On 21 Jan 2019, at 17:08, Anuj Borah  wrote:
> >>
> >> One small correction here :
> >>
> >> using newly created nsUserAccountRole and nsUserAccountRoles ( Will be
> used only to create filter role ) , i am creating filter roles only . This
> is the confusion here , we should remember filter roles are nothing but
> entries with o='something'. I am not touching any user here , but i am
> creating roles and these roles are covering the users automatically a
> Ludwig Krispenzs  said earlier. example-
> >>
> >>
> >>
> >>
> >>
> role=nsUserAccountRole(topo.standalone,'cn=tuser1,ou=People,dc=example,dc=com')
> >> user_props={'cn':'Anuj', 'nsRoleFilter':'cn=*'}
> >> role.create(properties=user_props, basedn=SUFFIX)
> >>
> >>
> >>
> >> In above example just created one filer role which will cover all users
> having 'cn=*' in 'ou=People'. Here 'cn=tuser1,ou=People,dc=example,dc=com'
> is nothing but a filter role which will cover all users having 'cn=*' in
> 'ou=People'.
> >>
> >> Another example as given bellow:
> >>
> >> dn: cn=FILTERROLEENGROLE,o=acivattr1,dc=example,dc=com
> >> cn: FILTERROLEENGROLE
> >> nsRoleFilter: cn=*
> >> objectClass: top
> >> objectClass: LDAPsubentry
> >> objectClass: nsRoleDefinition
> >> objectClass: nsComplexRoleDefinition
> >> objectClass: nsFilteredRoleDefinition
> >>
> >> This above entry is nothing but filter role entry , which will cover
> all users in 'o=acivattr1' which has sub entries that begins with 'cn'. And
> this is the property of filter role .
> >>
> >> Yes , i must say that newly created nsUserAccountRole and
> nsUserAccountRoles  which i renamed to  nsFilterAccountRole and
> nsFilterAccountRoles will only cover filter role as you cant create Filter
> role and other roles like Manage role all together . For my porting stuff
> newly created nsFilterAccountRole and nsFilterAccountRoles is more than
> enough because i need filter roles only .
> >>
> >> Hope it clears all of your doubts.
> >>
> > So I think the idea of composing this with nsUsers/nsAccount is so that
> the nsRoleFilter becomes:
> >
> > &(objectClass=account)(cn=*)
> but this filter would probably match all accounts, to properly test role
> based acis you need to have a set of user matching the filter and get
> access granted and a set of user not matching the filter and access
> rejected.
> >
> > This way it’s limited to just those types. Else we would have just
> “nsFilteredRole” lib389 type (which could be simpler, given that this idea
> seems to have caused so much confusion already … :( )
> >
> > I still think it would be good to see a write of “how it works” by hand,
> where you make the role, add the filter, show the roles on the users, then
> how that translates to the lib389.
> +1
> >
> > Thanks,
> >
> >
> > —
> > Sincerely,
> >
> > William Brown
> > 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
>
# --- BEGIN COPYRIGHT BLOCK ---
# Copyright (C) 2019 Red Hat, Inc.
# All rights reserved.
#
# License: GPL (version 3 or any later version).
# See LICENSE for details.
# --- END COPYRIGHT BLOCK ---

from working_contstants import *

DNBASE = "o=acivattr,{}".format(DEFAULT_SUFFIX)
ENG_USER = "cn=enguser1,ou=eng,{}".format(DNBASE)
SALES_UESER = "cn=salesuser1,ou=sales,{}".format(DNBASE)
ENG_MANAGER = "cn=engmanager1,ou=eng,

[389-devel] Re: [discuss] composable object types in lib389

[Anuj Borah]

One small correction here :

using newly created nsUserAccountRole and nsUserAccountRoles ( Will be used
only to create filter role ) , i am creating filter roles only . This is
the confusion here , we should remember filter roles are nothing but
entries with o='something'. I am not touching any user here , but i am
creating roles and these roles are covering the users automatically a
Ludwig Krispenzs  said earlier. example-


role=nsUserAccountRole(topo.standalone,'cn=tuser1,ou=People,dc=example,dc=com')
user_props={'cn':'Anuj', 'nsRoleFilter':'cn=*'}
role.create(properties=user_props, basedn=SUFFIX)


In above example just created one filer role which will cover all users
having 'cn=*' in 'ou=People'. Here 'cn=tuser1,ou=People,dc=example,dc=com'
is nothing but a filter role which will cover all users having 'cn=*' in
'ou=People'.

Another example as given bellow:

dn: cn=FILTERROLEENGROLE,o=acivattr1,dc=example,dc=com
cn: FILTERROLEENGROLE
nsRoleFilter: cn=*
objectClass: top
objectClass: LDAPsubentry
objectClass: nsRoleDefinition
objectClass: nsComplexRoleDefinition
objectClass: nsFilteredRoleDefinition

This above entry is nothing but filter role entry , which will cover all
users in 'o=acivattr1' which has sub entries that begins with 'cn'. And
this is the property of filter role .

Yes , i must say that newly created nsUserAccountRole and
nsUserAccountRoles  which i renamed to  nsFilterAccountRole and
nsFilterAccountRoles will only cover filter role as you cant create Filter
role and other roles like Manage role all together . For my porting stuff
newly created nsFilterAccountRole and nsFilterAccountRoles is more than
enough because i need filter roles only .

Hope it clears all of your doubts.

Regards

Anuj Borah



On Fri, Jan 18, 2019 at 4:24 AM William Brown  wrote:

>
>
> > On 17 Jan 2019, at 19:40, Ludwig Krispenz  wrote:
> >
> >
> > Maybe I do not understand how it works because of some lib389 magic, but
> I think this is not how roles work.
> >
> > You are  creating cn=tuser1 and cn=Anju and they will have the role
> objectclasses, but the benefit of roles is that you do NOT have to touch
> the useres to assign roles to them. There is a class of users and a class
> of role definitions and ONLY the change in the role definition will
> determine if a user has a role or not.
>
> I think lib389 probably isn’t helping, but Ludwig’s description here is
> correct.
>
> Maybe a good approach is to “setup” roles by hand, then once you have a
> process in mind, then you can make the lib389 parts? I generally approach
> things this way to understand them well.
>
> Would that help?
>
>
> —
> Sincerely,
>
> William Brown
> 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: [discuss] composable object types in lib389

[Anuj Borah]

Hay William.

RDN = 'cn'

class nsUserAccountRole(Account):
def __init__(self, instance, dn=None):
super(nsUserAccountRole, self).__init__(instance, dn)
self._rdn_attribute = RDN
self._create_objectclasses = [
'top',
'LDAPsubentry',
'nsRoleDefinition',
'nsComplexRoleDefinition',
'nsFilteredRoleDefinition'
]
self._childobject = Account
user_compare_exclude = [
'nsUniqueId',
'modifyTimestamp',
'createTimestamp',
'entrydn'
]
self._compare_exclude = self._compare_exclude + user_compare_exclude
self._protected = False


class nsUserAccountRoles(DSLdapObjects):
def __init__(self, instance, basedn, rdn='ou=People'):
super(nsUserAccountRoles, self).__init__(instance)
self._objectclasses = [
'top',
'LDAPsubentry',
'nsRoleDefinition',
'nsComplexRoleDefinition',
'nsFilteredRoleDefinition'
]
self._filterattrs = [RDN, 'cn']
self._childobject = nsUserAccountRole
if rdn is None:
self._basedn = basedn
else:
self._basedn = '{},{}'.format(rdn, basedn)


Here  i am not using nsUserAccount  in nsUserAccountRole as it requires
'uid' which is not allowed in  nsFilteredRoleDefinition and
nsRoleDefinition . Below are usages:

user=nsUserAccountRole(topo.standalone,'cn=tuser1,ou=People,dc=example,dc=com')
user_props={'cn':'Anuj', 'nsRoleFilter':'cn=*'}
user.create(properties=user_props, basedn=SUFFIX)


nsUserAccountRoles(topo.standalone, DEFAULT_SUFFIX).list()[0].dn
>> 'cn=tuser1,ou=People,dc=example,dc=com'

nsUserAccountRoles(topo.standalone,
DEFAULT_SUFFIX).create(properties=user_props)
>>> 
nsUserAccountRoles(topo.standalone, DEFAULT_SUFFIX).list()[1].dn
>>> 'cn=Anuj,ou=People,dc=example,dc=com'


Let me know , what you think .


Regards
Anuj Borah





On Tue, Jan 15, 2019 at 6:30 AM William Brown  wrote:

>
> > On 14 Jan 2019, at 19:28, Anuj Borah  wrote:
> >
> > Hi William ,
> >
> > Just find out a way to do it .
>
>
> This isn’t quite what I had in mind.
>
> Remember, we should be able to compose nsRole types to various other
> objects if required (despite my dislike of nsRoles …).
>
> We have "nsUserAccount(Account)”, and we need to be able to extend it with
> nsRole types.
>
> One way to achieve this is:
>
> class nsRoleDefinition(object):
> def __init__(self, instance, dn=None):
> if ‘_create_objectclasses’ not in self:
> raise Exception ….
> # So we must have been combined with a type to add roles
> self._create_objectclasses.append(’nsFilteredRoleDefinition’)
>
>
> class nsUserAccountRole(nsUserAccount, nsRoleDefinition):
> def __init__(self, instance, dn=None):
> super(nsUserAccount, self).__init__(instance, dn)
> super(nsRoleDefinition, self).__init__(instance, dn)
>
>
>
> Then you would use the nsUserAccountRole like normal. (I think we may need
> a similar “nsUserAccountRoles" for the muliple search parts)
>
> A benefit to this, is you could have role-specific functions like
> setting/changing the filter, but you never loose the “account” features
> like bind. Provided a method is uniquely sourced, I think python takes the
> implementation that is unique, or it takes the “first”. So this should all
> just work.
>
> The main benefit here is it’s really clean, we can compose this to other
> types. It also avoids any duplication of class definitions and logic etc.
>
> I think this is how I would like to see it created. It may be worth making
> a “ticket” just for the nsRole parts and splitting your test for nsRoles
> out of the mega-patch you have.
>
> >
> > class UserAccountnsRole(Account):
> >
> > def __init__(self, instance, dn=None):
> > super(UserAccountnsRole, self).__init__(instance, dn)
> > self._rdn_attribute = RDN
> > self._create_objectclasses = [
> > 'top',
> > 'LDAPsubentry',
> > 'nsRoleDefinition',
> > 'nsComplexRoleDefinition',
> > 'nsFilteredRoleDefinition'
> > ]
> > user_compare_exclude = [
> > 'nsUniqueId',
> > 'modifyTimestamp',
> > 'createTimestamp',
> > 'entrydn'
> > ]
> > self._compare_exclude = self._compare_exclude +
> user_compare_exclude
> > self._protected = False
> >
> > def _validate(self, rdn, properties, basedn):
> > if 'ntUserDomainId' in properties and 'ntUser' not in
> self._cr

[389-devel] Re: [discuss] composable object types in lib389

[Anuj Borah]

Hi William ,

Just find out a way to do it .

class UserAccountnsRole(Account):

def __init__(self, instance, dn=None):
super(UserAccountnsRole, self).__init__(instance, dn)
self._rdn_attribute = RDN
self._create_objectclasses = [
'top',
'LDAPsubentry',
'nsRoleDefinition',
'nsComplexRoleDefinition',
'nsFilteredRoleDefinition'
]
user_compare_exclude = [
'nsUniqueId',
'modifyTimestamp',
'createTimestamp',
'entrydn'
]
self._compare_exclude = self._compare_exclude + user_compare_exclude
self._protected = False

def _validate(self, rdn, properties, basedn):
if 'ntUserDomainId' in properties and 'ntUser' not in
self._create_objectclasses:
self._create_objectclasses.append('ntUser')

return super(UserAccountnsRole, self)._validate(rdn, properties, basedn)


def create_test_user_nsrole(instance, cn, nsRoleFilter, description,
suffix=None):
global test_user_id
if cn is None:
cn = "testuser_" + str(test_user_id)
test_user_id += 1
if suffix is None:
suffix =  DEFAULT_SUFFIX
dn = "cn=" + cn + "," + suffix
properties = {
'cn': cn,
"nsRoleFilter": nsRoleFilter,
"description": description,
}
user = UserAccountnsRole(instance, dn)
user.create(properties=properties)
return user

Now just using create_test_user_nsrole we will be able to create entries
with nsRoles.


Regards
Anuj Borah






On Mon, Jan 7, 2019 at 2:30 PM William Brown 
wrote:

> Hi,
>
> I’ve been speaking to Anuj Borah about a PR they made, and how we can
> properly represent nsRole.
>
> because nsRoles are an extra objectClass, rather than a standalone one, we
> need a way to represent this properly.
>
> It’s probably a good idea to use some of pythons composability here, where
> we could do something like:
>
> class nsFilteredRole(DSLdapObject):
>
>
> class User(DSldapObject):
>
> class User_nsFilteredRole(User, nsFilteredRole):
>
> Then to have a way to define and have each subclass called, and asserted
> for correctness. A question is how we would handle:
>
> user = User.create(…)
> # How to convert user to User_nsFilteredRole
>
> We could do something like:
>
> User_nsFilteredRole.from(user)
>
> And have a from that does a valid conversion based on types and adds in
> the required role parts?
>
> This isn’t a common scenario, so I think having a limited set of well
> understood types that require this type of conversion would be okay.
>
> Thought? *looking at you Simon* :)
>
> PS: It’s good to be back
>
> --
> Sincerely,
>
> William
> ___
> 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