Introduction

Recently, the openstack guest agent (nova-agent) hasn't been working up to par on Gentoo systems. As an excercise and for a bit of fun, I've re-written the agent functionality from scratch. The attempt is located on GitHub and currently works correctly on Gentoo systems. Others have volunteered to create appropriate configurators for other distributions as well as test the framework on these distributions.

Design Considerations

Singularity was designed to meet the following considerations:

• maintainable and extensible code
• use system libraries but leverage virtual environments for segregation
• framework for pluggably configuring a system based on information from the hypervisor
• configurators are focused on one task and kept small
• configurable; particular functions can be disabled individually

Conclusion

Singularity should be stable enough to use in production but without appropriate testing this claim feels hollow. The plan is to mark it 1.0 sometime within the next week unless major issues are reported or noticed.

Introduction

A Gentoo overlay for personal projects as well as interesting things that aren't found in eix-remote when I sit down to use them. Typically, this includes minor patches, use flags, or other minor items.

Installing alunduil-overlay

1. install layman
2. add http://www.alunduil.com/svn/portage/trunk/alunduil-overlay.xml to the overlay variable in /etc/layman/layman.cfg
3. add the overlay using layman: layman -f -a alunduil-overlay

Issue Reporting

Please, report any issues with the ebuilds provided to bugzilla.alunduil.com under the alunduil-overlay product.

Introduction

I was recently requested to document common Apache rewrite pitfalls and examples. As a result, I have crafted the following document. It is intended as a two page document where the first page is a reference guide of commonly used rewrite variables and flags; the second page is a short list of examples, gotchas, and troubleshooting advice.

Rewrite Cheat Sheet

RewriteCond %{HTTP_HOST} !^www [NC]
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [R,L,QSA]

RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R,L,QSA]

RewriteRule ^/?subweb/(.*) https://other.example.com/$1 [R,L,QSA]

RewriteCond %{REMOTE_ADDR} ^127.0.0
RewriteRule ^ - [F,L]

RewriteRule ~/?alias/(.*) /var/www/vhosts/$1/httpdocs/$1 [L,R]

RewriteCond %{REQUEST_URI} !server-status [NC]

RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [R,L,QSA]

Introduction

It seems that disk snapshots have become a hot topic and a confusing topic. I intend to simply outline what snapshots look like in terms of the lower layers of abstraction and nothing more. Snapshots are built into things like LVM, SAN, &c but I will not be covering those technologies. Instead, what I intend to clarify is how snapshots work in LVM.

Lower Layers

LVM Snapshots

For certain purposes (database backups, &c), it is necessary to have the disk being backed up in a consistent state. If we want these conditions it usually involves stopping any services that write to that region of the disk and ensuring the changes have been flushed and that nothing further will write to that region. Stopping production services for backup purposes is a possibility if you've got the cash to create a redundant environment but this becomes a much simpler problem when using LVM snapshots.

An LVM snapshot is a temporary region of disk set aside to preserve the consistency of the region it's a snapshot of. When an LVM snapshot is created the following happens:

• LVM reserves space for the original blocks that get changed by writes; this is the snapshot space (name and size in the LVM command)
• LVM creates a new device (e.g. /dev/mapper/vg-snapshot) to access the disk contents at the snapshot's creation time
• When a write occurs on the original disk the original extent gets written into the snapshot area

The reason that LVM snapshots don't use a differencing disk is speed. With this setup for snapshots we have instant creation and instant deletion:

Of course, this means that when we are reading this data or writing to the logical volume, we have extra operations to perform that didn't occur before the snapshot existed:

Conclusion

LVM snapshots are a convenient way of getting a consistent view of a particular logical volume while doing backups or other sensitive-to-write operations. One caveat to keep in mind (besides the ever so slight write performance drop), is the size of the snapshot dictates how much information can be written to the logical volume before the snapshot is useless and is no longer valid. Keep the amount of writing you expect for the logical volume in mind when determining the size of the snapshot you're creating.

Introduction

As I mentioned in Optimizing Gentoo: CFLAGS, you want to be comfortable with the existing documentation on CFLAGS before going crazy trying to optimize your CFLAGS on your system. With the wrong CFLAGS things can and will randomly stop working or possibly building. Thus, it's a good idea to have a good understanding of what you're doing to the code when you modify these sacred parameters.

Let's build on what we accomplished last time and get any ebuilds that are machine instruction set aware building those sections as well as the changes you made to the CFLAGS last time.

Finding USE Flag Names

How can we find the flags that we want to add to our /etc/portage/package.use or /etc/make.conf files? As always BASH is our friend and can be used to find this answer for us:

. /etc/make.conf && gcc -Q -c -v ${CFLAGS} --help=target | grep enabled

This displays the currently enabled flags based on your CFLAGS parameter from /etc/make.conf and allows us to find which flags have USE flags with the following:

gawk '/-m.*/ { print $1 }' | cut -d 'm' --complement -f 1 | xargs -i{} equery h "{}"

The resulting USE flags can be added to /etc/portage/package.use or /etc/make.conf as your needs dictate.

Conclusion

Using a little scripting we can extract the USE flags that correspond with the instruction sets we enabled last time.

Introduction

Memcached is a simple key/value memory store that uses keys to perform fast lookups of values stored in memory. Most languages have simple bindings that make this very easy from a programming perspective. This also means that it's not quite as simple to configure as APC.

Installation and Configuration

I recommend using your choice of installation mechanism (or your distribution's choice; mine's emerge) to install Memcached.

The configuration usually consists of an RC configuration parameter file that specifies how much memory to allocate and a port to listen on. In Gentoo this file is located in /etc/conf.d/ as usual but look for it in /etc/sysconfig on RHEL -like distributions.

Update the configuration to listen on the interface of your choice, use the amount of memory that's appropriate for your application and system, &c. That's all there is to Memcached and you're now ready to start the service.

Configuring Wordpress to Use Memcached

I've previously mentioned the W3 Total Cache Wordpress plugin but unfortunately this plugin doesn't allow you to easily configure Memcached usage through the web interface. It defaults to using the Memcached server located at 127.0.0.1:11211 which isn't appropriate for a remote installation of Memcached. We need to modify DOCROOT/wp-content/w3-total-cache-config.php so that the Memcached servers point to our remote server's location before enabling it in the interface. The following sed command can make this change for us:

sed -i -e 's/127.0.0.1:11211/HOST:PORT/g' DOCROOT/wp-content/w3-total-cache-config.php

Configuring MediaWiki to Use Memcached

Setting up MediaWiki with Memcached is a simple matter and only requires an edit of its LocalSettings.php file. We need to add the following section to enable Memcached:

## Shared memory settings
$wgMainCacheType = CACHE_MEMCACHED;
$wgParserCacheType = CACHE_MEMCACHED;
$wgMessageCacheType = CACHE_MEMCACHED;
$wgMemCachedServers = array("giskard.alunduil.com:11211");

$wgSessionsInMemcached = true;

These settings not only enable Memcached but also specifies the set of Memcached servers to use and whether or not to put sessions into Memcached.

If you do use multiple Memcached servers and want to apply a weighting factor you can do this with nested PHP arrays:

$wgMemCachedServers = array(array("host:port", weight), array("host2:port2", weight));

Conclusion

Using Memcached can greatly reduce the load placed on databases behind webapps or other data storage and retrieval systems. This usually improves the perceived load on the web application itself but not necessarily.