UserAccounts creates users with junk sign

[Anuj Borah]

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)



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_KEY,ou=Timeofday,ou=Keywords,dc=example,dc=com'
'cn=NOWORKER_KEY,ou=Timeofday,ou=Keywords,dc=example,dc=com'

Here users are in good shape .


Any suggestion. Should it be fixed .


Regards
Anuj Borah

[William Brown]

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 <aborah(a)redhat.com&gt;
> 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_KEY,ou=Timeofday,ou=Keywords,dc=example,dc=com'
>  'cn=NOWORKER_KEY,ou=Timeofday,ou=Keywords,dc=example,dc=com'
>  
>  Here users are in good shape .  
Here, because you do cn as i.split(,), now the cn becomes “EVERYDAY_KEY” and the provided
basedn you have in the UserAccount initialise is now set to the full DN, so the create
works.

Basically, the mistake here is that you are iterating over a list of partial-dn’s and you
expect lib389 to magically fix this all for you, and it’s behaviour is now surprising you
because it’s “making safe” from your mistake. 


There are two main pieces of advice I would give here.

First is to *stop* thinking about everything in terms of DN’s and start thinking about
things in terms of “containers and what they hold”. When you do:

uas = UserAccounts(basedn=DEFAULT_SUFFIX, rdn=ou=People)

You are describing “Here is the set of all possible users, and where they exist in the
servers tree”. So now that UserAccounts is setup like this you can do:

uas.create(properties={
    uid: ’test'
})

this will be combined to make uid=test + ou=People + DEFAULT_SUFFIX ->
uid=test,ou=people,DEFAULT_SUFFIX.

Now, when we look at your example, because you are trying to take shortcuts, you are
including the location of the object into the cn parameter with things like: ‘ips,ou=ips’
…. 


There are three possible ways to handle this.

1: (okay, but not the best)

Create each item bypassing UserAccounts, by loading the full dn into the UserAccount
setup. This is done with:

u = UserAccount(topo.standalone, dn=“uid=test,ou=People,dc=example,dc=com”)
u.create(properties={
    ….
})

Remember, UserAccount (singular) being an absolute object, can have a full path into the
DN like this. Once you have added all these, even if you do say:

u = UserAccount(topo.standalone, dn=“uid=test,ou=Container,ou=People,dc=example,dc=com”)
…
uas = UserAccounts(topo.standalone, DEFAULT_SUFFIX, rdn=ou=People)
uas.list()

uas.list/get will find the userAccount becaus it’s a subtree seacch, regardless of how
many containers exist in the path.


2. (“good enough")

Keep updating and changing your UserAccounts to account for the relative location change
during your create:

authmethod_users = UserAccounts(topo.standalone, DEFAULT_SUFFIX,
rdn=ou=Authmethod,ou=Keywords)
uas.create( …)

ip_users = UserAccounts(topo.standalone, DEFAULT_SUFFIX, rdn=ou=IP,ou=Keywords)
ip_users.create(…)

So this at the very least means you keep things work in the best way possible, even though
you need to do lots of changes to get all the weird rdns. You can probably solve this with
some lists of tuples like:

my users = [ (’name’, ‘ou=ip,ou=keywords’),
                     ….]

for (uid, rdn) in my_users:
    us = UserAccounts(topo.standalone, DEFAULT_SUFFIX, rdn)
    us.create(properties={ ‘uid’: uid })



3. (best)

Unless the test requires you to have all these crazy ou’s (and even if it does … fixtures
per test, rather than one giant fixture per module …), then your users should all be in a
SINGLE OU anyway. LDAP supports filtering and querying, which is a much more effective way
of expressing constraints and what users you want etc.

So just do:

users = UserAccounts(topo.standalone, DEFAULT_SUFFIX)


test_fixture_1
    users.create(…)
    fin:
        for u in users.get():
            u.delete()

test_fixture_2
    users.create(…)
    …


my_test(test_fixture_1)
    # Now do the test thing. Apply my ACI to ou=People instead, and do the test, then
reset in the fixture. 

I think you often are trying to copy-paste ACI’s as they are from past tests, you are
trying to duplicate bad test structure from TET, and you are then hitting up against
lib389 and wondering why it won’t work. Of course it won’t! Lib389 *can* allow you to do
everything you want with LDAP, but for the common cases, lib389 is trying to guide you to
do things in a certain, correct, and simple way. Sprawling deep tree directories are awful
to administer and understand, where flatter structures defined by group memberships and
filtering are far nicer. 

Remember: if you find you are struggling to do something, is it the API that’s at fault?
Or the way you are approaching the problem? 


Hope that helps,


—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Anuj Borah]

