User handling logic


#1

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


#2

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


#3

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 danr@activestate.com:

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