Clean up and improve demo objects for 1.4.0 during installation

[389-ds-bot]

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

• Created at 2017-10-25 02:12:02 by firstyear (@Firstyear)
• Closed at 2018-01-18 05:03:01 as fixed
• Assigned to firstyear (@Firstyear)

---

Issue Description

Our current demo /example data in userRoot is quite outdated, and we can offer a better more modern base setup. This ticket is to track that effort,

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-10-25 02:12:08

Metadata Update from @Firstyear:

• Issue assigned to Firstyear

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2017-10-26 17:58:49

Metadata Update from @mreynolds389:

• Custom field component adjusted to None
• Custom field origin adjusted to None
• Custom field reviewstatus adjusted to None
• Custom field type adjusted to None
• Custom field version adjusted to None
• Issue set to the milestone: 1.4 backlog

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2018-01-12 05:36:00

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2018-01-12 05:36:44

This comes with a unit test that asserts the correct behaviour and presence of the default objects, and additonally some checks to assert we only push the new data on a 1.4.0 install (IE prevent breaking older tests or unsupported schema issues).

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2018-01-12 05:36:50

Metadata Update from @Firstyear:

• Custom field reviewstatus adjusted to review (was: None)

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2018-01-12 09:03:40

The patch looks good. A question regarding the 'nsSshPublicKey' attribute, I am surprised it is a directoryString shouldn't it be octetString or something like that ?

[389-ds-bot]

Comment from lkrispen (@elkris) at 2018-01-12 09:31:45

I have a few questions about the new schema.

do we still use ns as a prefix nsXXX in new schema additions, the netscape reference is no longer needed, why not dsPerson or extPerson as we extend an objectclass.
The new oc, do they really need to be structural ?
why is displayname a MUST?

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-01-13 12:17:11

The code looks good to me, thanks! You have my ack.

Though I think it is important to mention in the docstrings that we should choose the new nsUserAccount and nsUserAccounts only on 1.4.0 and above. It will help to avoid a confusion in the documentation.

376 +    This is the modern and correct userAccount type to choose.
410 +    This is the modern and correct userAccount type to choose.
441 +    This is the classic "user account" style of cn + sn. You should consider
442 +    nsUserAccount instead.
443 +
487 +    This is the classic "user account" style of cn + sn. You should consider
488 +    nsUserAccounts instead.
489 +

Also, I think we can transform these lines into docstring (simple ones, without dirsrvtests/suites format)

561 +def test_install_sample_entries(topology_st):
562 +    # Assert that our entries match.
562 +    """"Assert that our entries match."""

570 +def test_install_aci(topology_st):
571 +    # Assert our default aci's work as expected.
571 +    """Assert our default aci's work as expected."""

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-01-13 12:17:21

Metadata Update from @droideck:

• Custom field reviewstatus adjusted to ack (was: review)

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2018-01-13 15:19:37

I also agree with Ludwig on the naming. We should start dropping "ns" prefix where we can since it really refers to "netscape". I think "ds" is a good prefix, but I'm concerned that its such a obvious choice that customers might already being using these names for their custom schema. For example, if I was a customer and I added a new person objectclass I would probably call it "dsPerson". These conflicts are probably rare, but I wanted to mention it anyway.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2018-01-15 02:46:07

I have a few questions about the new schema.
do we still use ns as a prefix nsXXX in new schema additions, the netscape reference is no longer needed, why not dsPerson or extPerson as we extend an objectclass.
The new oc, do they really need to be structural ?
why is displayname a MUST?

To answer both points from @mreynolds389 and @elkris. I have thought about this as well, because I don't like the ns prefix either. The issue is it's so prevalent in the code. So I think we either

• Accept it and just keep consistent (even if not perfect)
• Try to change new names to ds prefix, but then have inconsistent split of ns/ds

I think there really is not right answer here, but I opted to go with consistency over vanity. As much as I would love to make everything "ds" prefix, I think practically as a project we have to wear the NS prefix from now on, we can't avoid it. While not perfect, I think the consistency matters more, and most people don't even think about the origin of it anyway :)

As for "structural". I chose this to parallel the "person" objectClass, which is also structural. I did consider this a lot, thinking about if it should just be aux with top as structural component, but I don't know if that actually works TBH (it probably does, but I have not tested). I considered if this could conflict with other classes that subclass on person, but investigating popular types like radius info and eduPerson, these are all auxtypes. So this won't conflict. I think in a way it shows how aux and structural classes of ldap objects are kinda silly in a way, but it DOES prevent a single aci attack vector related to adding group objectClasses to a person object.

Finally, displayName is a must due to the reasons I put in the mailing list. People should be able to choose how they are viewed and identified as a person that is seperate from the UID or legalName that they have. It's the "identity" part of identity management :). As far as the ldap object goes I can see that from a technical view, having "may displayname, legalname" seems like a technically attractive option due to choice of which field to use, but the issue is that some implementors may choose to use legalName only (think fb real name policy). This goes against what we want! What we want is people to be identified the way they choose, and to do this requires enforcing that a displayName property is ALWAYS present, and that optionally the system may collect a legalName for reasons. It means that there is one correct way to render a person on a login screen, a website or others (displayName), because we guarantee it's there.

I think the final point to remember is that while this is saying "your users should look like this" the current Person schema still remains so we will not affect existing installs that wish to retain their current naming policies. Only that we are demonstrating "here is a modern way to achieve this that is inclusive and respectful to individuals".

I hope that helps!

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2018-01-15 03:45:00

The patch looks good. A question regarding the 'nsSshPublicKey' attribute, I am surprised it is a directoryString shouldn't it be octetString or something like that ?

Nope, it's a string like:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfDs2+iClMFiirY87dTy4/URWQP8wGLGs5uwsNhLzwPYfaQQNjvH7WvFzaO ...

Exactly as it would be in a .pub file in .ssh :)