Security issue in the OpenSSL library (Heartbleed bug)

Posted in Control panel by

As many of you have probably heard a serious security issue (dubbed the “heartbleed bug”) was found in the OpenSSL library yesterday. This is a very serious issue as this library is used to encrypt a large percentage of the Internet’s traffic, including web and email.

The security issue could allow anybody to access parts of the encrypted traffic as well as the secret keys used to encrypt that traffic.

What we have done

As soon as we were made aware of the issue we started updating the OpenSSL version used by our various systems and we replaced the SSL certificates that we were using.

As of now all of our systems have been patched and all of our SSL certificates have been replaced.

What you should do

We are not aware of any data having been compromised but there is a possibility that some may have been so as a precaution we recommend making the following changes:

  1. If you are using SSL certificates for your sites there is a risk that your certificates have been compromised. So we recommend that you ask your certificate provider to re-issue your certificates and then open a ticket for us to replace your certificates with the new ones.
  2. Once you have replaced your SSL certificate, you should consider that the data secured by your old SSL certificates may have been compromised. Change any passwords or other credentials that were encrypted by your old SSL certificates.
  3. We recommend that you change your WebFaction control panel password. Although the WebFaction control panel wasn’t vulnerable (it uses a different version of the OpenSSL library) the SSL certificate that it uses may have been compromised because it was also used by other sites which were vulnerable. So there is a small possibility that some control panel passwords may have been compromised.
  4. If you’re using phpMyAdmin or phpPgAdmin on our servers you should change these passwords.
  5. If you are using our email services we recommend that you change your email passwords.

You can find more information about the heartbleed bug at

If you have any questions regarding this issue just open a support ticket and our team will reply to you asap.


Your WebFaction account: email

Posted in Control panel by

This is the second post in an in-depth series on what’s included with your WebFaction account. In today’s installment, it’s time to take a look at email. Email’s easy to take for granted, but your account includes several email features that ought to make life with email a little easier. Let’s look at the highlights:

  • Sending, receiving, and storing email
    Rather than expecting you to run your own mail server, you can send, receive, and store email using our managed mail servers. Instead of fiddling with configuration files by hand, you can set up accounts and email addresses with the WebFaction control panel.
  • Spam filtering
    We take broad measures to prevent spam from reaching your inbox, like rejecting mail from servers that are misconfigured or known to be operated by spammers. We also run SpamAssassin, an open source tool for detecting spam, to give a spam score to every incoming message. With the control panel you can choose how spam messages are handled: have them immediately discarded, have them put into a spam folder or, for advanced users, have them processed with custom filtering rules.
  • Automatic mail tools
    Aside from spam detection, you can set up other ways to automatically deal with email. You can forward incoming messages to another address, or you can set up autoresponders to let people know when you can’t respond yourself. You can even choose to direct incoming messages to a script to process with your favorite programming language.
  • Many ways to get your mail
    Once you’ve received mail, you have several ways to access it. You can configure your mail client to access mail stored on the server with IMAP, or to download mail with POP. To send mail, you can use SMTP. And if you don’t want to run a dedicated mail client, you can log in to WebFaction’s webmail interface.
  • Unlimited email addresses
    Feel free to set up as many email addresses as you like. You can add addresses with the control panel, and you have the flexibility to have a single mailbox receive messages for multiple addresses. You can also receive as much mail as you like, provided you don’t exceed your account’s disk space limits.

With this set of features, email with WebFaction can be used in a variety of ways. Individuals can set up their favorite email client or use the webmail interface to exchange mail with friends and family or clients and colleagues. Likewise, your web applications can benefit from email communications, like sending welcome email or password reset messages.

We hope this post gives you a better idea of the mail capabilities of your WebFaction account. For more details, check out our mail documentation, and if you have any questions, join us in the Q&A Community.

Previously in the “Your WebFaction account” series: Servers


A look at installing your own tools on WebFaction servers

Posted in Server setup by

In previous posts, we’ve demonstrated how to use software we provide through one-click installers or through your shell account. But sometimes you may want to use something we haven’t installed. Today we’d like to give a better picture of how to do that, and what WebFaction servers already have installed to help you.

Sometimes the software you want to use will be available as a binary or script you can run more or less straight away, without any compilation steps. It’s simply a matter of downloading and running. wget and curl both make it easy to download files, limiting the need to upload with SFTP.

