The Life and Times of Michael Shadle

This past week, I set my Parents up with a Raspberry Pi-based OpenELEC unit, which I built for them to replace an extremely dated Buffalo product. (So far I have been pretty surprised as to what this little RPi can do!)

After getting a stable setup going, the last piece of it was getting a remote that they could manage. I was nervous at first because of compatibility concerns and "bleeding edge" software. However, I picked up an "Adesso ARC-1100 Media Center Remote" - which I had seen as being compatible on the XBMC forums, and out of the box, it works great. Truly plug and play.

I wanted to pick up something reasonably priced and locally (just in case I had to return it, I didn't want to hassle with RMA processes.)

The main issue with the remote is that some buttons are a bit confusing - which is tolerable, but the main offender is the power button. It works out of the box, as one would expect, except that once you power down the OpenELEC/RPi combination, you can't power it back up again (at least not with a USB-powered IR receiver...)

To solve that issue I looked into figuring out how to do some key remapping, to make the power button do something different, or nothing at all. The documentation seems straightforward but made me dizzy for a moment (and is slightly incorrect where remote.xml is), but on the first try I had success. After that, I decided to mess around and see what other buttons I could "disable" essentially (and I decided to see if <null> could be used to map the key to nothing - it seems to work)

Here is the output of that work, it looks simple enough. Put this under /storage/.xbmc/userdata/Lircmap.xml (or via the userdata SMB share)

  
    KEY_POWER 
    KEY_DELETE 
    KEY_SUBTITLE 
    KEY_VOLUMEDOWN 
    KEY_VOLUMEUP 
  

Sure enough, it all works - now I have a remote solution for them that won't let them get into trouble, and confidence now on how to map keys in the future.

After playing with XBMC on a Pivos AIOS DS, Intel NUC, and OpenELEC on an RPi, I have to say I am happy to see the extensive community involvement in the XBMC project and its derivatives.

Now, I just wish skinning it was as easy...

While I am typically a BackBlaze fan boy ("we'll always be unlimited" and so cost-effective) I somehow stumbled upon CrashPlan. Which when looking at it and seeing it's a Java-based client initially scared me, but the support for Linux and other OSes got me interested. Not only can I stick it on servers and home Linux boxes (and I have now...) but they even give you tips on how to use an SSH tunnel to connect to their local service. So I can launch a desktop application on my Windows machine and connect to my CrashPlan backup daemon on my server at SoftLayer. Neat.

It is supposed to be totally unlimited as well, and they only charge $12.99 or something for 2-10 computers, vs. a per-computer model from BackBlaze. Also, they don't list support for file shares, but it had no problem backing up one of my samba mounts. (Please don't fix that if it's a bug!)

So while I still consider BackBlaze to be more efficient and easier to use (just "set it and forget it" I will say that CrashPlan has a lot more options, is an opt-in policy (akin to Mozy, etc.) instead of an opt-out by default policy (BackBlaze) and it makes it really easy to list the entire filesystem, and select/deselect at any level of it.

The other interesting/neat thing is you can set it up to backup to friends machines, local storage, attached drives or their CrashPlan Central cloud (which is what they charge the monthly for.)

Since BackBlaze isn't playing in the Linux space yet, and has special ways to check if a filesystem is "local" and such, it looks like I will be using the best of both systems for now. The Java UI does feel a bit "Java-ey" but the price, features and performance of the actual network backups seem well worth it.

So +1 to CrashPlan!

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 (NEWS). 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 sendmail_from=direct@prout.com;

Multiple values, manually line-broken:

fastcgi_param PHP_VALUE "sendmail_from=chroot@prout.com
precision=42";

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

fastcgi_param PHP_VALUE "sendmail_from=chroot@prout.com \n precision=42";

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