@William Brown <wbrown(a)suse.de&gt;

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 <wbrown(a)suse.de&gt; 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 <aborah(a)redhat.com&gt; 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_KEY,ou=Timeofday,ou=Keywords,dc=example,dc=com'
>  > 'cn=NOWORKER_KEY,ou=Timeofday,ou=Keywords,dc=example,dc=com'
>  >
>  > Here users are in good shape .
>
>  Here, because you do cn as i.split(,), now the cn becomes “EVERYDAY_KEY”
>  and the provided basedn you have in the UserAccount initialise is now set
>  to the full DN, so the create works.
>
>  Basically, the mistake here is that you are iterating over a list of
>  partial-dn’s and you expect lib389 to magically fix this all for you, and
>  it’s behaviour is now surprising you because it’s “making safe” from your
>  mistake.
>
>
>  There are two main pieces of advice I would give here.
>
>  First is to *stop* thinking about everything in terms of DN’s and start
>  thinking about things in terms of “containers and what they hold”. When you
>  do:
>
>  uas = UserAccounts(basedn=DEFAULT_SUFFIX, rdn=ou=People)
>
>  You are describing “Here is the set of all possible users, and where they
>  exist in the servers tree”. So now that UserAccounts is setup like this you
>  can do:
>
>  uas.create(properties={
>      uid: ’test'
>  })
>
>  this will be combined to make uid=test + ou=People + DEFAULT_SUFFIX ->
>  uid=test,ou=people,DEFAULT_SUFFIX.
>
>  Now, when we look at your example, because you are trying to take
>  shortcuts, you are including the location of the object into the cn
>  parameter with things like: ‘ips,ou=ips’ ….
>
>
>  There are three possible ways to handle this.
>
>  1: (okay, but not the best)
>
>  Create each item bypassing UserAccounts, by loading the full dn into the
>  UserAccount setup. This is done with:
>
>  u = UserAccount(topo.standalone, dn=“uid=test,ou=People,dc=example,dc=com”)
>  u.create(properties={
>      ….
>  })
>
>  Remember, UserAccount (singular) being an absolute object, can have a full
>  path into the DN like this. Once you have added all these, even if you do
>  say:
>
>  u = UserAccount(topo.standalone,
>  dn=“uid=test,ou=Container,ou=People,dc=example,dc=com”)
>  …
>  uas = UserAccounts(topo.standalone, DEFAULT_SUFFIX, rdn=ou=People)
>  uas.list()
>
>  uas.list/get will find the userAccount becaus it’s a subtree seacch,
>  regardless of how many containers exist in the path.
>
>
>  2. (“good enough")
>
>  Keep updating and changing your UserAccounts to account for the relative
>  location change during your create:
>
>  authmethod_users = UserAccounts(topo.standalone, DEFAULT_SUFFIX,
>  rdn=ou=Authmethod,ou=Keywords)
>  uas.create( …)
>
>  ip_users = UserAccounts(topo.standalone, DEFAULT_SUFFIX,
>  rdn=ou=IP,ou=Keywords)
>  ip_users.create(…)
>
>  So this at the very least means you keep things work in the best way
>  possible, even though you need to do lots of changes to get all the weird
>  rdns. You can probably solve this with some lists of tuples like:
>
>  my users = [ (’name’, ‘ou=ip,ou=keywords’),
>                       ….]
>
>  for (uid, rdn) in my_users:
>      us = UserAccounts(topo.standalone, DEFAULT_SUFFIX, rdn)
>      us.create(properties={ ‘uid’: uid })
>
>
>
>  3. (best)
>
>  Unless the test requires you to have all these crazy ou’s (and even if it
>  does … fixtures per test, rather than one giant fixture per module …), then
>  your users should all be in a SINGLE OU anyway. LDAP supports filtering and
>  querying, which is a much more effective way of expressing constraints and
>  what users you want etc.
>
>  So just do:
>
>  users = UserAccounts(topo.standalone, DEFAULT_SUFFIX)
>
>
>  test_fixture_1
>      users.create(…)
>      fin:
>          for u in users.get():
>              u.delete()
>
>  test_fixture_2
>      users.create(…)
>      …
>
>
>  my_test(test_fixture_1)
>      # Now do the test thing. Apply my ACI to ou=People instead, and do the
>  test, then reset in the fixture.
>
>  I think you often are trying to copy-paste ACI’s as they are from past
>  tests, you are trying to duplicate bad test structure from TET, and you are
>  then hitting up against lib389 and wondering why it won’t work. Of course
>  it won’t! Lib389 *can* allow you to do everything you want with LDAP, but
>  for the common cases, lib389 is trying to guide you to do things in a
>  certain, correct, and simple way. Sprawling deep tree directories are awful
>  to administer and understand, where flatter structures defined by group
>  memberships and filtering are far nicer.
>
>  Remember: if you find you are struggling to do something, is it the API
>  that’s at fault? Or the way you are approaching the problem?
>
>
>  Hope that helps,
>
>
>  —
>  Sincerely,
>
>  William Brown
>
>  Senior Software Engineer, 389 Directory Server
>  SUSE Labs
>  _______________________________________________
>  389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-devel-leave(a)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/[e-mail]...
>

[William Brown]

>  On 27 Mar 2019, at 12:13, Anuj Borah <aborah(a)redhat.com&gt;
> wrote:
>  
>  I was wondering if UserAccount can do it , why UserAccounts cant . 
>   
UserAccounts is saying “here is all possible accounts in a subtree, but we only make new
ones at the root of the tree”. UserAccount is “this is a concrete, absolute account with
exactly this dn and properties”. 




—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs