[389-devel] Re: Improve the demo objects from install

2018-01-11 Thread Amita Sharma 
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  wrote:

> On Thu, 2018-01-11 at 16:40 +, 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.
> > >
> > >

[389-devel] Re: Improve the demo objects from install

2018-01-11 Thread William Brown 
On Thu, 2018-01-11 at 16:40 +, 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

[389-devel] Please review: Improve demo objects for 1.4.0

2018-01-11 Thread William Brown 
https://pagure.io/389-ds-base/issue/49425

https://pagure.io/389-ds-base/issue/raw/files/9cb1510fb39a94a62af4a7dbc
8a3f14caea0c10f94e4b13bf51e98f0376f4e5d-0001-Ticket-49425-improve-demo-
objects-for-install.patch

-- 
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] please review: Ticket 49529 - Fix coverity warnings: invalid dereferences

2018-01-11 Thread Mark Reynolds 
https://pagure.io/389-ds-base/issue/49529

https://pagure.io/389-ds-base/issue/raw/files/60c50df29914ff67f8d99b1ac717941c6913bb069a6552cf7318f4c49877881d-0001-Ticket-49529-Fix-Coverity-warnings-invalid-deference.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: Improve the demo objects from install

2018-01-11 Thread Brian (bex) Exelbierd 
> 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@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org