Again a wonderful job William. I always feel proud to work with you and This change surely deserves outstanding support.
I am thinking, we can publicize this by doing articles on Fedora Magazine and Commblog. Also, we should be mentioning about this change in one of our diversity presentations to inspire others. firstyear++ :) Regards, Ami On Fri, Jan 12, 2018 at 10:07 AM, William Brown <wibr...@redhat.com> wrote: > On Thu, 2018-01-11 at 16:40 +0000, Brian (bex) Exelbierd wrote: > > > 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. > > Thank you that's great to hear! I've just pushed the patch up now for > our 1.4.0 server support this. :) > > > > > 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@lists.fedoraproject.org > > To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.o > > rg > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Australia/Brisbane > _______________________________________________ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org >
_______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
