RFE - add dsrc options for default user and group subtrees

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/51240

• Created at 2020-08-13 11:02:37 by mmuehlfeldrh
• Assigned to nobody

---

Issue Description

On RHEL 8.2 (with 389-ds-base-1.4.2.12-2) creating a user works, but the same command fails on RHEL 8.3 nightly (with 389-ds-base-libs-1.4.3.11-1).

Package Version and Platform

389-ds-base-libs-1.4.3.11-1.module+el8dsrv+7557+bc264682.x86_64 (RHEL 8.3 nightly)

Steps to reproduce

dsidm instance_name -b "dc=example,dc=com" user create
Enter value for uid : example
Enter value for cn : example
Enter value for displayName : example
Enter value for uidNumber : 1234
Enter value for gidNumber : 1234
Enter value for homeDirectory : /home/example

Actual results

Error: No such object

Expected results

Successfully created example

Additional information

https://directory.fedoraproject.org/docs/389ds/howto/quickstart.html#add-users-and-groups
is outdated. It misses that -b Base_DN is required.

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-08-13 17:41:55

Metadata Update from @mreynolds389:

• Custom field origin adjusted to None
• Custom field reviewstatus adjusted to None
• Issue priority set to: major
• Issue set to the milestone: 1.4.3

[walshg3]

is there any update on this? Currently using 389 for my employer and running into the same Error: No such object on RHEL 8 389-ds-base-stable:default version 1.4.3.22

[mreynolds389]

"dsidm" still needs some work. It's very opinionated and it only adds users to "ou=people" + suffix. So it's not very flexible. We will up the priority of this issue...

[Firstyear]

@mreynolds389 Yeah - the challenge with "flexible" is that it makes the creation of a user interface much much harder for a cli. It's kind of a difference between "a generic ldap object editor that happens to be able to make accounts" and "something that makes accounts in a really clear and straightforward manner".

Especially once you throw in different ou's and such, it becomes pretty hard to say even a simple query like "list all my accounts" because then we have to consider "where are they? Which ou's are clients searching?". Then considering stuff like "given two accounts with the same uid how can we act on these on the cli" because then we change from say .... "dsidm inst account reset_password william" to "dsidm inst account reset_password uid=william,ou=custom,dc=...".

So it was a trade off - a simpler ux/cli interface, by defining a set of constraints that we knew we would be working within. Where as allowing more customisation increases the ux/ui scope, changes the communication to the user and more.

Another aspect in the thinking was also that there are plenty of other "generic" object entry editors. 389-ds is a box of parts, and you are free to choose to ignore the dsidm 'part' in favour of your own part that understands the customisations you need.

[mreynolds389]

@Firstyear Perhaps an expansion to .dsrc where user and group containers could be defined? Default would be to ou=people,SUFFIX of course.

[Firstyear]

@mreynolds389 Yeah that could work, but the question is what is @walshg3's intent here? What's the layout they want to create with the tool?

For a "simple" solution that's still opionated but path of least resistance I think your idea for the dsrc changes are good :)

[walshg3]

I am nowhere near qualified to be able to give a productive answer in this conversation but for my use case what @mreynolds389 was mentioning about a default ou=people,SUFFIX would work perfectly and then the user could specify any additional configurations / options if needed. Even the ability to use the INF style similar to using dscreate would be great too. The main issue I found myself running into with 389 is that i'm very new to LDAP and 389 looked the most user friendly because of the scripts that are built in. I have since learned some of the scripts are not complete due to very understandable design opinions. My own opinion comes from being a beginner in LDAP and how quick i was able to get the ball rolling with 389 so I am for the path of least resistance. As a final note thank you both for your hard work in this awesome product as I learn more about LDAP I am truly appreciating how much hard work went into 389ds.

[mreynolds389]

@walshg3 In your database tree structure, where do you want you users to be created? It is common to use "ou=People,SUFFIX" --> "ou=people,dc=example,dc=com".

If dsidm is failing for you it means you do not have this branch created (which is fine). If using this container "ou=people,dc=example,dc=com" for your user entries is okay, then you can just create it:

# dsidm slapd-localhost -b SUFFIX organizationalunit create  (name it "people")

Then the dsidm command will start working seamlessly. Does this work for you? Or do you need to store the users under a different branch?

[walshg3]

@mreynolds389 followed your instructions and that worked perfectly. Yeah I think the issue originated from me making an ldap server with a suffix of c=us as the root so the typical ou=people was not created. Once i added the people ou the dsidm user create worked. Thank you. For me this functionality worked. I think maybe adding an error check for the people ou would be beneficial maybe make it say "error no object it might be possible you did not create a people ou is this intentional?" I can also see how this leads into what you were talking about earlier with only being able to add to the people ou. Thank you so much for your time!

[Firstyear]

@walshg3 You may find that the use of the sample-entries or the "initialise" command could help as it sets up a base ou tree and acis :)

[tbordaz]

RHDS epic 12

[mreynolds389]

Clone to bugzilla to add options to .dsrc to specify the people/groups DN's that dsidm should use.

[mreynolds389]

f79182f..7b86528 389-ds-base-2.2 -> 389-ds-base-2.2
3feb1a3..d4fcfa8 389-ds-base-2.1 -> 389-ds-base-2.1
4e256db..ad8ab41 389-ds-base-2.0 -> 389-ds-base-2.0
1afd3ee..ee284d4 389-ds-base-1.4.3 -> 389-ds-base-1.4.3