Take ack, a grep alternative, as an example. Downloading and installing ack is a one-liner, provided $HOME/bin is in your PATH:

curl > ~/bin/ack && chmod 0755 !#:3

Much of the software you may want to install may require a more complicated installation process, however. In particular, you may be required to configure, compile, and install as separate steps.

To that end, each WebFaction server comes equipped with many of the common tools you need to do that. In particular, each WebFaction server has make for running the compilation and installation process, C/C++ compilers, and plenty of common prerequisite libraries. Preinstalled libraries include essentials such as readline and libcurl, as well as fancier libraries, like ImageMagick for graphics manipulation (to get a sense of what’s installed, try running ldconfig -p).

System configuration details are a bit dry, however. For a more concrete demonstration, we’ll compile the open source key-value store Redis. In general, the strategy for setting up software in your home directory is:

  1. Get the source.
  2. Configure (if applicable) and build.
  3. Install.

Of course, no two packages are alike, so be sure to read the software’s README file and other documentation. You should also look over the WebFaction Installing Software from Source documentation for some additional guidelines.

In Redis’s case, the process is simple. First, log in to your SSH account, then download the source with this command:


Next, extract the tarball and switch to the source directory with these commands:

tar -xf redis-2.6.11.tar.gz
cd redis-2.6.11

Redis doesn’t require any configuring before building, so the next step is to compile. Enter make and press Enter. It takes a couple of minutes to compile, but when it’s done you’ll have working redis-server and redis-cli executables in the src directory. Before continuing, it’s best to confirm that the compilation finished without any problems. Many packages, including Redis, provide a test suite to confirm the build results. Run the test suite with this command:

make test

The tests take a few minutes to run, but provide confidence that the software will work as expected. Once we’re satisfied it’s ready, then we can install Redis to the home directory. Install with this command:

make PREFIX=$HOME install

Now, the Redis binaries are in your $HOME/bin directory. You can run the server with redis-server and the command-line client with redis-cli. You’re free to store keys and values to your heart’s content.

For a broader example, featuring several different packages and numerous dependencies, check out our post Setting up the reddit app without root access. It contains several more examples of installing software in your home directory.

Let us know what you’re installing in the comments, and if you need any help, join us in the Q&A Community.


A look at version control on our servers

Posted in Git by

Appending version_36 or final_2 to a file name is no way to keep track of different versions of files. Instead, we’re lucky to have a wide variety of version control tools at our disposal. And a webserver is no place to skimp on such things, so today we’re taking a look at version control on WebFaction’s servers.

If you like your version control centralized, with a single, authoritative repository, we’ve got you covered with Subversion. Both the Subversion client and server are available with your WebFaction account. For example, you can check out a working copy of the WordPress trunk with the svn command-line client like this:

$ svn co wp-source

You can also serve a Subversion repository with the one-click installer. You can serve a Subversion repository publicly for open-source projects, or set up users to control access for private projects. Check out the Subversion documentation for more details.

If you like your version control distributed, where each user has a complete “clone” of the repository, then Git is a great choice. Each WebFaction server has the Git client installed, and serving Git repositories on the web is a snap with the one click installer. The client’s handy for grabbing code from GitHub, like the Django repository:

$ git clone

Like Subversion, you can make respositories available on the web with the one-click installer. A single Git application can host mulitple repositories and can be configured for public access or per user access for private projects. See the Git documentation for detailed instructions.

An additional benefit of using a Git or Subversion application is that you can link your repositories to a Trac installation. Trac is a handy, open source project management tool that features a ticket tracker, wiki, and repository browser. For more details about using Trac with your WebFaction account, see our Trac documentation.

Of course, Git and Subversion aren’t your only options. It’s easy to set up other version control tools in your home directory. We have instructions for installing Mercurial and Bazaar clients, as well as publishing Mercurial and Bazaar repositories on the web with hgweb and loggerhead respectively.

So if you haven’t already, give version control a try with your WebFaction account. Let us know what you think in the comments, or if you need any help, join us in the Q&A Community.


World IPv6 Launch day

Posted in Control panel by

As you may have heard today is World IPv6 Launch day. A lot of companies around the world have worked hard to be IPv6-ready by today. The world is running out of IPv4 addresses and the solution is the new IPv6 protocol.

