Follow-up: use ondemand PHP-FPM masters using systemd

A few days ago, I published a blogpost called A better way to run PHP-FPM. It's gotten a fair amount of attention. It detailed the use of the "ondemand" process manager as well as using a separate PHP-FPM master per pool, for a unique APC cache.

The setup works fine, but has the downside that you'll have multiple masters running -- an obvious consequence. Kim Ausloos created a solution for this by using systemd's socket activation. This means PHP-FPM masters are only started when needed and no longer stay active on the system when obsolete.

This has a few benefits and possible downsides;

  • Pro: masters are only spawned when needed, meaning less memory consumed overall
  • Pro: masters are also killed when they're obsolete, so a perfect ondemand scenario
  • Min: no longer able to restart a PHP-FPM pool when needed (to load new .INI settings), all pools would restart?
  • Min: APC cache will be destroyed whenever a PHP-FPM master is killed (which may not be a bad thing, for low-traffic sites)

I'll do some more testing on this use-case, as well as the performance penalty (if any) of having to start new master on a first request to the PHP-FPM socket. For this to work out, RHEL or CentOS 7 is needed in my case (we're a RHEL/CentOS shop), as systemd is required and will only be supported from RHEL/CentOS 7.

Tagged with: ,
Posted in php

Varnish 4.0.0 released together with configuration templates

Good news! Today, Varnish 4.0.0 has been released!. Among the most important features are;

* Full support for streaming objects through from the backend on a cache miss.
Bytes will be sent to 1..n requesting clients as they come in from the backend
* Background (re)fetch of expired objects. On a cache miss where a stale copy
is available, serve the client the stale copy while fetching an updated copy
from the backend in the background.
* New varnishlog query language, allowing automatic grouping of requests when
debugging ESI or a failed backend request. (among much more)
* Comprehensive request timestamp and byte counters.
* Security improvements, including disabling of run-time changes to security
sensitive parameters.

Together with this release, I'm making public the first draft of Varnish 4.0 configuration templates on Github. Since the syntax and internals have changed quite a bit, this is a Work-in-Progress.

My config templates for Varnish 3.x have received a great deal of feedback and attention, I'm hoping to accomplish the same with these 4.x configs. They're still in draft and need finetuning, so I appreciate any feedback!

Tagged with:
Posted in Varnish

Scan your network for Heartbleed vulnerabilities with Nmap

Nmap now has an NSE script (Nmap Scripting Engine) to detect SSL Heartbleed vulnerabilities. You can find how to patch yourself in my previous blogpost: Patch against the heartbleed OpenSSL bug (CVE-2014-0160). Read more ›

Tagged with:
Posted in Security

A better way to run PHP-FPM

If you search the web for PHP-FPM configurations, you'll find many of the same configurations popping up. They nearly all use the 'dynamic' process manager and all assume you will have one master process for running PHP-FPM configurations. While there's nothing technically wrong with that, there is a better way to run PHP-FPM.

In this blogpost I'll detail;

  1. Why 'dynamic' should not be your default process manager
  2. Why it's better to have multiple PHP-FPM masters

Read more ›

Posted in php

Patch against the heartbleed OpenSSL bug (CVE-2014-0160)

A very unfortunate and dangerous bug has been discovered in OpenSSL that allows an attacker to read otherwise sensitive information hidden by the encryption of OpenSSL. In some cases, it allows an attacker to retrieve the private key of certificates. The vulnerability is known as CVE-2014-0160

The bug has been fully disclosed on the site Unfortunately, someone went through a lot of trouble getting massive publicity for this bug/vulnerability but did not notify the OpenSSL project first. So the vulnerability is now public, but the software may not already be patched.

How do you protect yourself? Update OpenSSL!

Most distros already have a patched version of OpenSSL included. In the case of CentOS, a workaround has been created by removing the vulnerable pieces of code from OpenSSL. A full patch is expected in the next few days.

Red Hat / CentOS / fedora

$ yum update openssl

Debian / Ubuntu

$ apt-get update
$ apt-get install openssl

Restart services that rely on OpenSSL

You can find all the services on your system by running the following command as root. It lists all services that rely on libssl.

$ lsof | grep libssl | awk '{print $1}' | sort | uniq

After the update of OpenSSL, every one of those services needs to be restarted.

Consider re-issuing your certificates

Since this vulnerability allowed an attacker to possibly get your private keys (without leaving a trace in your logs), you should consider replacing all your certificates. This of course comes down to money; a re-issue will cost you some $$.

If you're not running a high-profile website over SSL, I would assume you're probably safe. If you're dealing with millions of dollars in transactions every day and SSL is one of the ways to protect your clients, then yes -- consider issuing all new certificates and consider the current private keys as compromised.

How do you know if you're vulnerable?

There are a few tools to help you test if you're vulnerable. For now (April 8th, 2014), it's safe to assume that if you're running SSH, SSL certificates, or anything else involved with encryption, you're vulnerable until you update your OpenSSL version.

You can use the tools below to test if you are actually vulnerable.

  1. Heartbleed Test: a website that allows you enter any (publicly available) URL and test for the exploit (alternative site is
  2. Heartbleeder: a script written in Go to test the vulnerability.
  3. a python script to test this vulnerability. (github mirror here)

I'd be happy to hear for other alternatives to protect yourself.

Tagged with: ,
Posted in Security