You're a sysadmin. You love the CLI. You use PHP. Surely, you should be able to troubleshoot PHP applications that are normally run via an HTTP server through the CLI as well, right? Well good news; you can -- with a few caveats. This is in follow-up of a blogpost I made in 2012 titled "Running php-cgi scripts via the CLI as a webserver would (by faking them)". If you can run your PHP applications via the CLI, you can use tools such as strace to debug the PHP app's behaviour.
TL;DR: you can fake pretty much any HTTP request by setting the correct environment variables before you call the PHP binary.
Read more ›
Tagged with: php cli debug strace
Posted in php
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: php
Posted in php
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
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: varnish
Posted in Varnish
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: openssl nmap
Posted in Security
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;
- Why 'dynamic' should not be your default process manager
- Why it's better to have multiple PHP-FPM masters
Read more ›