Andrey Ivanov wrote: > > * support of other virtual attributes generated "on the > fly" > > Can you explain this a little more? > > > For example, the memberOf attribute now generated by memberOf > plugin and written into the db could be generated dynamically. > > For the particular case of memberOf, we decided against using > virtual attributes. One reason is that it's harder to do > filtering/indexing on virtual attributes e.g. supporting searches > like (memberof=somegroup). > > Yes, i remember this reasoning - i was following quite closely the > development of this plug-in as it was sine qua non for our production > environment... > > > > The attributes like entryLevelRights and attributeLevelRights > are already created dynamically, nsRole/CoS also (one of the > main drawbacks of the roles is that they are only applicable > to a sub-tree). > > 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... Do you want to do something like this 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? > > > I'm talking about this type of "virtual" attributes generated > by some filters or regular expressions or plug-ins, maybe > creation of some sort of framework or mechanism to generalize > the creation of such attribiutes. > > There already is a framework, but not many want to delve into the > C code. > > Can you provide some examples of what you mean? > > 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/| It would be difficult to create indexes on these (e.g. if you wanted to do searches like (displayOu=LPP/*) Something like that would be useful for posix homeDirectory too cosAttribute: uid cosDestinationAttribute: homeDirectory cosRegex: s,(.+),/home/\1, > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20090415/846f7dab/attachment.bin
