Linux Network Interface Channel Bonding and DHCP

While configuring a few servers I noticed some strange behavior with mode 4 channel bonding (LACP / 802.3ad) and DHCP. You might get the following error message, no matter what you do:

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; }

Continue Reading

2^128 is a really big number

~ $ dig aaaa +short

~ $

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 to make sure to make the distinction for the IPv6 only subdomain, similar to and such. If you have IPv6 connectivity, go ahead and give it a try!

Continue Reading

Crisis Averted

Really thought I lost the LVM share. There might actually be a bug in the PowerPC Debian kernel that causes it to kernel panic on large LVM partitions. Ever since I switched to an Athlon MP server from my old PowerMac, it hasn’t kernel panicked since. Nice to have a large network drive at home again. Gonna take the plunge and convert the partition to ext4 while I’m at it.

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

Continue Reading

Be nice to your servers


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)]

Continue Reading

memcached + WordPress + DreamHost Shared Hosting

The idea of using memcached on my shared hosting account had been bouncing around my head for a while; especially on my DreamHost shared hosting account. There are periods when the performance would suffer because of other users on the server, and I was also looking for a general increase in performance without having to pay for an expensive dedicated server. I should start off by saying that what I’m about to explain only works if you have a VPS or Dedicated server that you can access already. It may seem redundant for a tutorial or howto guide on how to get memcached working in a shared environment if you already have a VPS available, but the practice and procedures will be useful to allow you to run other customer PHP modules on DreamHost shared hosting. In my case, I already had a VPS server I use for Irssi but was not configured to be a web server. It’s a stripped bare DreamHost VPS with sudo / root access, and a handful of IRC applications running in screen. I had stumbled across this deal, for $5/month (on top of your regular DreamHost bill) when they were beta testing VPS servers and I had volunteered for an account; somehow my account got tagged with the discount, so I decided why not and added one to the account. Not only that, I didn’t want to deal with the migration of switching my accounts over from the shared server to the VPS; the “seamless” transition they have setup is fairly deceiving; I find that it usually borks up the websites in the transfer and requires a fair bit of mucking to get everything working again.

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.

Continue Reading

Disabling console blanking in Debian Linux

I find it particularly annoying that the default settings in a stock base Debian install blanks the monitor after about 30 minutes of inactivity. There are a few servers that I have logged in and running htop 24×7 and it’s inconvenient to have to hit the keyboard every time I need to check in on the system.

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

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
if [ “$BLANK_TIME” ]; then
setterm_args=”$setterm_args -blank $BLANK_TIME”
if [ “$BLANK_DPMS” ]; then
setterm_args=”$setterm_args -powersave $BLANK_DPMS”
if [ “$POWERDOWN_TIME” ]; then
setterm_args=”$setterm_args -powerdown $POWERDOWN_TIME”
if [ “$setterm_args” ]; then
setterm $setterm_args

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)
< 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)

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


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).

Continue Reading

PowerMac G4 Debian Linux SMP Support

Update 6/9/2011: I have put in a bug report (#629492) with the Debian developers to notify them of this issue.

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

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 –!>

Reboot the server, and then check the kernel again:

root@baccus:~# uname -r

Continue Reading

Ugly shell scripting

Recently I developed a strange wear pattern on my car’s front passenger side tire (that’s front rightside tire for those driving on the “wrong” side”) – the outer surface of the tire was warn almost completely bald while the inside treat was fresh and meaty. This was rather odd, as I recently had the car re-aligned with zero toe and max negative camber, which comes out to around -1.6 on both sides. Later I found that as a result of this slight adjustment, I had been pushing the car a lot more aggressively while driving to and from work. The downside of this, as I retraced my steps, is that my drive home from work is almost entirely left turns. When coupled with the fact that I had been recently pushing the car very hard on these left turns, it made sense that I had worn out just the outer edge of the tire.

Since the car is AWD, I didn’t have the option of just replacing that one tire as the difference in tread levels can be harmful to the AWD system. Now here comes the difficult task of finding a single Bridgestone Potenza RE-960/AS Pole Position tire in 225/45/17 so it can be shaved down and mounted.

After some searching I came upon the website – but searching for “Potenza 960” yielded the tire in all sizes but the size I needed. Now, since I’m lazy, how would I automate this search and have my computer notify ME instead of having to manually check every day for the tire I needed?

Continue Reading

How to update the PRL on your HTC Touch Pro 2

What is this PRL file do? It’s the Preferred Roaming List, and it’s a database that your phone uses to pick which cell phone towers to use, and which towers to consider “Roaming” and “Home”.

With modern cell phone plans in the US, we rarely have to deal with “Roaming” charges, but this term is used just to refer between towers owned and operated by your service provider (Sprint, Verizon, Alltel, US Cellular, etc…) and towers that your service provider doesn’t own but has roaming agreements to.

Updating your PRL updates which towers your phone can access, and can help with signal strength in areas where you have fringe coverage. This is usually due to changing roaming agreements between cell phone service providers, so keeping the PRL updated can improve consistency and coverage if you are in an area that does not have very good coverage.

Here is what you need in order to update your PRL:

  • Your phone
  • A registry editor for your phone
  • A MicroSD card reader/writer, or the USB cable for your phone

Here are the step-by-step instructions on how to update the PRL on your Sprint HTC Touch Pro 2.

  1. Get a .prl file for your provider (Sprint, in my case) – I used this thread [] and save it to your MicroSD card root
  2. If the PRL file you downloaded is zipped, you may need to unzip it to get the .prl file.
  3. You will need your MSL code for this next step, if you don’t have it, here is how to get it:
    1. Get a Windows Mobile registry editor tool like CeRegEditor [free!].
    2. Go to HKLM\Software\HTC\ATDbgLog
    3. Edit item called “Enable” and change from “0” to “1”, and save your changes
    4. Reboot your device
    5. Go back to the registry editor and change the setting back to “0”
    6. Reboot your device
    7. Open File Explorer and go to the folder “\Atlog” in the root directory of your device.
    8. You should see a file called “ATDbg0” (the “0” may be another number like 1).
    9. Open the file and locate a line containing “RMSL”
    10. You should find a line item that includes a 6 digit number, this is your MSL code. Write it down
  4. Open up the phone dialer application and enter this combination: ##775# – you do not need to hit “Send”, it will automatically enter a hidden menu after you enter in that combination.
  5. It will ask you for your MSL code, enter it in now.
  6. Select “Menu” then “Edit”, and find where you have extracted the PRL to. It should be on your MicroSD card.
  7. Select the PRL file and hit “OK” twice
  8. Your phone should now prompt you to reboot. Go ahead. After the phone boots up, you can dial ##778# to verify your new PRL!
Continue Reading