Change Chef Server settings after installation

Just about every significant aspect of Chef Server is configurable, although the defaults are okay for most.  The configuration options are documented at .

Note, though, that the chef-server.rb described in the article was nowhere to be found on my server.  Instead, after some digging, I found what I needed at  /opt/chef-server/embedded/cookbooks/chef-server/attributes/default.rb .

So, for example, if you want to change nginx’s HTTPS port from 443 to 4443, you’d simply set default['chef_server']['nginx']['ssl_port'] = 4443.

Update:  after a bit more digging, I found that a) updating your Chef server will undo all of these changes, and b) that there is a better way.

Simply create the file /etc/chef-server/chef-server.rb and use the attributes from .  Going with our example above, to change the nginx SSL port, simply insert  nginx['ssl_port'] = 4443 .

After making all of the changes you need, you’ll have to apply the configuration (which does a chef-solo behind the scenes) with:

You’ll see a diff of all the changes that avalanched out to during the Chef run.

And that’s it.  Hopefully that’ll help you accomplish what you’re looking for.


Use nginx as a reverse proxy to speed up your WordPress site

Everyone loves speed.  That includes your site’s visitors.  If you run a WordPress site, WP Super Cache is a pretty cool plugin that generates static files from your dynamic content, and serves those to your users instead of dynamically generating the same page for each user, which can really put your database to work.

If your current WordPress installation runs on Apache, and you want to give it an easy dose of speed, there’s a solution for you.  nginx is a very lightweight and performant webserver that not only serves static files fast, but it caches, too.  We can put both of those features to use to make your site faster than ever.

First, download and install WP Super Cache.  Next, you’ll need to install nginx (I use the official nginx repos, but any recent build should be good).  Don’t start it yet.  Take the config file below, and adjust it to your needs (mainly the section at the top).  Pop it into the nginx conf.d directory as (adjust the name, of course).  Next, adjust your Apache config’s Listen directive to listen on port 8080.  In your virtualhost config for your site (which you can find with apachectl -S), update the port from 80 to 8080.

Now, do the following:

The above will test the nginx and Apache configs (apachectl will do a configtest before a restart), and start nginx if all is well.

In case the nginx config wasn’t clear, it will serve the static pages created by WP Super Cache directly from the filesystem if they exist.  Otherwise, the request will be proxied to Apache, where the page will be generated (and in most cases, WP Super Cache will create a static file for it) and returned to nginx.  nginx will cache that request for 15 minutes.  If a user requests the same page again, if WP Super Cache indeed cached that page, it’ll be served from the filesystem, otherwise nginx will serve it from its cache (if it’s within the 15 minute window), or it’ll proxy it back to Apache.

Users who are logged in or who have left comments will not be served any cached data.  This is determined via a cookie check.  So, if an anonymous user has a blazing user experience, then comments on a post, he/she can suffer with slower speeds until the comment cookie expires (typically 5-30 minutes) since each request will be proxied to Apache for processing.  Just something to keep in mind.

If you try this, let me know how it goes!

Update your Ubuntu/Debian servers with Chef

If you need a hands-off way to update your Ubuntu or Debian servers, Chef’s Knife utility provides an easy way to do this (and parallelize it!).

The following will update your packages in an unattended way.  In other words, all prompts will be suppressed, and defaults will be accepted (e.g. if a new file is delivered with a package, yours will be kept).  You can look at the dpkg –force-conf* flags to change this behavior.  The -C flag denotes the number of parallel processes.

If you don’t want to update all of your servers, update the search command to be more precise.


Using autofs with a NAS in Chef

autofs isn’t so bad, but when it’s been a while, it can make you pull your hair out.  Been there, done that.  Now here’s the result of that for you to benefit from.  This Chef recipe simply installs autofs and its dependencies, and sets up a mountpoint called /media that’s managed through autofs.  The recipe is certainly meant to be updated; this is just a general template.  The NAS hostname/export below are hardcoded, but can be defined via attribute.

Note that this will overwrite /etc/auto.master, so if you already have something important in there, you should factor that into the cookbook as well and update accordingly.

Note that this was written for and tested on CentOS 6.  You will need to update it accordingly for your distro.


