If You will use automount of home dirs, it will allready centrelaised. В Ср, 10/07/2013 в 15:53 -0600, Alan Evans пишет: > Man I just can't seem to reply to this list correctly. I hope the > other two didn't actually go anywhere. > > Dimitri, > > > I do not mean to store system environment variables but MY environment > variables. > > > dn: uid=alan,dc=example,dc=com > > objectclass: top > > objectclass: posixAccount > > objectclass: inetOrgPerson > > objectclass: posixAccountEnv > ... > > uid: alan > > cn: Alan Evans > > posixEnv: EDITOR=vim > > # or > > posixEnv;EDITOR: vim > > > > In my opinion while these do not necessarily meet the definition you > just described they are distinctly MY preferences and I would argue > they belong with my object in LDAP. Storing some environment > variables isn't that different from storing my preferred shell, or my > preferred contact information and so on. > > > As for implementing it could be all done in pam_ldap which would be > pretty easily portable. > > > HTH, > > -Alan > > > > On Wed, Jul 10, 2013 at 3:20 PM, Dmitri Pal <[email protected]> wrote: > On 07/10/2013 04:48 PM, Alan Evans wrote: > > So I have been kicking around an idea for a while now and > > thought I would develop it but its out of my league. The > > FreeIPA community is very very active in pam/sssd/ldap/so on > > and so on so I thought I would float the idea here before I > > made a Trac [RFE] ticket. > > > > > > Would anyone else find it useful to store environment > > variables in LDAP? In the environment (no pun intended) I > > work in we have a few thousand servers all authenticating to > > LDAP and a home grown LDAP+sshPublicKey implementation which > > is great. But we have a bunch of different distros which > > all have different default editors. Unless I feel like > > touching a lot of servers or using cfengine3 to distribute > > my preferred environment variables I am at the mercy of the > > editor on the system. > > > > How wonderful would it be to set EDITOR=vim, LESS='-S', > > TZ='America/Hawaii', LANG='Klingon' in LDAP and have pam/sss > > pull/store that information for me. Sort of like pam_env > > but backed by LDAP. > > > > > > So this got me thinking the other thing that would be > > wonderful to store in LDAP would be shell profiles... > > Consider having your ~/.profile or ~/.bashrc or ~/.my.cnf > > or what-have-you in LDAP? > > > > Maybe this modified pam_ldap could do things like append, > > remove, replace or unset environment variables. Consider: > > > > > > dn: uid=me,dc=example,dc=com > > > > objectClass: posixAccountEnv > > > > ... > > > > # replace EDITOR > > > > posixEnv: EDITOR=vim > > > > # unset TZ > > > > posixEnv: TZ-= > > > > # append PATH > > > > posixEnv: PATH=+:~/bin > > > > # prepend PATH > > > > posixEnv: PATH+=/opt/foo/bin: > > > > > > > > Further perhaps the PAM module could be configured to only > > allow certain environment variables to be manipulated this > > way admins can control which variables users can set. > > > > > > /etc/ldap/pam_ldap.conf: > > ... > > > > # allow > > > > pam_allow_env_vars PATH,EDITOR > > > > # deny > > > > pam_deny_env_vars PATH,TZ > > > > # wildcards? regex? > > > > pam_allow_env_vars LC_*,PATH,EDITOR > > > > pam_deny_env_vars TZ > > > > > > > > So if we're storing environment variables in LDAP why not > > profiles or small files? ~/.bashrc, ~/.my.cnf, > > ~/.ssh/config? Sure there's some overlap with env vars > > because you could set them in your profile but with both > > options an admin is free to choose. > > > > > > > > I can think of a couple of ways to implement this. > > > > 1. create subortinate objects to the user object > > > > dn: cn=~/.bashrc,uid=me,dc=example,dc=com > > ... > > > > objectClass: posixAccountProfile > > > > posixProfile: <octet string> > > > > > > Advantages: The advantage of this setup is that the > > profileScript class could contain any number of attributes, > > perhaps a modified time so that the script isn't rewritten > > if the subordinate object hasn't been modified since the > > script was last modified. > > > > > > Disadvantages: Kinda kludgy. Extra objects (more lookups). > > > > > > > > 2. Use LDAP attribute options (See > > http://www.ietf.org/rfc/rfc2251.txt RFC 2251 "4.1.5. > > Attribute Description" if not familiar) > > > > dn: uid=me,dc=example,dc=com > > ... > > > > posixProfile;~/.bashrc: <octet string> > > > > posixProfile;~/.my.cnf: <octet string> > > > > > > Advantages: No extra objects, makes use of oft unused LDAP > > attribute options :), can have ACI's applied to them. > > Disadvantages: Only modified time to track is modified time > > of the LDAP object not individual profileScript attrs > > > > > > In both cases it might be wise to consider how file names > > are specified. Perhaps leave off the ~/ and make everything > > relative to ~ no matter what. Or make everything relative > > to ~/ even if it starts w/ a '/'. Maybe simply reject > > anything that begins with '/'. > > > > dn: uid=me,dc=example,dc=com > > ... > > > > posixProfile;.bashrc: <octetString> > > > > posixProfile;.foo/foorc: <octetstring> > > > > Plus I don't know if / and . are legitimate characters in > > attribute options. > > > > > > So thanks for sticking with me if you got this far. What do > > you think? > > > > > > Regards, > > > > -Alan > > > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > [email protected] > > https://www.redhat.com/mailman/listinfo/freeipa-users > > I see couple problems but in a different plane. > 1) You are talking about the server storing this data, it is > not standard but extension can be made. The bigger problem is > the client. Creating the client and porting it to multiple > distros is a challenge. SSSD is in Linux but not in classical > UNIXes. As you start looking at the client side effort > solutions like Puppet, Chef and friends become much more > attractive. > 2) Which ENV vars need to be served to which groups of hosts. > You need the infrastructure to define and manage it. Puppet, > Chef and others are already good at it. > > So I am not really sure that adding the suggested data to LDAP > is the right place. LDAP is just a storage format and client > protocol. This is the smallest part of the effort. This would > effectively lead to duplicating some of existing management > systems. > > We discussed things like that several years ago when we were > starting IPA project. We needed to draw the line about what to > store and what not to store in LDAP. We came up with a > following definition: > Store things that are either traditionally stored in LDAP and > already have LDAP schema of some sort, store things that are > dynamic and must be looked up on the fly because security > decision or configuration relies on it. > That leaves LDAP to be storage of identities (user, groups, > hosts, host groups) and remappings of those identities to the > externally managed objects, i.e. user(s) to command(s) = sudo, > user(s) to host access = HBAC, user(s) to SELinux policies = > SELinux user mappings, users and hosts to SSH keys = SSH > integration. > > So realistically you might want to have something similar to > what we have for SELinux user mapping that would deliver a > "tag" to a host and then pass it to some pam module that would > configure system using that tag or use this tag to fetch > something from a central policy server. But that would again > require a client and server change and if you want it to be > available on multiple platforms you face the same challenge as > in 1). > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/freeipa-users
_______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
