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 <wibrown@xxxxxxxxxx> wrote:
Thank you that's great to hear! I've just pushed the patch up now forOn 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.
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-leave@lists.fedoraproject.org
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
