[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Chef and LDAP Users

[AJ Christensen < >]

The recipe isn't dictating how it is done. You are. There is no
"problem with the recipe", if anything it sounds like a bug regarding
directory defaulting to root/root, or the interaction between lazy and
the outputs of the Library you're using. I don't know, I can't tell
without trying more :-)

Put your keys in /etc/ssh/keys/%u as has been suggested (that zap
cookbook looks super cool) to avoid the problem altogether.
Alternatively store keys in LDAP. Both methods ensure a user cannot
inject any old key into authenticated keys between Chef converges.

I don't know what is causing the directory to be created root/root, if
the ShellGetent lookups w/ lazy are working. You can run with debug
mode to see what values the directory is being created with, by Chef
itself.

Post your debug logs if you can't read English.

--AJ

On Fri, Aug 1, 2014 at 8:13 AM, Douglas Garstang
<
 >
 wrote:
> I'd prefer not to allow a problem with the recipe dictate the way it's done.
> PAM currently sets the directory to be user.group, and I'd like to stick
> with that.
>
> Doug.
>
>
> On Thu, Jul 31, 2014 at 1:04 PM, Joe Nuspl 
> <
 >
>  wrote:
>>
>> Nope.  The directory and files can be root:root.  Just need to be world
>> readable.
>>
>> I like this because chef controls the contents and it can be audited.
>> Users can’t do things like put
>> Wile E. Coyote’s public key in their authorized keys file (for those who
>> don’t have a data bag entry).
>>
>> <shameless-plug>
>> You will probably want to https://github.com/nvwls/zap that directory.
>> </shameless-plug>
>>
>>         Joe
>>
>> On Jul 31, 2014, at 12:54 PM, AJ Christensen 
>> <
 >
>>  wrote:
>>
>> > Does that directory still need to have uid/gid permissions, 0700/0600?
>> >
>> > On Fri, Aug 1, 2014 at 7:53 AM, AJ Christensen 
>> > <
 >
>> >  wrote:
>> >> Boom! That's even simpler.
>> >>
>> >> --aj
>> >>
>> >> On Fri, Aug 1, 2014 at 7:52 AM, Joe Nuspl 
>> >> <
 >
>> >>  wrote:
>> >>> Or you could configure sshd to look for authorized keys some place
>> >>> other
>> >>> than the user's home directory.  For example:
>> >>>
>> >>> AuthorizedKeysFile     /etc/ssh/keys/%u
>> >>>
>> >>> And then have your recipe populate that directory…
>> >>>
>> >>> Joe
>> >>>
>> >>> On Jul 31, 2014, at 12:37 PM, Douglas Garstang
>> >>> <
 >
>> >>> wrote:
>> >>>
>> >>> AJ,
>> >>>
>> >>> There home directories are being created by LDAP and PAM on first
>> >>> login.
>> >>> However, that does not handle the setup of the ssh authorized keys
>> >>> file. For
>> >>> select users, I wanted chef to create the home directories, with the
>> >>> correct
>> >>> uid and gid pulled from LDAP, and then pull the ssh public key from a
>> >>> data
>> >>> bag and drop it into their home directory. Obviously, the LDAP recipe
>> >>> has to
>> >>> run first in the run list. This should be pretty simple.
>> >>>
>> >>> My latest attempt, based on your suggestion, is not working however. I
>> >>> believe the uid and gid are correct (although I can't print them
>> >>> because
>> >>> that causes it to fail. How do I print lazy variables? I tried using
>> >>> lazy in
>> >>> the log statement and it failed), but I can't verify because I can't
>> >>> print.
>> >>> When the recipe has run, /home/doug is owned by root.root.
>> >>>
>> >>> Doug
>> >>>
>> >>> # recipe
>> >>> include_recipe "foo-ldap"
>> >>> bag = data_bag("ssh-keys")
>> >>> for item in bag do
>> >>>    user = data_bag_item('ssh-keys', item)
>> >>>    user_name = user['id']
>> >>>    directory "/home/#{user_name}" do
>> >>>        owner lazy { ShellGetent.uid "#{user_name}" }
>> >>>        group lazy { ShellGetent.gid "#{user_name}" }
>> >>>    end
>> >>> end
>> >>>
>> >>> # library:
>> >>> class ShellGetent
>> >>>    include Chef::Mixin::ShellOut
>> >>>
>> >>>    class << self
>> >>>        def uid(username)
>> >>>            return if username.nil? || username.empty?
>> >>>            x = new.getent(:passwd, username)[2]
>> >>>        end
>> >>>
>> >>>        def gid(username)
>> >>>            return if username.nil? || username.empty?
>> >>>            new.getent(:passwd, username)[3]
>> >>>        end
>> >>>    end
>> >>>
>> >>>    # Returns a new slice of parts of the output. Maybe make a struct
>> >>> or
>> >>> something? Be creative!
>> >>>    def getent(type, name)
>> >>>        return unless %w(passwd).include?(type.to_s)
>> >>>        cmd = shell_out!("getent #{type.to_s} #{name}")
>> >>>        cmd.stdout.split(":")
>> >>>    end
>> >>>
>> >>> end
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Thu, Jul 31, 2014 at 11:23 AM, AJ Christensen 
>> >>> <
 >