I’m happy to say that IPv6 is now supported throughout our various systems:

  • Our sites and have been available over IPv6 for some time
  • All of our Centos6 servers (web300 and over) and a subset of our Centos5 servers have IPv6 enabled. On these servers various services such as MySql, Postgresql, phpMyAdmin and phpPgAdmin are available over IPv6.
  • Our control panel now lets you specify whether you want a particular site available over IPv4 only, IPv6 only or both:

    IPv4/IPv6 choice
    Note that this option is only available if you’re on an IPv6-enabled server. If you don’t see this option and you want to enable IPv6 for your sites open a support ticket and we’ll enable IPv6 on your server.

  • Our control panel now lets you create custom AAAA DNS records for your domains:

    AAAA record

IPv6 provides 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses so we should be OK for a while…


A Look at Our PHP Setup

Posted in Server setup by

In the tradition of A look at our Python setup, today’s post is all about WebFaction’s PHP setup. While some of our specialized installers get a lot of attention, we know that PHP is an important, if not glamorous, part of many web developers’ toolbox. So let’s take a closer look.

On our servers, PHP 5.2 is the default version. It’s not the newest and shiniest, but it’s hugely popular. For example, on Web310:

$ php --version
PHP 5.2.17 (cli) (built: Jan 17 2012 13:19:44) 
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
    with the ionCube PHP Loader v4.0.10, Copyright (c) 2002-2011, by ionCube
        Ltd., and
    with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies

But we’re not ignoring PHP’s development. PHP 5.3 is also available:

$ php53 --version
PHP 5.3.9 (cli) (built: Jan 16 2012 15:27:59) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with the ionCube PHP Loader v4.0.10, Copyright (c) 2002-2011, by ionCube

We’ve tried to provide a lot of the more popular and useful compilation options. For example, we’ve enabled libcurl support so you can start making HTTP requests, right out of the box:

    $c = curl_init();
    curl_setopt($c, CURLOPT_URL, "");

Here’s a complete list of the our compilation flags on a CentOS 6 (64-bit) server:


You can see all the details on your specific machine’s PHP setup by running php-config.

In case you missed it previously, you should also know that our PHP setup allows you to send email with PHP’s built-in mail() function. There’s no requirement to use an SMTP library to send mail (though you’re welcome to do so, if you prefer). You can send email simply, like so:

    $message = "Just testing sendmailn";
    mail('', 'Help me', $message);

Of course, PHP in isolation isn’t so useful; we can plug it into the web with our corresponding Static/CGI/PHP applications. They’re more flexible than meets the eye. By default, a Static/CGI/PHP application uses a traditional php-cgi deployment method, where each PHP script is loaded and run with each request. It’s simple, effective, and perhaps best of all, doesn’t count toward your account’s memory usage.

But if you’d like to tweak your PHP deployment method, you can choose FastCGI as an alternative. Although it consumes your account’s memory, it has better performance for some applications. To use FastCGI, create a .htaccess file in your Static/PHP/CGI application directory containing this line:

<FilesMatch .php$>
    SetHandler php52-fcgi

You can also replace php52-fcgi with php52-fcgi2, php52-fcgi3, through php52-fcgi6 to control the number of processes FastCGI will use to serve the site.

In addition to .htaccess, you’re free to use your own php.ini file to configure your PHP application. For example, you can use php.ini to set the maximum size of file uploads. See our existing Configuring PHP docs for all the details.

Finally, we have some Static/CGI/PHP-derived installers for popular tools, like WordPress and Drupal. Under the hood, they’re PHP applications through and through, so you can use what you’ve learned here to extend or customize those applications too.

We hope this gives you a better picture of what our PHP setup is capable of and what you can do with your account. If you have any questions, let us know in the comments or join us on the Q&A Community.


Server Name Indication enabled on all servers

Posted in Server setup by

A few weeks ago we enabled Server Name Indication (SNI) on all of our servers.

SNI allows you to use an SSL certificate for your secure site (https) without having to buy a dedicated IP address.

It works by having the browser send the hostname as part of the initial handshake so the webserver knows which certificate to use even if multiple certificates are used on the same IP address.

Note however that while SNI is supported by most modern browser some older browsers (notably all versions of Internet Explorer on Windows XP) don’t support it. If you choose to use SNI and someone visits your secure site with a browser that doesn’t support SNI they will receive our default certificate and their browser will display a certificate-mismatch warning.


Fair shared hosting

Posted in Server setup by

Traditional shared hosting has always suffered from the “bad neighbor problem”: your site runs fine until another user on the machine decides to encode 20 video files and all of the sudden your site is very sluggish.

