The Life and Times of Michael Shadle

I'm a sucker for a free t-shirt. This year was a record - 11 shirts from OSCON 2012, and I missed going to the OpenStack anniversary event where I could have picked up another one. The one disappointment about all of this though is probably half of these shirts are unusable - they're either so thin they couldn't even make "undershirt" status, or such an odd fit (too skinny and long, or too wide and too short.)

So I plead with you, companies, please invest just that little bit more to get higher quality stock. It can't be that much more, and you'll have a greater chance that people will wear those shirts sporting your logo, and not because they picked it up at the local Goodwill. 🙂

On another note, I apologize for not posting anything in almost seven months. I've been busy and haven't felt like wordsmithing anything I've been up to, or otherwise haven't had anything useful to share.

I'm always excited to read updates to the NEWS file for each PHP version (yes, I am that big of a PHP fan boy) - and PHP 5.4 has quite a handful of noteworthy changes. I started cutting them out and decided to publish my "this is interesting" or "this is awesome" list...

This is as of PHP 5.4.0 RC6. Note that I didn't put in anything related to OO, as I despise the obsession with OO now in PHP and do my best to live without it.

Misc. notable changes:

• Added built-in web server that is intended for testing purpose. (Moriyoshi)
• Changed default value of "default_charset" php.ini option from ISO-8859-1 to UTF-8. (Rasmus)
• Added array dereferencing support. (Felipe)
• Added header_register_callback() which is invoked immediately prior to the sending of headers and after default headers have been added. (Scott)
• Changed http_response_code() to be able to set a response code. (Kalle)
• Added new json_encode() option JSON_PRETTY_PRINT. FR #44331. (Adam)
• Changed silent conversion of array to string to produce a notice. (Patrick)
• Removed support for putenv("TZ=..") for setting the timezone. (Derick)
• Removed the timezone guessing algorithm in case the timezone isn't set with date.timezone or date_default_timezone_set(). Instead of a guessed timezone, "UTC" is now used instead. (Derick)
• ext/mysql, mysqli and pdo_mysql now use mysqlnd by default. (Johannes) )I think this is in 5.3 though too?)
• Expose session status via new function, session_status (FR #52982) (Arpad)
• Added support for storing upload progress feedback in session data. (Arnaud)

PHP-FPM related:

• Remove EXPERIMENTAL flag. (fat)
• Added partial syslog support (on error_log only). FR #52052. (fat)
• Lowered default value for Process Manager. FR #54098. (fat)
• Enhance security by limiting access to user defined extensions. FR #55181. (fat)
• Added process.max to control the number of process FPM can fork. FR #55166. (fat)
• Dropped restriction of not setting the same value multiple times, the last one holds. (giovanni at giacobbi dot net, fat)

Removed legacy features:

• Safe mode and all related ini options. (Kalle)
• register_globals and register_long_arrays ini options. (Kalle)
• import_request_variables(). (Kalle)
• allow_call_time_pass_reference. (Pierrick)
• Session bug compatibility mode (session.bug_compat_42 and session.bug_compat_warn ini options). (Kalle)
• session_is_registered(), session_register() and session_unregister() functions. (Kalle)
• y2k_compliance ini option. (Kalle)
• Removed magic_quotes_gpc, magic_quotes_runtime and magic_quotes_sybase ini options. get_magic_quotes_gpc, get_magic_quotes_runtime are kept but always return false, set_magic_quotes_runtime raises an E_CORE_ERROR. (Pierrick, Pierre)

Something just cropped up today on HN about a "reboot of PHP" - being a PHP fanboy, I decided to go look. I've had my own ideas on what I'd change (or rather, just clean up, optimize, and purge) from PHP.

The project is here: https://code.google.com/p/phpreboot/

Why is this an issue? Well, for one, it's NOT A REBOOT OF PHP. It's a frickin' Java-based re-implementation of some PHP ideas and function names with a completely different syntax, and at the end of the day, it has 99.9% nothing in common with PHP.

Why do people develop in PHP? Because it is PHP. Stop trying to make PHP more like Java, more JSON-y, etc. Why did it become the world's most popular language? Besides for being easy to pick up (too easy, sometimes, which leads to a bunch of garbage and unsecure code), it got there because of what it is.

This "php.reboot" project is just trying to use PHP's popularity and function names to get people to check it out. PHP doesn't have XML/JSON/SQL style constructs (although the new array syntax sure does look like an attempt to emulate JSON, cough), it has structure - that's what "$" and ";" are for - denoting specific constructs in the language. If people don't want to develop using "$" or ";" go switch to another language that doesn't, that is already established.

I am tired of seeing blog posts and other items pop up every so often "why PHP wants to be more like Java" or "10 things PHP can learn from Ruby" - if you're trying to adapt PHP to another language, just use the other language. Period.

Some of the ideas in this project might be neat, or good; but in the end, it's not a "reboot of PHP" and stop labeling it as one.

Today, Igor announced that he is establishing a company behind nginx, citing that he and some others are going to be focusing more seriously on development, support, etc. This is exciting, as it proves how serious the project has become. For a long time, nginx has been regularly updated, and support has been typically very reliable, but at the end of the day, the internals of nginx development and features and such have largely been a mystery. It sounds like now we'll all benefit from increased transparency and much more focus on the end-users and support for developers in a more structured and formal way.

I, for one, am excited to see things like a roadmap and making it easier for contributors to help out.

Read Igor's post here.

nginx, my webserver du joir, announced its 1.0.0 launch today. Along with the announcement, Igor has also posted a public SVN repository to grab the code from (which seems to include a lot of historical versions, if not the whole thing!)

He hasn't setup a web-based SVN option yet (cough, cough, I bet it would be if nginx supported SVN's DAV needs :)) - but you can hit it up using a native SVN client: svn://svn.nginx.org - note, I would only grab "/nginx/trunk" as otherwise you'll get a few years worth of code, if not the entire nine years.

