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 <d...@redhat.com> 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
>         > 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 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
>         Freeipa-users@redhat.com
>         https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> 
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to