Re: [Freeipa-users] [RFC] Feature idea - ENV vars/profile scripts in directory

[Артур Файзуллин]

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  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: 
> > 
> > 
> > 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.
> 

Re: [Freeipa-users] [RFC] Feature idea - ENV vars/profile scripts in directory

[Dmitri Pal]

On 07/10/2013 05:53 PM, Alan Evans wrote:
> 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.

I might have looked at it in a more generic way as more system ENV VARs
than personal preferences.
But here is a question. Are your preferences same on all systems?
It seems that preferences should be more targeted to the groups of
systems rather than be a property of the user.
What your are talking about here is effectively a roaming profile. I
think in Windows you can define which groups of systems the profile
roams between.

I do not have any negative feelings about the idea of storing the
information in LDAP. But IMO it makes sense to view it more as a user
preferences. I would think that it should be something like:

userPreferences: 

That would allow more flexibility and would not require protocol changes
to add new things as needed.
And have it be associated with user-host pair. It is expressed by
association object class in IPA.

But let us assume we say it is not a bad idea and can be done. What is next?
I can say for sure that we will not invest into changing pam_ldap to
support it. Only SSSD. Will it make the solution irrelevant for you?




>
> 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  > 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: 
>>
>> 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 rewr

Re: [Freeipa-users] [RFC] Feature idea - ENV vars/profile scripts in directory

[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  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: 
>
>  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.txtRFC 
> 2251 "4.1.5. Attribute Description" if not familiar)
>  dn: uid=me,dc=example,dc=com
> ...
>  posixProfile;~/.bashrc: 
>  posixProfile;~/.my.cnf: 
>
>  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: 
>  posixProfile;.foo/foorc: 
>
> 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 
> listFreeipa-users@redhat.comhttps://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 e

Re: [Freeipa-users] [RFC] Feature idea - ENV vars/profile scripts in directory

[Alan Evans]

Oops I think my first reply went to Dimitri only:

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  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: 
>
>  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.txtRFC 
> 2251 "4.1.5. Attribute Description" if not familiar)
>  dn: uid=me,dc=example,dc=com
> ...
>  posixProfile;~/.bashrc: 
>  posixProfile;~/.my.cnf: 
>
>  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: 
>  posixProfile;.foo/foorc: 
>
> 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 
> listFreeipa-users@redhat.comhttps://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. 

Re: [Freeipa-users] [RFC] Feature idea - ENV vars/profile scripts in directory

[Dmitri Pal]

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: 
>
> 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: 
> posixProfile;~/.my.cnf: 
>
> 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: 
> posixProfile;.foo/foorc: 
>
> 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 eit