>> >>> wrote:
>> >>>>
>> >>>> Another way to run the code during convergence time is to put the
>> >>>> code
>> >>>> in the body of an LWRP action, when the action fires (converge time)
>> >>>> the code will run (not compile time!)
>> >>>>
>> >>>> A way to tidy this is to put re-used logic in Libraries and refer to
>> >>>> those method/function calls from the LWRP itself.
>> >>>>
>> >>>> I believe that is most of the ways.
>> >>>>
>> >>>> Copying data in/out of resources at compile/convergence phase is one
>> >>>> of the most advanced/nasty pieces of knowledge you will gain
>> >>>> regarding
>> >>>> recipe authorship, I expect; it should be avoided.
>> >>>>
>> >>>> I would consider re-designing your entire user management system and
>> >>>> extract it from Chef; have like a little process that runs on every
>> >>>> node, listening to LDAP; when new users are made, use skel to
>> >>>> construct them. I could have sworn I saw functionality in PAM,
>> >>>> specifically for creating users home dirs and so-on, when logged in
>> >>>> from LDAP for the first time.
>> >>>>
>> >>>>
>> >>>> http://manpages.ubuntu.com/manpages/maverick/man8/pam_mkhomedir.8.html
>> >>>>
>> >>>> Many ways to shave dat yak.
>> >>>>
>> >>>> Chef -> configure LDAP -> configure PAM -> Users log in -> Home dirs
>> >>>> created automatically via PAM -> No compile/converge phase
>> >>>> shenanigans.
>> >>>>
>> >>>> Be careful configuring PAM, you can easily hose your system.
>> >>>>
>> >>>> --AJ
>> >>>>
>> >>>> On Fri, Aug 1, 2014 at 6:17 AM, AJ Christensen 
>> >>>> <
 >
>> >>>> wrote:
>> >>>>> My specific example shows the code being called at Convergence Time
>> >>>>> through a Lazy Attribute evaluation (a new Chef11 feature).
>> >>>>>
>> >>>>> Specifically: the attributes to the resource when lazy aren't
>> >>>>> evaluated at compile time, they are "finalized" so to speak at
>> >>>>> convergence time, when the action actually needs it!
>> >>>>>
>> >>>>> --aj
>> >>>>>
>> >>>>> On Fri, Aug 1, 2014 at 6:15 AM, Douglas Garstang
>> >>>>> <
 >
