[chef] Re: Re: user handling logic

[Leonard Messier < >]

Thanks Dan, 

Your solution is interesting but I don't think it will easily apply to my solution.

I think I have a conception problem. 

As you pointed out, my user is set prior to any chef execution. I think I should keep the dummy user from my base installation and create my real user with chef. 

That way, I can stick with using sudo to launch the chef-solo command and use data bags to configure users. In my recipes, instead of hard coding the user and group value or using an environment variable like SUDO_USER, I could loop on the users data bag and apply resources for each user, allowing for future user creation. 

What do you think of it ?

Léonard Messier

2014-02-08 0:15 GMT+01:00 Dan Razzell < " target="_blank"> >:

Basically, yes, at least if you want to express the goal within Chef.  Though, given that you've set up the user external to Chef anyway, that might be a more congruent point to add to sudoers. Logically, it's a property of the user account, just that for historical reasons it isn't recorded along with the account.

Then you'll have your main Chef session running as the specified working user.  But even though that user is now in sudoers, it doesn't have root privileges itself.  Therefore all of the resources where you might want to specify a user/owner/group attribute other than the working user, say root for example, will not work.

This includes bash and execute as well.  Though you can get the desired effect by defining their command attribute as a sudo command, you're leaving Chef behind at that point.

All in all, unless the scope of what you want to do is genuinely limited to that working user, you might want to run Chef as root and then specify user/owner/group attributes wherever you want a more restricted effect.  This will work as expected (except for recursive directory creation which has unusual semantics in Chef).

If you want to run bash by default as the specified user, our solution here was to extend the bash provider as something we call bash_strict.  It's defined in a library file and looks like this:

require "chef/resource/script"

class Chef
  class Resource
    class BashStrict < Chef::Resource::Script

      def initialize(name, run_context=nil)
        super
        @resource_name  = :bash_strict
        @interpreter    = "bash"
        @flags          = "-e"
        @user           = "your default user goes here"
        @group          = "your default group goes here"
        @verbose        = nil
      end

    end
  end
end

Hope you find this useful.

Dan

On 14-02-07 03:45 AM, Leonard Messier wrote:

Hi there,

I'm facing an issue related to the way I'm supposed to handle users on the machine I'm provisioning with chef-solo.

Since it is a physical machine, the user I'm using was created during installation. I would like to go on using this user.

In the past, I used to launch chef-solo with sudo because it was simpler to achieve what I wanted to do.
Since I've started to include rspec testing in my process, I can't use sudo directly anymore : I relied on "#{ENV['SUDO_USER']}" in my recipes to set the proper user and group, which is not available anymore with rspec and I don't think it's a good idea to launch rspec as sudo.

Now, I'm trying to find a way to handle this logically. Obviously, I need my user to have sudo access. My first move was to include the sudo community cookbook. However, i'm kind of stuck here because the chef run needs to have sudo privileges to create the sudoers file.

Am I supposed to have a one item run list that does this small step, launching chef-solo as sudo ?


--
Léonard Messier

--
Léonard Messier
Développeur web PHP/_javascript_/MySQL
http://www.leonardmessier.com