http://www.youtube.com/watch?v=yHJOz_y9rZE

I thought it was appropriate.

Determining IP information for bond0… failed; no link present. Check cable?

The problem appears to exist in how the interface responds to link status on LACP / 802.3ad ports. The computer is trying to send DHCP packets when the interface itself isn’t ready, causing Linux to think the interface isn’t configured or has no network cable plugged in. This appears to only happen when you use mode 4 channel bonding. Mode 6 works fine. The (band-aid) solution appears to be to trick the system into thinking the interface is already configured. This enables Linux to continue sending DHCP packets until the interface is configured and negotiated successfully with 802.3ad, at which point everything works as planned. Simply insert this at the end of /etc/sysconfig/network-scripts/ifcfg-bond0 - I should note this particular example is for CentOS and RHEL so I haven’t confirmed if this workaround works for Debian based distributions.

check_link_down () { return 1; }

~ $ dig andrewpeng.net aaaa +short
2607:f298:1:104::a53:ecdd

~ $

What the hell is that? It’s my shiny new IPv6 address! Dreamhost makes it stupid easy to assign a IPv6 address to your account; just log into your panel, click on your domain, then just click Add IP Address and that’s it.

I also added an AAAA record for ipv6.andrewpeng.net to make sure to make the distinction for the IPv6 only subdomain, similar to ipv6.google.com and such. If you have IPv6 connectivity, go ahead and give it a try!

pengc99@zeus:~$ sudo fsck.ext4 -fvy -C 0 /dev/mapper/MASS_STORAGE-STORAGE_LV
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

342541 inodes used (0.19%)
1892 non-contiguous files (0.6%)
178 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 57159/9867/16
333728343 blocks used (91.11%)
0 bad blocks
57 large files

321274 regular files
21258 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
——–
342532 files
pengc99@zeus:~$

Yelling at your servers can measurably negatively affect their performance. No joke. Make sure to treat your servers with respect, and keep it quiet in the datacenter!

Perhaps there is a “brown note” for disks (“rust note”?) – some harmonic that destroys their performance; although based on what we think is happening (disk heads being thrown off track), we think this has more to do with shock force than resonance. I’m sure there are disk vendor engineers out there who know all about this (Bryan links to a good reference in his blog entry).

[Source: Sun Microsystems Blog (now Oracle)]

The first obvious problem, even before you go about installing memcached support modules for your web application, is that DreamHost’s default PHP modules for their shared hosting environments do not include memcached. Later I found out that they also don’t have a build of Imagemagick, but the procedures in this guide will apply to also allow you to install Imagemagick on your own.

Before we dive in and get our hands dirty, here’s a little background about memcached and why we want it. Memcached’s website says this about what it is:

memcached is a high-performance, distributed memory object caching system, generic in nature, but originally intended for use in speeding up dynamic web applications by alleviating database load.

The gist of the issue is that PHP is a dynamically interpreted language. Unlike traditional languages like C or Java, you don’t “compile” it, you leave it as source. When someone stumbles on your website, the request for the page pulls the source code into the PHP interpreter, which then compiles it and executes the code before sending the result to your happy web visitor. Because the code is pulled, compiled, and ran each time someone visits your website, there is usually a pretty significant overhead as your PHP slowly stumbles through the compiler. This effect is especially bad for intensive CMS systems like WordPress, which is being used on this very website.

Memcached aims to speed the process up by caching frequently used objects that your PHP code uses – in the case of WordPress, this is achieved through the use of a plugin that queries the memcached server for a cached version of the object before recreating and recompiling the object from scratch. Even with the overhead of checking before creating the object, this results in a significant savings in compilation and execution time. The tradeoff is higher memory usage (space-time tradeoff). The memory usage isn’t really significant for a single user, but can easily balloon if there’s high-traffic website that is hitting the cache often. For this application, I’m just using memcached with the default cache size of 64mb.