>> >>>>>  wrote:
>> >>>>>> AJ,
>> >>>>>>
>> >>>>>> Thanks. Now, what are the practical implications of compile and
>> >>>>>> converge in
>> >>>>>> relation to variable scope? How does one 'Run the ShellOut code
>> >>>>>> during
>> >>>>>> convergence'? Does it have to be in a library as you've done? Can
>> >>>>>> it be
>> >>>>>> done
>> >>>>>> another way? What exactly in a recipe makes something run at
>> >>>>>> compile or
>> >>>>>> converge time? How do you tell? How do you pass variables obtained
>> >>>>>> during
>> >>>>>> compilation (or is it convergence) back to the other?
>> >>>>>>
>> >>>>>> Doug
>> >>>>>>
>> >>>>>>
>> >>>>>> On Thu, Jul 31, 2014 at 11:12 AM, AJ Christensen 
>> >>>>>> <
 >
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> http://docs.getchef.com/essentials_nodes_chef_run.html
>> >>>>>>>
>> >>>>>>> * Compile the resource collection
>> >>>>>>>
>> >>>>>>> The chef-client identifies each resource in the node object and
>> >>>>>>> builds
>> >>>>>>> the resource collection. All libraries are loaded (to ensure that
>> >>>>>>> all
>> >>>>>>> language extensions and Ruby classes are available). And then all
>> >>>>>>> attributes are loaded. And then all lightweight resources are
>> >>>>>>> loaded.
>> >>>>>>> And then all definitions are loaded (to ensure that any
>> >>>>>>> pseudo-resources are available). Finally, all recipes are loaded
>> >>>>>>> in
>> >>>>>>> the order specified by the expanded run-list; each action
>> >>>>>>> specified in
>> >>>>>>> each recipe is identified before any Ruby code within a recipe is
>> >>>>>>> evaluated.
>> >>>>>>>
>> >>>>>>> * Converge the node
>> >>>>>>>
>> >>>>>>> The chef-client configures the system based on the information
>> >>>>>>> that
>> >>>>>>> has been collected. Each resource is executed in the order
>> >>>>>>> identified
>> >>>>>>> by the run-list, and then by the order in which each resource is
>> >>>>>>> listed in each recipe. Each resource in the resource collection is
>> >>>>>>> mapped to a provider. The provider examines the node, and then
>> >>>>>>> does
>> >>>>>>> the steps necessary to complete the action. And then the next
>> >>>>>>> resource
>> >>>>>>> is processed. Each action configures a specific part of the
>> >>>>>>> system.
>> >>>>>>> This process is also referred to as convergence.
>> >>>>>>>
>> >>>>>>> Run the ShellOut code during convergence after the LDAP code has
>> >>>>>>> converged (instead of at compile time as your example inaccurately
>> >>>>>>> attempts to represent mine)
>> >>>>>>>
>> >>>>>>> YMMV
>> >>>>>>>
>> >>>>>>> --aj
>> >>>>>>>
>> >>>>>>> On Fri, Aug 1, 2014 at 6:10 AM, AJ Christensen 
>> >>>>>>> <
 >
>> >>>>>>> wrote:
>> >>>>>>>> You ignored all of my examples and ran the code at Shell Out code
>> >>>>>>>> at
>> >>>>>>>> compile time. It will be executed before the other LDAP stuff is
>> >>>>>>>> actually converged.
>> >>>>>>>>
>> >>>>>>>> Don't be such a support vampire bro.
>> >>>>>>>>
>> >>>>>>>> --AJ
>> >>>>>>>>
>> >>>>>>>> On Fri, Aug 1, 2014 at 5:59 AM, Douglas Garstang
>> >>>>>>>> <
 >
>> >>>>>>>>  wrote:
>> >>>>>>>>> AJ,
>> >>>>>>>>>
>> >>>>>>>>> Thanks. I'm really not a ruby guy. It will take me considerable
>> >>>>>>>>> time to
>> >>>>>>>>> work
>> >>>>>>>>> out your gist. I tried this. I thought the call to
>> >>>>>>>>> Mixlib::ShellOut
>> >>>>>>>>> would
>> >>>>>>>>> fork a new process and therefore get me the correct result.
>> >>>>>>>>> However,
>> >>>>>>>>> cmd.stdout is empty on the first run, and contains the correct
>> >>>>>>>>> getent
>> >>>>>>>>> passwd
>> >>>>>>>>> reply on the second run, so I assume it's the same issue...
>> >>>>>>>>>
>> >>>>>>>>> include_recipe "foo-ldap"
>> >>>>>>>>>
>> >>>>>>>>> bag = data_bag("ssh-keys")
>> >>>>>>>>> for item in bag do
>> >>>>>>>>>
>> >>>>>>>>>    user = data_bag_item('ssh-keys', item)
>> >>>>>>>>>    user_name = user['id']
>> >>>>>>>>>
>> >>>>>>>>>    execute "create_homedir" do
>> >>>>>>>>>        command "mkdir /home/#{user_name}"
>> >>>>>>>>>        creates "/home/#{user_name}"
>> >>>>>>>>>        action :run
>> >>>>>>>>>    end
>> >>>>>>>>>
>> >>>>>>>>>    log "USER_NAME = #{user_name}"
>> >>>>>>>>>    cmd = Mixlib::ShellOut.new("getent passwd #{user_name}")
>> >>>>>>>>>    cmd.run_command
>> >>>>>>>>>    log ">>>>>>>>>>>>>>>>>>>>>>>>>>> NODE_DATA  = #{cmd.stdout}"
>> >>>>>>>>>    ent_array = cmd.stdout.split(':')
>> >>>>>>>>>    user_id = ent_array[2]
>> >>>>>>>>>    group_id = ent_array[3]
>> >>>>>>>>>
>> >>>>>>>>>    execute "homedir_perms" do
>> >>>>>>>>>        command "chown #{user_id}.#{group_id} /home/#{user_name}"
>> >>>>>>>>>        action :run
>> >>>>>>>>>    end
>> >>>>>>>>>
>> >>>>>>>>> end
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Wed, Jul 30, 2014 at 5:25 PM, AJ Christensen 
>> >>>>>>>>> <
 >
