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
Freeipa-users@redhat.com
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