Installing Chef Server in an OpenVZ Container

I love OpenVZ, but I was unfortunately never able to successfully install Chef Server in a container; I’ve always had to try it out on KVM or Xen instead. The culprit was the procps package, which refused to install as a dependency.

After looking into it, it turns out that a sysctl setting conflicted with procps, causing that error. OpenVZ doesn’t even use sysctl (or any other kernel-level settings) since it’s effectively a chroot, and inherits all settings from the host.

The solution, found here, was to delete the following (Ubuntu 12.04 here):

This corresponds to the setting  kernel.kptr_restrict = 1 .  On other distros, simply grep out that setting in sysctl.conf or sysctl.d, and remove it.

Once that’s done, you should be good to go with the install.

On Ubuntu 12.04, using the traditional OpenVZ templates, I do:

That’s all, folks!

Use X-Forwarded-For in Apache when behind a proxy

I love Apache. I love nginx. I love them when they’re alone, and I love them when they’re together. But when they’re together, sometimes they don’t play nice.

When behind a proxy, Apache will use the proxy’s IP address in logs and everywhere else. Unless your application knows to look for X-Forwarded-For, every single one of your visitors will have your proxy’s IP. Helpful, huh?

Thankfully, there’s a module that’ll help you get around this, called mod_rpaf (reverse proxy add forward).

The Github page has some info on how to install it, but I couldn’t get that to work on Ubuntu 12.04. Here’s what worked instead:

You should start seeing some real IPs now!

Specify multiple redundant Vagrant box URLs

Vagrant is awesome, but there are times where you might need to specify redundant/alternative URLs in a Vagrantfile.  This could be a failover type scenario, although in my case, I needed it to give external developers access to our Vagrantbox, which we made a copy of on the interwebs.  The below goes in the Vagrantfile, and does an HTTP HEAD request to see if the Vagrant box is available.  If so, it uses it; otherwise, it’ll default to the public Vagrant box.

I hope that helps!

Install bbcp on Ubuntu

bbcp is becoming a hot contender to rsync.  Unfortunately, it’s not available by default in Ubuntu 12.04.  The steps below will get you going with it.  Note that bbcp needs to be installed at both ends of a transfer.


Chef — knife super quick start

In this post, I will show you how to get started with the open-source version of Chef using knife.


  • A working Chef server
  • An admin account on the Chef server
  • A supported version of Linux (this might work on OS X too, but I haven’t tested it)

We’ll start off by installing the Chef client on your management workstation:

Assuming all went well, we now have the knife command at our disposal.

We now have to point knife at our Chef server.  Most documentation will tell you to copy /etc/chef-server/chef-validator.pem from your Chef server, and let knife send that over to nodes upon bootstrapping.  While this works well, I much prefer to have each user use his/her own validation key.  Our Chef server is shared, and it makes a lot of sense for us this way.

To create an administrative client:

  • Login to Chef server
  • Click on ‘Clients’
  • Click on ‘Create’
  • Type in a unique name for the client and check the ‘Admin’ checkbox
  • Click on ‘Create Client’ and save the private key on the next page as ~/.chef/validator.pem

If you do not have your user private key, you’ll need to go to Users-><your username>->Regenerate Private Key->Save User and save that key to ~/.chef/user.pem.

Now, we can go ahead with our knife setup.  On your workstation, run the following:

You’ll be asked a series of questions, as shown below:

You should now be able to use knife.

You can test by doing knife client list.  This will perform an API call to the Chef server, and use your Chef user private key for authentication.  You should see at least your computer listed, if you followed the instructions as-is.

The next step would be to bootstrap a node.  This can be done by doing:

That’s it!

Installing SRS extensions on Postfix (Ubuntu/Debian)

Note:  This post is heavily based on this article.

Install needed dependencies:

Install libsrs:

Install pfix-srsd:

Update libraries:

Create secrets:

Save to /etc/default/pfix-srsd:

Save to /etc/init.d/pfix-srsd:

Enter addresses that you need to be excluded from SRS:

Add SRS settings to Postfix:

Install pfix-srsd init script:

Apply new changes: