0

I'm using knife to bootstrap my VM with vanilla Debian 7.0 installation. In bootstrap stage I'm just setting sources.list, updating & upgrading system, then I install buil-essential, rsync and ruby1.9.1 (with rubygems). As a last step, my bootstrap template install chef as a gem.

Bang! my node is in this point bootstrapped and ready to run recipes. But on that machine is still only root able to run chef-solo. And this a point I'm getting confused:

  • should I use root to run my recipes on target node?
  • or should I bootstrap separate system user with elevated permisions by sudo with nopasswd?
  • or should I cook that separate unix user using some recipe?

The thing is, when I run knife solocook some_user@some.node.tld I want to cook (provision) that machine as non-root user (for example user named chef). You know, some of my recipes will setup sshd not to accept connections to root (as one of the security measures).

But if some other recipe will setup unix user named chef and some another sudo for that user, then until that point I must cook as root. And then, if I want to cook as a chef, I must run knife solo cook ... again, with separate list of recipes.

And to me this is complete antipattern. Node should be provisioned in one step. So my question is, should I leave the idea of provisioning as other user as root and use root to run all my chef recipes?

srigi
  • 121
  • 1
  • 4

2 Answers2

0

In my project, I choose this pattern(in AWS, 'ec2-user' will do this)

bootstrap separate system user with elevated permisions by sudo with nopasswd

and the following command works just fine. 

ssh wheel_user@some_host sudo /usr/local/bin/chef-solo -c /chef_dir/.chef/solo.rb -j /chef_dir/.chef/chef.json

In my case, I'm not using 'knife solo' but just a 'chef-solo'.

Naoyuki Yamada
  • 106
  • 3
0

Chef is meant to be run as root. There is no way to provision a box other than as a root process in the general case.[1]

This means you need to either run it as root, or run it in an elevated process as root via sudo or other means.

You are running into an anti-pattern because you are using chef in a way that it wasn't intended. Even as chef-solo, it's designed to be run as root via a cron job or a daemon at regular intervals.

Your use case may be entirely valid, but you may be using the wrong tool. If you want this kind of push only configuration management, Ansible might be a better match for what you are attempting to do. If you don't envision running chef at regular intervals as part of your normal work, then chef might not be the right tool.

[1]- If you tweak all the permissions of the files chef wants to manage, you can run it as an ordinary user, it's just difficult for more than very simple recipes.

Fred the Magic Wonder Dog
  • 2,095
  • 12
  • 17