The first thing you’ll want to do is head on over to the PECL page and download the module of choice – since I’m working with memcached, this is the link for the PECL module. I grabbed the latest stable version, which is 2.2.6 at the time of this writing. You’ll need to download and extract the archive on the DreamHost shared server into a temporary working directory.

exodus:~/.php/5.3/src$ wget -nv http://pecl.php.net/get/memcache-2.2.6.tgz; tar -zxvf memcache-2.2.6.tgz
2011-06-27 06:21:39 URL:http://pecl.php.net/get/memcache-2.2.6.tgz [35957/35957] -> “memcache-2.2.6.tgz” [1]
package.xml
memcache-2.2.6/config.m4
memcache-2.2.6/config9.m4
memcache-2.2.6/config.w32
memcache-2.2.6/CREDITS
memcache-2.2.6/example.php
memcache-2.2.6/memcache.c
memcache-2.2.6/memcache_queue.c
memcache-2.2.6/memcache_session.c
memcache-2.2.6/memcache_standard_hash.c
memcache-2.2.6/memcache_consistent_hash.c
memcache-2.2.6/memcache.dsp
memcache-2.2.6/php_memcache.h
memcache-2.2.6/memcache_queue.h
memcache-2.2.6/README
memcache-2.2.6/memcache.php
atomicfire@exodus:~/.php/5.3/src$

Now that you have extracted the source, we can follow DreamHosts’s procedure on building and installing custom modules:

exodus:~/.php/5.3/src$ cd memcache-2.2.6
exodus:~/.php/5.3/src/memcache-2.2.6$ /usr/local/php53/bin/phpize
Configuring for:
PHP Api Version: 20090626
Zend Module Api No: 20090626
Zend Extension Api No: 220090626
exodus:~/.php/5.3/src/memcache-2.2.6$ ./configure –with-php-config=/usr/local/php53/bin/php-config && make
<lots of configure and build information here>
exodus:~/.php/5.3/src/memcache-2.2.6$ cd modules
exodus:~/.php/5.3/src/memcache-2.2.6/modules$ ls
memcache.la  memcache.so
exodus:~/.php/5.3/src/memcache-2.2.6/modules$

With the build (hopefully) successfully finished, all we need to do now is move them to a folder where we can point our new PHP configuration file, and add the line into our phprc file:

exodus:~/.php/5.3/src/memcache-2.2.6/modules$ mv * ../../../lib/
exodus:~/.php/5.3/src/memcache-2.2.6/modules$ cd ../../../
exodus:~/.php/5.3$ cat phprc
extension = /home/username/.php/5.3/lib/imagick.so
extension = /home/username/.php/5.3/lib/memcache.so

Now all you have to do is log into your DreamHost control panel and make sure your hostname is running PHP 5.3 (since you compiled the PECL module against 5.3), and your Memcache PECL extension should be good to go!

Lets install memcached on our VPS:

~$ sudo apt-get install memcached
Reading package lists… Done
<lots of install-ish stuff here>
~$

I do love Debian-based distributions so, so much. Next, lets get it setup and configured.

Take note; because DreamHost’s VPS servers do NOT have the capability for iptables, you can’t firewall off controlled access to the memcached daemon. By itself, memcached does not have much in the way for access control, and you certainly don’t want it exposed to the Internet. Memcached stores, writes, returns, and can communicate data in clear-text, and is indiscriminate about who accesses the daemon or what the client does to the data. This means any average Joe Bob SquirrelPants can just netcat / telnet / whatever their way into your object cache and read and modify information at will. Not good. If HTML had a tag for “reach out and slap the reader” I would use it here to make sure you understand the risk.

What I wound up doing here is something that I lucked out on. Dreamhost VPS have a private and a public interface:

~$ sudo ifconfig
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:151727415 errors:0 dropped:1871 overruns:0 frame:0
TX packets:236389135 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:31861835451 (29.6 GiB) TX bytes:341275420981 (317.8 GiB)
Memory:fb5e0000-fb600000

eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3282435188 errors:0 dropped:5610 overruns:0 frame:0
TX packets:3138743657 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:2913519728599 (2.6 TiB) TX bytes:2137298062221 (1.9 TiB)
Memory:fb6e0000-fb700000

eth0:ps358441 Link encap:Ethernet HWaddr 00:25:90:34:c7:4a
inet addr:10.xxx.xxx.xxx Bcast:xxx.xxx.xxx.255 Mask:255.255.128.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:fb5e0000-fb600000

eth1:ps358440 Link encap:Ethernet HWaddr 00:25:90:34:c7:4b
inet addr:173.xxx.xxx.xxx Bcast:xxx.xxx.xxx.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:fb6e0000-fb700000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:234405240 errors:0 dropped:0 overruns:0 frame:0
TX packets:234405240 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:874649533641 (814.5 GiB) TX bytes:874649533641 (814.5 GiB)

~$

See that 10.x.x.x interface? It’s private and only accessible from inside the datacenter; as it turns out I can also access it from my shared server Exodus – perfect. Edit the /etc/memcached.conf configuration file to make the daemon listen only on the private interface:

# Specify which IP address to listen on. The default is to listen on all IP addresses
# This parameter is one of the only security measures that memcached has, so make sure
# it’s listening on a firewalled interface.
-l 10.xxx.xxx.xxx

Obviously you want to use your private interface here instead of the x’s. :wq and go start the daemon:

~$ sudo /etc/init.d/memcached start
Starting memcached: memcached.
~$

You now have a functional and running memcached setup on your VPS server, accessible only from it’s private interface. Now lets concentrate on our WordPress installation. I was using the Memcached Object Cache plugin to enable my websites to utilize memcached. A side-note when you use this plugin; there’s no need to have the directory in your /wp-content/plugins/ directory. When you download the zip file, the only file you need is the object-cache.php file, which you place in the wp-content directory. It activates automatically, and there is no configuration required beyond setting the location of your memcached server your wp-config.php file:

//memcached plugin settings
global $memcached_servers;
$memcached_servers = array(‘default’ => array(’10.xxx.xxx.xxx:11211′));

I have several WordPress sites that I want to use with memcached but one of the things you’ll find out quick is that you will run into key collisions where WordPress will use the same object names in queries to memcached, even across several different installations. This eventually lead to some hilarity as I started working on my sites; I would log into one, while reviewing content another. Pretty soon I was seeing myself logged into the wrong instances of WordPress, and seeing content grafted from one site to another. No bueno!

The problem lies in the fact that the plugin was designed to be used with either one instance of WordPress -> once instance of memcached or with a WordPress MU installation. This wasn’t really what I wanted. I wanted multiple instances of WordPress to be able to hit the same memcached server, so I didn’t have to spawn a separate memcached process for each website I intend to use with WordPress. More research and digging revealed that this particular plugin was more exclusively designed to work with WordPress MU installations, not standard single-seat WordPress installations. Some Google searching and I came upon this blog where Mr. Mohanjith had a modified and patched version of object-cache.php that can be used to allow multiple instances of standard WordPress installations to hit the same memcached server without key collisions. His innovation relies in the use of the $blog_id variable that you can define in the wp-config.php file – thereby prepending each key query to the server with a blog ID unique to that particular instance, eliminating the data key collision problem. In each of my wp-config.php files for my sites, I have this defined now:

//blog_id settings – REQUIRED for memcached
global $blog_id;
$blog_id = ‘andrewpeng_net’;

With this modification in effect along with the patched and updated object-cache.php – all my WordPress sites are now hitting the same memcached server, with a healthy performance boost as well. Great results so far!

I did a quick search on Google, but the only results were hack-ish setterm commands crammed into the rc.local or .bashrc files – sure that would work, but instead of setting it at bootup, then setting it again at login, wouldn’t there be a direct way to change the default behavior of the screen blanking? Go dig in /etc and lets see what we find:

