Here’s a little snippet I use to remove multiarch / i386 support from Ubuntu with Puppet.
if versioncmp( $::lsbdistrelease, "12.04" ) > 0 {
exec { "remove-architecture i386":
command => "/usr/bin/dpkg --remove-architecture i386",
onlyif => "/usr/bin/dpkg --print-foreign-architectures | /bin/grep -q i386",
}
} else {
file { "/etc/dpkg/dpkg.cfg.d/multiarch": ensure => absent, }
}
I’ve found a few snippets of PHP code to read XMP / XML meta data from an image file, but none that I would call very robust or efficient. I ended up writing my own for Underwater Focus, and I’m quite pleased with the result. In fact, after adding support for a shortcode, I packaged it as an Adobe XMP plugin for WordPress.
The first part of using XMP meta data is reading the XMP information from the image. I’ve seen a few solutions that read the whole file into memory, and others that read-in just a small part. If the XMP / XML contains a lot of information, that small part may be incomplete. And each time the XMP meta data is required, the original (and sometimes quite large) image file must be re-read. Since the XMP doesn’t change unless the original image is updated, there’s no reason to keep re-reading the same large file time and time again.
A few weeks ago I mentioned the wesley.pl script from GitHub to optimize images, and how I had modified it to keep (or discard) the EXIF / XMP information. Making sure images are as small as possible is important to save bandwidth and improve page load times (and google rank), so I think it’s worth discussing my image optimization process in more detail.
Recently Jason A. Donenfeld reported a simple vulnerability in W3 Total Cache on the Full Disclosure mailing list, which was picked up by the Security Ledger website, and then posted on Slashdot. The vulnerability is a simple Apache Httpd configuration oversight — plugins often create their own folders under ./wordpress/wp-content/ without considering that directory indexing might be turned on, or that files within that folder are located under a DocumentRoot, and thus available to anyone. Some configuration files are also vulnerable in this way — the wp-config.php file, for example. During the WordPress install, it is recommended that the wp-config.php be re-located one folder above ./wordpress/, to move it out of the DocumentRoot.
When an encrypted VPN is not available, the next best solution is usually port-forwarding one or more port(s) through an SSH tunnel. The down-side of SSH is that by itself it cannot maintain a persistent connection — network issues may force the tunnel to stop responding, or even drop completely. Autossh is a small front-end for SSH that can monitor the connection, and restart the tunnel if it drops or stops responding. I found that the startup scripts available for autossh on the internet were a little too basic for my needs — I wanted autossh to start multiple connections, and to start/stop each one individually if I needed — so I wrote my own.
I wrote a bash script this morning to report the size of WordPress cache folders, the number of files they contain, read each file to prime the OS disk cache, and optionally flush the OS disk cache as well. This might be a script you could execute to email a daily/weekly report of cache folder sizes, or perhaps execute during/after booting a server to prime the OS disk cache, or even on a regular schedule to make sure the OS cache is always primed. The script also has a “flush” argument to sync and drop the OS disk cache, which isn’t very useful (to me) except to see the difference in speed between a clean and primed cache (about 11s vs 0.4s for all websites on my server).
I recently added some disk caching for MySQL queries, WordPress objects, PHP opcode, and PHP web pages on my server. There are several different caching techniques and applications available, and memcached seems like one of the more popular ones. Right or wrong, it appears to be the default go-to for many developers these days.
Since I’m a SysAdmin by profession (with maybe a penchant for scripting and integration), I tend to have a more “systems” oriented approach — which led me to first consider, and then choose disk caching over memcached. In this post, I’ll outline the reasons I chose disk caching, and why in most circumstances it might be superior to memcached.
I had to update several reverse zone files today, so wrote a quick for-loop in bash to freeze and thaw all the zones. The script parsed the zone file names and reversed them into a proper `d.c.b.a.in-addr.arpa` format. Later I tweaked it with sed to make it more flexible (in order to pass it a full or partial IP address), but ended up using `tac` for the reversing part instead – that’s what it’s made for after all. And if you’re wondering what `tac` stand for, just read `cat` backwards. :-)