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