>> >>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> I meant to link to this too re: Mixlib ShellOut:
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> https://github.com/opscode/chef/blob/master/lib/chef/mixin/shell_out.rb#L29-L39
>> >>>>>>>>>>
>> >>>>>>>>>> 'git grep shell_out' in the Chef codebase, haha! You'll see all
>> >>>>>>>>>> of
>> >>>>>>>>>> the
>> >>>>>>>>>> places this is used.
>> >>>>>>>>>>
>> >>>>>>>>>> --aj
>> >>>>>>>>>>
>> >>>>>>>>>> On Thu, Jul 31, 2014 at 12:22 PM, AJ Christensen
>> >>>>>>>>>> <
 >
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>> If you 'include Chef::Mixin::ShellOut' in a custom library,
>> >>>>>>>>>>> you
>> >>>>>>>>>>> can
>> >>>>>>>>>>> use #shell_out! there.
>> >>>>>>>>>>>
>> >>>>>>>>>>> using the lazy attribute evaluator and the Mixin ShellOut
>> >>>>>>>>>>> classes'
>> >>>>>>>>>>> shell_out!() functionality, something like this outta' work:
>> >>>>>>>>>>> https://gist.github.com/fujin/f0b7dd38b558001c5913
>> >>>>>>>>>>>
>> >>>>>>>>>>> --aj
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Thu, Jul 31, 2014 at 12:03 PM, Daniel DeLeo
>> >>>>>>>>>>> <
 >
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>>> On Wednesday, July 30, 2014 at 5:00 PM, Douglas Garstang
>> >>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>> AJ,
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Thanks. One more question... shelling out in chef and
>> >>>>>>>>>>>>> grabbing
>> >>>>>>>>>>>>> the
>> >>>>>>>>>>>>> output... has never been an easy task... best approach?
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I was able to do this just now with the execute resource, I
>> >>>>>>>>>>>>> guess
>> >>>>>>>>>>>>> because that forks a new process too. It would be nice
>> >>>>>>>>>>>>> though
>> >>>>>>>>>>>>> to
>> >>>>>>>>>>>>> call getent
>> >>>>>>>>>>>>> in some fashion, and the parse the output, so that I could
>> >>>>>>>>>>>>> be
>> >>>>>>>>>>>>> sure
>> >>>>>>>>>>>>> that the
>> >>>>>>>>>>>>> group id I am assigning is the correct one for the user. At
>> >>>>>>>>>>>>> the
>> >>>>>>>>>>>>> moment it's
>> >>>>>>>>>>>>> coming out of a data bag.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Also kinda gross.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Doug
>> >>>>>>>>>>>> Well, it’ll be a little gross, but I think you’ll have to use
>> >>>>>>>>>>>> a
>> >>>>>>>>>>>> lazy
>> >>>>>>>>>>>> attribute
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> http://docs.getchef.com/resource_common.html#lazy-attribute-evaluation
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> In the code block you give to `lazy`, you can use backticks
>> >>>>>>>>>>>> or
>> >>>>>>>>>>>> %x
>> >>>>>>>>>>>> to
>> >>>>>>>>>>>> run a command that returns the UID.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> --
>> >>>>>>>>>>>> Daniel DeLeo
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>> Regards,
>> >>>>>>>>>
>> >>>>>>>>> Douglas Garstang
>> >>>>>>>>> http://www.linkedin.com/in/garstang
>> >>>>>>>>> Email: 
>> >>>>>>>>> 
 
>> >>>>>>>>> Cell: +1-805-340-5627
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Regards,
>> >>>>>>
>> >>>>>> Douglas Garstang
>> >>>>>> http://www.linkedin.com/in/garstang
>> >>>>>> Email: 
>> >>>>>> 
 
>> >>>>>> Cell: +1-805-340-5627
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Regards,
>> >>>
>> >>> Douglas Garstang
>> >>> http://www.linkedin.com/in/garstang
>> >>> Email: 
>> >>> 
 
>> >>> Cell: +1-805-340-5627
>> >>>
>> >>>
>>
>
>
>
> --
> Regards,
>
> Douglas Garstang
> http://www.linkedin.com/in/garstang
> Email: 
> 
 
> Cell: +1-805-340-5627