Do you want to do something like this
One of the drawbacks of groups is that they do not apply to the
sub-tree - makes it difficult in general to replicate them.
Roles/CoS are scoped along with the data they apply to, so they
go along with replication quite easily.
Yep.You're talking about the drawbacks concerning the difficulty of the code development. But for us the sub-tree application that was an essential limitation of Roles - we couldn't use it to make the same thing as memberof, that's why i was looking forward eagerly for the memberof plugin...
dc=example,dc=com
+ou=people
+ou=roles
++cn=my role
And have cn=my role be a role that applies to users under ou=people? e.g. by adding a roleSubtree: ou=people,dc=example,dc=com to the role definition?
Yes. An attribute like that is already a good step forward that would permit to organise the roles in the way that is independent of the sub-trees to which they are applied.
For example, automatic generation of a virtual attribute describing the location (or type) of the person by applying regex to his/her telephoneNumber (first n digits). But then again you are right about indexing and filters with these attributes... Another example: in our production environment we have a "ou" attribute containing the DNs of the units where the person belongs. It would be nice to convert it automatically to an attribute "displayOu" with slashes instead of ",ou=":
ou: ou=lpp,ou=lab,ou=dgar,ou=dg,ou=organisation,dc=example,dc=com
displayOu: LPP/LAB/DGAR/DG
Today we are using scripts. This type of attribute conversion can easily be made inside an application if you write it internally, otherwise one needs to add this type of "converted" attributes...
Ok. So something like CoS, but with a couple of additional attributes:
cosDestinationAttribute - grab the value from cosAttribute, but write to this attribute instead
cosRegex - apply this regex to the value e.g.
cosAttribute: ou
cosDestinationAttribute: displayOu
cosRegex: s|ou=(\S)+,ou=(\S)+,ou=(\S+),ou=(\S+)|\1/\2/\3/\4/|
Yes, something like that.
It would be difficult to create indexes on these (e.g. if you wanted to do searches like (displayOu=LPP/*)
Exactly. That why i have told that it is not a high-order priority for us but it would be a nice feature in one of the future versions...
Something like that would be useful for posix homeDirectory too
cosAttribute: uid
cosDestinationAttribute: homeDirectory
cosRegex: s,(.+),/home/\1,
yes, in our production environment we often need attributes that are generated automatically from other ones...
Thank you for taking your time to understand our needs and to formalize the requests! :)
Thank you for taking your time to understand our needs and to formalize the requests! :)
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
