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

[Rich Megginson]

On 05/31/2011 08:41 PM, Colin Panisset wrote:
> 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?
https://bugzilla.redhat.com/show_bug.cgi?id=668808
>    -- 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
>>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users