That problem is now history on our centos6 servers thanks to a relatively unknown feature recently added to the linux kernel: cgroups.

cgroups allow admins to define various groups and various rules for which processes should go into which groups. Each group can then be allocated various resources or resource priorities relative to other groups.

Here is how cgroups get rid of the traditional “bad neighbor problem” in shared hosting:


  • Imagine a CPU-intensive script called “cpu-eater”
  • Imagine that user A runs 3 instances of the script (process 1, 2 and 3) and users B and C each run one instance of that script (process 4 and 5)
  • Without cgroups each of these 5 processes gets allocated the same amount of CPU (20% each if all the CPU power is available) which means that user A gets 60% in total and user B and C get 20% each. User A is being a bad neighbor and that’s not fair to users B and C.
  • With cgroups we can configure it so that each user gets their own cgroup and all of a user’s processes go in that user’s cgroup. We then configure it so that all cgroups have the same CPU priority. This means that users A, B and C each get 33.3% of the CPU to run their “cpu-eater” scripts which is fair.

Note that cgroups keep all the CPU power available to processes who want it: if there are only two CPU-intensive processes on the machine they’ll get 50% CPU each. If there is only one CPU-intensive process on the machine it’ll get 100% CPU.

Also, this example mentions CPU usage but cgroups can do the same for disk IOs and network IOs.

We’ve been running cgroups on all of our Centos6 servers for a few months and we’ve seen great results! No longer can a single user affect all other users on the machine.


New server setup: Centos-6-64bit, MySql-5.5 and Postgresql-9.1

Posted in Server setup by

A few weeks ago we quietly started using a new setup for our new servers based on Centos-6-64bit. Apart from the new Centos version and the new architecture the main difference is that they run the latest MySql and Postgresql versions: MySql-5.5 and Postgresql-9.1.

If you would like to migrate your account to a Centos-6 server you can do so by going to “Account -> Server migration” in the control panel. There you will have the option to either migrate the data yourself (see this page for the procedure) or ask us to do it for you.

Regardless of the migration method that you choose be aware that in many cases you will need to tweak your apps in order for them to work on Centos-6-64bit:

  • Apps that use only a scripting language such as pure-PHP apps (WordPress/Drupal/etc.), pure Python apps, pure Ruby apps etc. usually work without any modification.
  • Anything that is compiled will most likely need to be re-compiled or replaced with Centos-6/64bit versions of the binaries. For instance Django apps will need to have the Apache binary and its modules replaced. See this page for details on how to migrate Django, Rails and Trac apps.

A little holiday present: 10,000 reqs/sec with Nginx!

Posted in Server setup by

Updated Dec 19 at 05:15 CDT (first posted Dec 18 at 06:01 CDT) by Remi

A few weeks ago we quietly started to configure our new machines with Nginx as the front web server instead of Apache (we still run Apache behind Nginx for people who need all the features from Apache).

Here is a little benchmark that I did to compare Nginx versus Apache (with the worker-MPM) for serving a small static file:

nginx vs Apache requests per second

This benchmark is not representative of a real-world application because in my benchmark the web servers were only serving a small static file from localhost (in real life your files would get served to remote machines and some of your requests would be dynamic) but the results are impressive nonetheless. Both servers are capable of serving a huge number of requests per second, but Apache’s performance start decreasing as you add more concurrent connections whereas Nginx’s performance almost doesn’t drop!

But here comes the best bit: because Nginx is event-based it doesn’t need to spawn new processes or threads for each request, so its memory usage is very low. Throughout my benchmark it just sat at 2.5MB of memory while Apache was using a lot more:

nginx vs Apache memory usage

To take advantage of the lightning speed of Nginx we have added two new types of applications to our control panel: the “static only” app and the“symlink to static-only” app. They just work like a normal “static/cgi/php” and “symlink to static/cgi/php” app, except that they can only serve purely static content (no .htaccess support) and they are served directly by the front Nginx server.

Even if your site is not static you can still serve all your static data (CSS, javascript, images, …) directly from Nginx and enjoy the speed gain.

Nginx is only available on Web57 and over. If you’re on an older server and would like to use Nginx open a ticket and we’ll give you an extra plan on a new Nginx server and a free week to transfer your data.

Nginx FTW!

[Updated December 19th, 2008 to clarify the fact that we still run Apache behind Nginx for people who need all the Apache features]