Enable XHProf for WordPress

 

cd into wp-content/plugins

In wp-config.php:

In your admin dashboard, enable “WP XHProf Profiler” from the plugins section.

You will have “Profiler output” links at the very bottom of your page that’ll show you XHProf output.

Posted in Tech Corner

Migrating from one Chef server to another

It happens — you’re on a server that just can’t be upgraded any further, and you need more resources.  Or, you need to backup a Chef server.  Or, you need to setup a QA instance.  Or, you need to finally migrate from Chef 10 to Chef 11.  Or, you have one of many other possible reasons, but you need to be able to stand up a new Chef instance, and not have to do a ton of work.  If any of that applies to you, then this post is for you.

In the case where you’re migrating from one Chef server to another (i.e., the old one is going bye-bye), it would be very helpful to have your Chef server be CNAMEd (e.g. chef.company.com -> vm101.iad.company.com) or behind a load balancer/proxy where you can change targets easily.  That way, you won’t need to update the client configs, and it’ll be an easy swap.  Everything should “just work” ™.

First, we’ll make a copy of your knife.rb:

Now, we’ll need to get access to your new Chef server via knife.  You can do so by logging in as admin, and regenerating and saving a new private key.  You can also create a new user here instead of using admin, but I advise against this, as any user you create will conflict with users of the same name from the old server.  Yes, that means that if you’ve been using ‘admin’ as the main user, you may run into problems (but let’s just hope that you’ve been using per-person accounts).

Now, we’ll update your current knife.rb to reflect the new node information in it:

It wouldn’t hurt to check that you have access to the new node by doing a  knife user list .

Now, we’ll need to download all of the data from the “old” Chef server.  To do so, we’ll be using the nifty ‘knife backup‘ plugin.  To get it installed on OS X, I did:

Now, to finally back things up, we’ll do:

Note that the argument after -D is the destination directory where all of the Chef data will go; this directory will automatically be created for you.  The argument of -c tells knife which config file to use; we’ll, of course, be using the “old” server here.  Also, if you only need to backup a certain set of data from your Chef server (e.g. only users and environments), you can specify that.  See the knife backup documentation for details.

Now that we have all the data we need, we’ll need to push it up to the new server.  This works much the same as the export:

I left off the -c here because knife.rb is the default config file.

Once everything has been restored, your original user in Chef will now be available (you can verify this via the Chef Server UI).  The amazing thing is that your keys have not changed, and can be used as-is.  Chef Server keeps track of your public keys, so all of your private keys for all nodes/clients are still good.

This, now, is where you update your knife.rb to reflect your original user settings.  If you’re running behind a load balancer/proxy, you can simply use your original config as-is after replacing the old server with the new one.  If you’re doing the CNAME/A record route, you can do the same once DNS has propagated.  Otherwise, you can overwrite your new config with your old one, and edit it to reflect the new server’s URL.

If your nodes are pointing to the wrong server in their client.rb, you can use knife ssh with sed to find/replace the server URLs.

If you’ll be accessing multiple Chef servers frequently enough, I highly recommend looking at the knife block plugin.  That way, you can switch between different configurations with ease, including those for Berkshelf.

Posted in Linux Luvin'

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 http://docs.opscode.com/config_rb_chef_server_optional_settings.html .

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 http://docs.opscode.com/config_rb_chef_server_optional_settings.html .  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.

 

Posted in Linux Luvin'

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 mysite.com (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!

Posted in Linux Luvin'

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.

 

Posted in Linux Luvin'

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.

 

Posted in Linux Luvin'

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):
/etc/sysctl.d/10-kernel-hardening.conf

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!

Posted in Linux Luvin'

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!

Posted in Tech Corner

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!

Posted in Tech Corner

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.

 

Posted in Linux Luvin'