At first I thought this was a joke, seeing the announcement for 1.0.0 - sounds like it just started. But one must remember, he's always used pre-1.0 for past versions.

Update:

MTecknology maintains a PPA and has already built a package for 1.0.0. The quick and dirty method to update:

apt-get install python-software-properties
add-apt-repository ppa:nginx/stable
apt-get update

This will provide you a handful of new packages, by default the "nginx" package is a dummy package that will provide "nginx-full" and should be the only one you really need to care about.

nginx-dbg - Debugging symbols for nginx
nginx - small, but very powerful and efficient web server and mail proxy
nginx-common - small, but very powerful and efficient web server (common files)
nginx-doc - small, but very powerful and efficient web server (documentation)
nginx-extras - nginx web server with full set of core modules and extras
nginx-extras-dbg - Debugging symbols for nginx (extras)
nginx-full - nginx web server with full set of core modules
nginx-full-dbg - Debugging symbols for nginx (full)
nginx-light - nginx web server with minimal set of core modules
nginx-light-dbg - Debugging symbols for nginx (light)

I was moving a customer's site from an old HTML and individual PHP page site to a friendly URL site managed by Drupal, and I only cared about intercepting URLs with those file extensions. I installed Global Redirect on a Drupal 6.x site, and the entire site started going into an infinite redirect, before I even had time to configure it. I had to use Drush to disable the module, and immediately uninstalled Global Redirect since I didn't have time to debug what was going on, and hacked this up.

I didn't really need this to do much. The code is simple and there is no UI to manage it, but it works, and even gives you cute little X-Redirect headers to let you know if it was executed and if it found a match. It would be easy enough to take that if() out and have it check any URL (just be sure to remove the fallback :))

function foo_init() {
    if(stristr($_SERVER['REQUEST_URI'], '.php') || stristr($_SERVER['REQUEST_URI'], '.htm')) {
        $old = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
        $new = db_result(db_query("SELECT new_url FROM custom_redirect WHERE old_url = '%s'", $old));
        if($new) {
            watchdog('foo', $old.' found in the custom_redirect table', NULL, WATCHDOG_INFO);
            header('X-Redirect: Found');
            drupal_goto('http://'.$_SERVER['HTTP_HOST'].$new, '', '', 301);
        } else {
            watchdog('foo', $old.' NOT found in the custom_redirect table', NULL, WATCHDOG_ERROR);
            header('X-Redirect: Not Found');
            drupal_goto('http://'.$_SERVER['HTTP_HOST'].'/', '', '', 302);
        }
    }
}

The table?