pengc99@janus:~$ sudo grep -r setterm /etc/*
grep: /etc/fonts/conf.d/30-defoma.conf: No such file or directory
/etc/init.d/kbd:    setterm_args=”"
/etc/init.d/kbd:        setterm_args=”$setterm_args -blank $BLANK_TIME”
/etc/init.d/kbd:        setterm_args=”$setterm_args -powersave $BLANK_DPMS”
/etc/init.d/kbd:        setterm_args=”$setterm_args -powerdown $POWERDOWN_TIME”
/etc/init.d/kbd:    if [ "$setterm_args" ]; then
/etc/init.d/kbd:        setterm $setterm_args
/etc/rcS.d/S16kbd:    setterm_args=”"
/etc/rcS.d/S16kbd:        setterm_args=”$setterm_args -blank $BLANK_TIME”
/etc/rcS.d/S16kbd:        setterm_args=”$setterm_args -powersave $BLANK_DPMS”
/etc/rcS.d/S16kbd:        setterm_args=”$setterm_args -powerdown $POWERDOWN_TIME”
/etc/rcS.d/S16kbd:    if [ "$setterm_args" ]; then
/etc/rcS.d/S16kbd:        setterm $setterm_args
pengc99@janus:~$

Hm, /etc/init.d/kbd looks interesting, so lets take a look in there:

# This is the boot script for the `kbd’ package.
# It loads parameters from /etc/kbd/config and maybe loads
# default font and map.
# (c) 1997 Yann Dirson
< 8< ————- snip ————- >8 >
# screensaver stuff
setterm_args=”"
if [ "$BLANK_TIME" ]; then
setterm_args=”$setterm_args -blank $BLANK_TIME”
fi
if [ "$BLANK_DPMS" ]; then
setterm_args=”$setterm_args -powersave $BLANK_DPMS”
fi
if [ "$POWERDOWN_TIME" ]; then
setterm_args=”$setterm_args -powerdown $POWERDOWN_TIME”
fi
if [ "$setterm_args" ]; then
setterm $setterm_args
fi

Hm, it looks like it’s looking for the variable BLANK_TIME and POWERDOWN_TIME in the config file /etc/kbd/config – lets take a look in there:

# screen blanking timeout.  monitor remains on, but the screen is cleared to
# range: 0-60 min (0==never)  kernels I’ve looked at default to 10 minutes.
# (see linux/drivers/char/console.c)
BLANK_TIME=15
< 8< ————- snip ————- >8 >
# Powerdown time.  The console will go to DPMS Off mode POWERDOWN_TIME
# minutes _after_ blanking.  (POWERDOWN_TIME + BLANK_TIME after the last input)
POWERDOWN_TIME=30

Perfect! Change these from their respective values to 0 and it will effectively disable the screen blanking:

BLANK_TIME=0
POWERDOWN_TIME=0

Restart kbd and you’re good to go:

pengc99@janus:~$ sudo /etc/init.d/kbd restart
Setting console screen modes.
Skipping font and keymap setup (handled by console-setup).
pengc99@janus:~$

It looks like there is a bug in the installer for Debian Lenny/PPC that causes the installation to improperly detect SMP configurations. I have a Quicksilver PowerMac G4 dual 800 – after I finished installing Debian I noticed that the server was only seeing one processor:

pengc99@baccus:~$ uname -r
2.6.32-5-powerpc
pengc99@baccus:~$

Not to panic, the solution is actually rather simple. Just install the SMP kernel meta-package:

root@baccus:~# apt-get install linux-image-powerpc-smp
<!– lots of installing stuff here –!>
root@baccus:~#

Reboot the server, and then check the kernel again:

root@baccus:~# uname -r
2.6.32-5-powerpc-smp
root@baccus:~#

CTRL-a, a, d