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(a)rea-group.com
> <mailto:colin.panisset@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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users