Upstart and resolvconf cache

I’ve recently found this when I was trying to fix a nameserver config issue with resolvconf on Ubuntu. When resolvconf populates /etc/resolv.conf, it will read what we have configured in /etc/resolvconf/resolv.conf.d (head, base, tail, etc) and also any dns-server declared in /etc/network/interfaces. I had a conflict with something I was populating in the head file (with Puppet) from something that was configured under /etc/network/interfaces. So I removed the conflicting dns-server declaration from the interfaces file and run “resolvconf -u” to update the config. To my surprise, the “deleted” nameservers from /etc/network/interfaces were still included in /etc/resolv.conf. After some debugging, I have noticed that resolvconf’s Upstart script now keeps a cache file under /run/resolvconf/interface that is a copy of the previous /etc/network/interfaces. You need to delete this file and restart resolvconf to make it work: “stop resolvconf ; start resolvconf”.

Poor man’s ssh launcher (CLI)

Problem: just wanted an easy way to add my hosts to the ssh config file and connect to each host through the easiest way possible using normal bash command-line.

Solution: configure your .ssh/config like you normally would, with the following:

Host myapache
User fred

Host myapache2
User fred

Add the following to your .bashrc or .bash_profile (Mac OS X):

shosts=`grep ‘Host ‘ ~/.ssh/config | awk ‘{print $2}’`
for h in $shosts ; do alias $h=”ssh $h” ; done
alias ssh-hosts=’echo -e $shosts | tr ” ” “n”‘

And voilá, if you want to connect to any host, just type the name of the host, for example ‘myapache’. If you want to get a list of ssh hosts, type ‘ssh-hosts’. Keep it simple, stupid.

daemontools svscanboot & Ubuntu Server 8.10

If you just installed a brand new Ubuntu 8.10 server and tried to run daemontools the Debian Way (apt-get install daemontools daemontools-run), you, just like me, realized that there is no more /etc/inittab. Since Edgy Eft that someone decided that inittab should be deprecated in favor of a thing called Upstart. So, the best you can do is to remove the daemontools-run package:

# apt-get remove daemontools-run

Create a new file on /etc/event.d/svscanboot with:

# svscanboot

start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5

stop on runlevel 0                                                              
stop on runlevel 1                                                              
stop on runlevel 6

exec /usr/bin/svscanboot

Create /etc/service directory and start the service with:

# mkdir /etc/service ; initctl start svscanboot

That’s it. You should have svscanboot started, together with svscan and readproctitle.

zfs-fuse 0.5.0

Remember ZFS for Fuse? It was a Summer of Code Project, done by Ricardo Correia (he’s now working for Sun). This guy has done a great job porting it from Solaris to Linux/Fuse. Since we will not see any kernel driver version for Linux anytime soon due to license problems, and for those that want to test it, there is good news. I’ve checked his page today, and oh boy, the project is not dead and we even have new release, 0.5.0! Yay. Checking from the CHANGES file, the new release is up-to-date with ZFS Pool 13, lot’s of bugfixes and new features like gzip compression, async i/o, send/recv and much more. I’m going to test it very soon. Almost missed this.

RedHat buys Qumranet (KVM)

After dropping the support of Xen for RHEL (well, not really, they will still support it, but not as passionate as it was in the past), RedHat buys Qumranet (KVM) and becomes a new player on the virtualization market, specially with Virtual Desktops (watch SPICE). As a sidenote, I’m a very big fan of KVM. And RedHat also. KVM is also part of the stock kernel since 2.6.20 (as a module). If there were some doubts about the future of KVM, well, think again.

e1000_clean_tx_irq: Detected Tx Unit Hang

Today after installing CentOS 5.1 x86_64 (kernel 2.6.18-53.1.14.el5xen) on a server with a Tyan motherboard and when I’ve tried to do a yum update, got this nasty error on the console:

e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <31>
  TDT                  <31>
  next_to_use          <31>
  next_to_clean        <af>
  time_stamp           <1014b175c>
  next_to_watch        <af>
  jiffies              <1014b1875>
  next_to_watch.status <1>

The server has 3 Intel NIC’s. One 100M and two 1000M. The faulty NIC is connected to a Gigabit Switch and I don’t have this problem forcing the port to 100M. With a little bit of research, I’ve found out that actually, it’s a known bug, specially on Supermicro hardware. In case you have the luck of having the same problem, you’ll need to download a fixeep.txt to fix some naughty bit on the eeprom. It will detect and fix the 82573-series eeprom using ethtool (sh fixip.txt ethX). Worked for me after running the script and doing a reboot.