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@xxxxxxxxxxxxx >>> <mailto:colin.panisset@xxxxxxxxxxxxx>> >>> >>> 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@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
