Add chef-client cookbook to chef bootstrap

Hi guys,

I seek help from IRC and thanks Cheesepl_ and *hoover_damm *for helping
me tonight.

knife bootstrap 192.168.1.29 -x admin -P password --sudo -VV -r ‘role[base]’

I bootstrapped a machine and I turned it off. It didn’t talk to the
chef-server to check in so I was wondering why.

It turns out that there was no init. This should not be the default
behavior if it is. I thank hoover_damm from IRC channel to point out
chef-client cookbook.

I think, there should be a base.rb provided, minimally it should adds
chef-client cookbook to it, as someone else will turn down one of the nodes
down for maintenance and on the server it should know about the update.

Why isn’t this the default behaviour through bootstrap?
Actually, forget about the base.rb. Why isn’t the init thing part of the
chef setup? If a user wants to change it to upstart or whatever, there
should be a configuration / manually set it. But not knowing that
chef-client will not start automatically seems odd. Also, putting it inside
/opt/chef/ is also weird. I use Ubuntu 10.04 btw.

Thanks.

John

Yo,

On 16 August 2012 15:00, John Wong gokoproject@gmail.com wrote:

Hi guys,

I seek help from IRC and thanks Cheesepl_ and hoover_damm for helping me
tonight.

knife bootstrap 192.168.1.29 -x admin -P password --sudo -VV -r 'role[base]'

I bootstrapped a machine and I turned it off. It didn't talk to the
chef-server to check in so I was wondering why.

It turns out that there was no init. This should not be the default behavior
if it is. I thank hoover_damm from IRC channel to point out chef-client
cookbook.

Packages should not automatically start services. That is the job of a
configuration management system.

I think, there should be a base.rb provided, minimally it should adds
chef-client cookbook to it, as someone else will turn down one of the nodes
down for maintenance and on the server it should know about the update.

I'd recommend monitoring configuration drift with a (monitoring)
system like Nagios or Sensu.

Why isn't this the default behaviour through bootstrap?
Actually, forget about the base.rb. Why isn't the init thing part of the
chef setup? If a user wants to change it to upstart or whatever, there
should be a configuration / manually set it. But not knowing that
chef-client will not start automatically seems odd. Also, putting it inside
/opt/chef/ is also weird. I use Ubuntu 10.04 btw.

Once the chef-full packages are installed you can use Chef to
configure services (or cron, etc) to manage chef-client (or chef-solo)
as appropriate.

Regards,

--AJ

Thanks.

John

On Wed, Aug 15, 2012 at 11:00 PM, John Wong gokoproject@gmail.com wrote:

Why isn't this the default behaviour through bootstrap?
Actually, forget about the base.rb. Why isn't the init thing part of the
chef setup? If a user wants to change it to upstart or whatever, there
should be a configuration / manually set it. But not knowing that
chef-client will not start automatically seems odd. Also, putting it inside
/opt/chef/ is also weird. I use Ubuntu 10.04 btw.

Chef isn't configured to run automatically out of the Omnibus
installer (which is what you get by default from knife bootstrap now)
because there is more than one way to daemonize chef and different
users have different use cases and preferences.

Some users prefer it just run out of init in its own daemonized mode,
some use cron heavily and thus use cron to schedule chef runs, some
prefer the monitoring capabilities of something like runit. Some folks
prefer to just run chef-client by hand or using knife ssh, some use a
separate orchestration tool. Often, the same people will use two of
these methods for running chef. In the future, there will be more. If
you force Chef to use one of these methods, then using another method
means you have to undo everything that set up the out of box method,
which is messy and unnecessary.

Some users won't want Chef to start immediately on reboot because they
may want to wait for the server to stabilize or may plan to continue
maintenance. Usually we prefer to not configure a particular feature
than force a choice on a user, making them have to use a multiple step
undo recipe just to get back to a clean slate to configure the server
the way they want.

The Omnibus installer installs to /opt/chef because it contains
embedded versions of software like ruby and this is the traditional
location for installing large vendor packages. That you think this
location is weird echoes the first point, there are many ways to do it
and you should be able to change them.

You can find more information on Omnibus here:

Bryan