CREATE TABLE custom_redirect (
  old_url varchar(150) NOT NULL,
  new_url varchar(150) NOT NULL,
  PRIMARY KEY (old_url)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Enjoy. Totally could have Drupal'ed that up and made a hook_install() for the schema too, right? :p

I want to share this with the world, as it may have been helpful up front for me. I had to move a database that is 13gb on the filesystem (not including the shared ibdata file) - the database is a mixture of MyISAM and InnoDB tables. That's not an extremely large or complex database, however, when I ran the export script, it only took a couple minutes. Great, I figured import would take longer, but not as long as it actually was originally.

I didn't do the math, but it would have probably taken over 10-15 hours to restore the database from the mysqldump. There's a couple easy tweaks I did not use. For one, I used --skip-opt and made my mysqldump files full INSERT statements (for verbosity and the ability to "diff" them if I ever needed to) - this was stolen from a backup script I wrote.

If you read the documentation/blogs, it says to use --opt when running mysqldump for faster imports. Well, duh! While I was at it, I also tweaked a couple other things. Right now it is moving MUCH faster. What did I do?

• On the source, I used mysqldump --opt (it seemed to dump the database faster too)
• On the destination, I set innodb_flush_log_at_trx_commit to "0" in my.cnf for the time being. This server isn't used yet, so that's safe.
• I also put "SET AUTOCOMMIT=0;" at the top of the script, and "COMMIT;" at the bottom of the script. I don't need any commits until the end, this is a fresh import.

The results are not very scientific, but here's how it breaks down so far (still in the middle of the process)

• Without these tweaks, at 107 minutes it was only at 2.2gb out of 13gb.
• Without these tweaks, at 12 minutes it was at 4.5gb out of 13gb.

I think this will save my bacon, I wish I had done this sooner and not wasted that two hours originally. Someone in #mysql recommended I look at XtraBackup, but it seemed like too much to learn and attempt my first run at it while I was having to do a  production migration.

A little known feature in PHP-FPM 5.3.3+ (since it was integrated into PHP core) is that you can actually define PHP INI parameters inside of your nginx configuration. This bridges some of the desire to have "php_value" and "php_admin_value" from Apache available. It's not user-override-able, but things like htscanner or newer PHP 5.3 features could address some of that.

This is cool, and I wasn't sure it actually got in a build or not, I remember it was mentioned or discussed, but sure enough, Jérôme coded it and got it in to FPM in core. So it is available to all, and he welcomes the feedback - see this thread on the nginx mailing list.

Due to limitations in the FastCGI protocol, you have to pass all the parameters you want as a single string, separated by "\n" - it's not the cleanest looking configuration, but that's how it is for now. I spitballed a different approach to it, but at the moment I believe it will be unlikely to get adopted.

If you're like me, you're probably looking for the code samples almost immediately. Here's your examples. Note that PHP_VALUE and PHP_ADMIN_VALUE are both legitimate keys, the difference being that PHP_ADMIN_VALUE does not allow the user to override the value using ini_set() - see the manual for more infomation.

Single value:

fastcgi_param PHP_VALUE [email protected];

Multiple values, manually line-broken:

fastcgi_param PHP_VALUE "[email protected]
precision=42";

Multiple values, with the \n in there to clearly call it out:

fastcgi_param PHP_VALUE "[email protected] \n precision=42";

More information is available in the feature request on the PHP bug tracker.

It was weird to see a company nowadays still have your password stored somewhere plaintext.

I've been a fan of Backblaze for a long time, and prefer it and recommend it over Mozy time and time again. Mozy was the golden child for a bit, but now the prize goes to Backblaze, with its more efficient backup client, faster network speeds and same price. I've been using Backblaze for over a year by itself on many machines and have been quite happy. For the sake of redundancy though, a couple months ago I decided to subscribe to Mozy as well, just out of paranoia.

Due to the fact that their service always uses over 100 megs of RAM, and seems to continuously get stuck on certain files, I was planning on getting rid of it soon. Today's announcement made this decision even easier though, as now they've decided to go the way of other companies with tiered pricing models. With how cheap technology continuously gets, any company marking prices up really pisses me off.

So, I give a profane salute to you, Mozy, as you have now joined the ranks of companies I feel personally displeased with, and definitely will not recommend (not that I really did anyway.)

Even AT&T (one of the main companies I despise) let people grandfather in their unlimited plans, and cell networks take a lot more beating than a backup service with hard drive prices going down every day. Adding more servers to a rack is a lot harder than adding cell tower capacity. That type of "next month you'll be forced to change" does not sit well with me.

Dear Michael,

Thanks for being a valued Mozy subscriber. For the first time since 2006, we're adjusting the price of our MozyHome service and wanted to give you a heads up. As part of this change, we’re replacing our MozyHome Unlimited backup plan and introducing the following tiered storage plans:

50 GB for $5.99 per month (includes backup for 1 computer)
125 GB for $9.99 per month (includes backup for up to 3 computers)

You may add additional computers (up to 5 in total) or 20 GB increments of storage to either of the plans, each for a monthly cost of $2.00.

While this policy takes effect for new MozyHome customers starting today, your MozyHome Unlimited subscription is still valid for the duration of your current monthly term. In order to ensure uninterrupted service, you'll need to select a new renewal plan.