[chef] RE: Re: Re: Question about Chef running as root


Chronological Thread 
  • From: Kevin Keane Subscription < >
  • To: < >
  • Subject: [chef] RE: Re: Re: Question about Chef running as root
  • Date: Tue, 14 May 2013 03:05:54 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=sendgrid.info; h=subject :from:to:mime-version:content-type:in-reply-to:references :sender; q=dns; s=smtpapi; b=zM0pC/g0tdyGx7eGzJII+6XlrUzYZ7UOdKE Z56DL2ApzPSbontB+YxSfQEB7uxWeiWiGoZCqHJ2NbNg3sgd+tFlFikIZCvlzOUB QRXZx7TplltLDcaXMfPzvuymQnV9rxdV+OpCka3nRw98aiTmRlBFSnb1dhnawVzB n6tnXfqI=

Title: RE: [chef] Re: Re: Question about Chef running as root

I'm running chef on CentOS 6.4 with SELinux enabled and IPTables running, but there are a number of tricks to observe:

- Older versions of chef will clobber SELinux contexts. With these versions, after each chef run, you will need to run restorecon on any files chef may have touched. Chef 11.4 has mostly fixed that (there are still a few issues with the RemoteDirectory resource, I believe). This fix is not documented, but rather seems to be an artifact of some redesign.

- Don't use the Apache community cookbook, or any cookbooks that depend on it. Just as you say, it was written with Ubuntu in mind, and I don't think it really matches the SELinux contexts in CentOS. You can of course come up with fixed SELinux contexts, but that is a fairly massive undertaking to get it right.

- I don't really see why iptables would be a problem. Are you generating the iptables configurations using chef, and if so, which cookbook are you using?

Personally, I'm using shorewall-lite, and I use chef to auto-generate the shorewall files.

-----Original message-----
From: Lunixer < >
Sent: Friday 10th May 2013 9:53
To:
Subject: [chef] Re: Re: Question about Chef running as root

In all docs I've read, the assumption is that one is working with Ubuntu. But that is not always the case.

There are slight differences when using, say, CentOS; the "--sudo" part didn't work for me. I had to use root to bootstrap a node.

Also, in CentOS 6.4, I had to disable selinux and stop iptables so I could access HTTPS from a remote web client. Don't know whether that's an issue in Ubuntu.         

-lun


On Wed, May 8, 2013 at 1:50 PM, Nguyen, Dang < " target="_blank" title="This external link will open in a new window"> > wrote:
Just to clarify a couple of things I read in your email that could be part of the confusion:

  • when you run "knife bootstrap" against a target node, you can/should login as yourself and use the "--sudo" option. This option opens a SSH session under your login and then runs the rest of the bootstrap under the "sudo" environment that you specified. This is entirely do-able with EC2 where you'll ssh into the EC2 instance as the "ubuntu" user, for example, if you're running Ubuntu instances.
  • On the target node, there is an agent that runs, called the chef-client, that normally runs as root. Even if your node doesn't allow direct login as root, your chef-client can still run as root, and in most cases, for the tasks that the chef-client needs to do, this is almost a requirement. In theory, you can run the chef-client as another user, but you will need to work out the cascading permissions issues that will surely crop up. The chef-client runs under a pull model, where it will reach out to the chef server to get its set of instructions and other data that it'll need for the chef run (aka cookbooks, recipes, attributes, etc). Once it gets all that data from the server, it runs independently of the server and uploads some data back at the end of the run that reports on the new state of the node. The chef-client will need to access HTTPS 443 port to reach the server, so make sure your firewalls are playing nicely.
HTH,
Dang Nguyen



Hello all,

I'm fairly new to Chef. I stepped through some parts of the documentation to understand what Chef is all about, and I have a rough idea.

So I am working on a project now that already uses Chef to deploy to servers. I kind of jumped into the middle of it (it was al written by someone else). The way it currently works from what I can see, is the when the scripts are run, it logs into the server as root, and then does what it needs to do based on json files. This has worked well so far, but now I am facing an issue with deploying to Amazon EC2 instances.

With Amazon EC2, we can't log in as root by default, only whatever user that is assigned (i.e. "ubuntu for Ubuntu instances, "ec2-user" for RHEL etc.). I cannot change that at the moment, so I have to find another way to do it.

My question is: does Chef always run as root? Is there a way to bypass the root user altogether, and use another user with all the privileges? How would you recommend that I tackle this?

As I said, I'm very new to this so kindly bear with me.

Thank you!







Archive powered by MHonArc 2.6.16.

§