[389-users] Role-based CoS and subtypes [Was: Views, Filtered roles and CoS]

Colin Panisset colin.panisset at rea-group.com
Wed Jun 1 02:41:18 UTC 2011


So, as a followup, I'm now trying to combine this with role-based CoS
overrides, but it's not working.

I'd like to set the loginshell;devel attribute-subtype via a filtered
role so that I can maintain it in a single place

I have this classic Cos definition:

dn: cn=cosOverrideDevShell,dc=example,dc=com
cosAttribute: loginshell;devel override
objectClass: cosClassicDefinition
objectClass: cosSuperDefinition
objectClass: ldapSubEntry
objectClass: top
cosspecifier: nsRole
costemplatedn: cn=cosTemplates,dc=example,dc=com
cn: cosOverrideDevShell

which references templates in this container:

dn: cn=cosTemplates,dc=example,dc=com
cn: cosTemplates
objectClass: top
objectClass: nscontainer

The only template in the container is:

dn: cn=cn\3DDeveloper\2Cdc\3Dexample\2Cdc\3Dcom,cn=
 cosTemplates,dc=example,dc=com
cn: cn=Developer,dc=example,dc=com
loginShell;devel: /bin/bash
objectClass: top
objectClass: costemplate
objectClass: extensibleobject

which references this Role:

dn: cn=Developer,dc=example,dc=com
nsRoleFilter: (objectclass=person)
objectClass: top
objectClass: ldapsubentry
objectClass: nsroledefinition
objectClass: nscomplexroledefinition
objectClass: nsfilteredroledefinition
cn: Developer

and yet the loginshell;devel attribute-subattribute doesn't get set.

I'm looking with ldapsearch:

$ ldapsearch -x "(nsrole=cn=developer,dc=example,dc=com)" loginshell\;devel

but it's never set.

I've tested the syntax of my templates and definitions by adding a
second cosAttribute to the definition, thus:

cosAttribute: mobile override

and then adding the attribute to the template:

mobile: +123456

and an ldapsearch *does* show the mobile attribute being set for that
set of users, but not the loginshell;devel attribute overriden by the
same template.

This isn't a showstopper, I can update every entry to add the
loginshell;devel subattribute, but I'd much prefer to have it set
dynamically, as this will then prevent future account creation mishaps.

Is this something I should be able to do?

  -- C.


On 1/06/11 8:50 AM, Colin Panisset wrote:
> That's *exactly* what I need to do, and a solution that works perfectly
> for me.
> 
> Thanks!
> 
>   -- C.
> 
> On 1/06/11 1:45 AM, Andrey Ivanov wrote:
>> Hi Colin,
>>
>> you can use two different attributes (or the subtypes of an attribute).
>> But it implies that the nss_ldap configuration file on development
>> servers is different. That's the way we do it. Example:
>>
>> the user entry :
>> dn: uid=test.user,ou=People,dc=example,dc=com
>> loginShell: /bin/rbash
>> loginShell;devel: /bin/bash
>> uid: test.user
>> ...
>>
>> If you use RedHat/CentOS 5.x the only difference between the nss_ldap
>> configuration files (/etc/ldap.conf) will be the mapping part on
>> development servers :
>> nss_map_attribute loginShell loginShell;devel
>>
>> This example uses the attribute subtype ';devel' but you are free to
>> choose anything you like.
>>
>> It's not a pure ldap solution, but rather a mix of ldap and server-side
>> solution. Don't know whether it helps you but that's how we use it (this
>> way,the same ldap user may have several "personalized" posix attributes
>> depending on the /etc/ldap.conf configuration of the server) :
>> nss_map_attribute uidNumber uidNumber;devel
>> nss_map_attribute gidNumber gidNumber;devel
>> nss_map_attribute homeDirectory homeDirectory;devel
>> nss_map_attribute loginShell loginShell;devel
>>
>> @+
>>
>> 2011/5/31 Colin Panisset <colin.panisset at rea-group.com
>> <mailto:colin.panisset at rea-group.com>>
>>
>>     I have a pretty flat DIT, with all users currently under
>>     ou=people,dc=example,dc=com; these user objects also have posixAccount
>>     attributes, of which loginShell is one.
>>
>>     What I'm trying to achieve is to be able to set a "default" loginShell
>>     to be a restricted shell (/bin/rbash) for developers, but allow that to
>>     be a non-restricted shell on systems which are development hosts.
>>
>>     As an example, on a production host I'd like:
>>
>>     $ ldapsearch -x "(uid=devuser)" uid loginshell
>>
>>     to return:
>>
>>     dn: cn=Dev User,ou=People,dc=example,dc=com
>>     loginShell: /bin/rbash
>>     uid: devuser
>>
>>     while on a development host, I'd like the same search to return
>>
>>     dn: cn=Dev User,ou=People,dc=example,dc=com
>>     loginShell: /bin/bash
>>     uid: devuser
>>
> 
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> 




More information about the 389-users mailing list