Earlier in this chapter, you were briefly introduced to the chef-solo tool. You saw how it can be used to manage your local server using on-disk recipes and configuration data. The Chef team has leveraged this ability to do just that with the Chef server using chef-solo to bootstrap the server configuration. If you were to look at the code for the /opt/chef-server/bin/chef-server-ctl script, you would see that the last line in the script executes the following command:

/opt/chef-server/embedded/bin/omnibus-ctl chef-server /opt/chef-server/embedded/service/omnibus-ctl $@

If you follow the trail and dig into the omnibus-ctl script, you will find that it is just a wrapper around the omnibus-ctl Ruby gem. Digging into the omnibus-ctl gem, you will see that in the end, the reconfigure command you pass on the command line is a Ruby method that makes the following call:

run_command("chef-solo -c #{base_path}/embedded/cookbooks/solo.rb -j #{base_path}/embedded/cookbooks/dna.json")

This tells us that the Chef omnibus package uses chef-solo to configure itself—a pretty clever trick indeed! You can see just how powerful a tool chef-solo can be, being able to configure and reconfigure the Chef service.

What you will probably notice right away is that a lot of text is being scrolled past in your terminal window. If you were to look at the contents, you would see that it shows you the actions that are being taken by chef-solo to provision your new services. As there is a lot of information going past (thousands of lines), here is a high-level overview of what is happening on your host:

Clearly, there is a lot happening here; if you have any outstanding concerns about what is being done, be sure to read through the output. One of the great things about Chef is that the recipes are just a set of scripts that you can open and view the contents of, and the output shows you what is happening during the execution. Everything it does is transparent and manageable by you.

Once the configuration of your services is complete, you will want to validate that the required services are running. Again, the chef-server-ctl script will be used, but we will invoke the status subcommand instead of the reconfigure subcommand, as shown in the following code:

user@host:~ $ sudo chef-server-ctl status
run: bookshelf: (pid 3901) 3123s; run: log: (pid 3900) 3123s
run: chef-expander: (pid 3861) 3129s; run: log: (pid 3860) 3129s
run: chef-server-webui: (pid 4053) 3095s; run: log: (pid 4052) 3095s
run: chef-solr: (pid 3819) 3135s; run: log: (pid 3818) 3135s
run: erchef: (pid 4230) 3062s; run: log: (pid 3937) 3117s
run: nginx: (pid 4214) 3064s; run: log: (pid 4213) 3064s
run: postgresql: (pid 3729) 3146s; run: log: (pid 3728) 3146s
run: rabbitmq: (pid 3423) 3172s; run: log: (pid 3422) 3172s

The status subcommand will show you the process ID of each component, how long it has been running for, the PID of the logging process associated with that service, and how long the logging service has been running. For example, we can see that chef-server-webui has a PID of 4053 and has been running for close to an hour, and the logger has a PID of 4052, having been running for just as long as the service.

As you can see, the installation of Chef yields a number of components that will need to be up and running in order to successfully use Chef. You should have the following components running and listening on the following network ports:

Public components need to be made available to any clients, nodes, or end users that expect to use the Chef service over the network. Configuring your infrastructure to ensure that your services are available via the network is outside of the scope of this book as there are a near-infinite number of possible network configurations.

At a higher level, make sure that any firewall devices or packet-filtering systems are not preventing traffic from reaching these services if you see that they are running, but are having difficulties in connecting to them. If any of these services are not running, you will need to consult the logfiles generated by the service to determine what might be preventing them from starting up.