Re: Improve the demo objects from install

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Hi all,
> 
> It's time that I'm looking at:
> https://pagure.io/389-ds-base/issue/49425
> 
> There are some great reasons to freshen up the default objects we
> install. The current design isn't really reflective of modern directory
> usage, the aci's are not "great" examples, and it's not a super-useful
> foundation out of the box.
> 
> As a result, I have some improvements I want to make here. Let's start
> with the simple ones:
> 
> Tree layout:
> 
> dc=example,dc=com
> cn=389_ds_system,dc=example,dc=com
> ou=people,dc=example,dc=com
> ou=groups,dc=example,dc=com
> ou=services,dc=example,dc=com
> ou=permissions,dc=example,dc=com
> 
> This is the structure I want us to ship with: groups, people, service
> accounts, and permission groups. I additionally add an
> nscontainer|ldapsubentry 389_ds_system, which is the "hidden" config
> area that we could start to use for things like pwpolicy, keepalive
> entries, replication service accounts and more. I don't think anything
> here is too controversial :)
> 
> Next, demo objects!
> 
> uid=demo_user,ou=people,dc=example,dc=com
> cn=demo_group,ou=groups,dc=example,dc=com
> 
> These can show a user and group, and lets the cli tools have something
> to show, and how they can be integrated with *acis*.
> 
> Again, nothing complex :) 
> 
> Permissions! This is where we start to add aci's and get's a bit fun.
> 
> I want to ship with a few useful permisisons and acis. The thinking is:
> 
> * anonymous read to public ou=People and user attributes (ie Sssd
> should work oob)
> * anonymous read to groups attributes (ie Sssd should work oob)
> * a permission group where members can alter group members
> * a permission group where members can alter users
> * a permission group where members can reset user passwords
> * a permission group where members can create/delete users
> * a permission group where members can create/delete groups
> 
> This is a pretty simple set of acis, but I want them to show how
> delegation of permissions can be done safely, and act as examples and
> templates for admins - as well as just being simple and useful for
> small deployments out of the box!
> 
> 
> Now, this is the final suggestion: I'd like to add some extra schema
> and change user objects by default that we create. 
> 
> I would like to add:
> 
> nsPerson
> 
> I would like them to contain the following:
> 
> nsPerson:
> MAY: userPassword, telephoneNumber, seeAlso, description, legalName
> MUST: cn, displayName

I am also very in favor of this change.  I'd love to see this highly advertised once it merges as I think it speaks very highly of how to both be inclusive and move great software forward while continuing to be extremely useful to users.

regards,

bex

> 
> 
> This is a shift from the traditional person object and there is a
> really good reason - 
> internationalisation. (we replace sn with legalName and make it may,
> and add
> displayName).
> 
> 
> The current person account *requires* the sn field. However surname
> *does not*
> translate across many cultural boundaries. Some people have multiple
> surnames, some
> have no concept of a surname.
> 
> What people do have is a *legal name* which is their full name - for me
> that would be
> givennames + surname. For others just their single name. having a
> single legalName
> field correctly represents this case. And additionally many
> applications don't
> even need a legal name, *only* a displayName of the users choice.
> 
> The second reason is identity related. There are many people whos
> chosen name
> for the world (displayName) differs from their actual legal name. As a
> result
> having a displayname field where the user can *choose* how they are
> represented
> is highly important. Consider divorced people (who haven't yet changed
> legal names)
> victims of crime (who need to hide their identity) and more.
> 
> I think our current schema doesn't current reflect the "best" in
> identity management
> and by adding nsPerson like this, we can really do the right thing
> here, by
> default.
> 
> *obivously* this is a new schema, not changing existing items, so
> existing deployments
> will keep using whatever they want (person etc) - more that new
> deployments will
> see a modern, best practice that they can follow,
> 
> 
> I'd like to get feedback on this soon, as I'd like to have this in the
> cli
> tool demo I want to release soon.
> 
> Thanks everyone,
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Directory Announce]     [Fedora Users]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Review]     [Fedora Art]     [Fedora Music]     [Fedora Packaging]     [CentOS]     [Fedora SELinux]     [Big List of Linux Books]     [KDE Users]     [Fedora Art]     [Fedora Docs]

  Powered by Linux