VMWare: Debian NICs don’t come up after removing and adding virtual network card

A long time has passed after the last post to this blog. But I’m still alive and today there will be another. 😉

Yesterday I stumbled upon some problems in our virtual infrastructure regarding the Debian Linux Servers. For several reasons (most important is a dedicated network for NFS) i needed to add another virtual network card to those servers. I also removed the existing card, because the type of that card was still „Flexible“ and I wanted to change that to „E1000“ anyway.

So in short: 1 card (Flexible) was removed, 2 cards (E1000) were added. Sounds easy, but it wasn’t! 🙁


SIOCSIFADDR: No such device
eth0: ERROR while getting interface flags: No such device
SIOCSIFADDR: No such device
SIOCSIFADDR: No such device
eth0: ERROR while getting interface flags: No such device
eth0: ERROR while getting interface flags: No such device

The interfaces don’t come up and i had no idea why!

After some investigation this issue seemed to be related to udev. The MAC address of the old NIC was still in the file /etc/udev/rules.d/z25_persistent-net.rules, but of course the MAC has changed after migrating to the new E1000 card.

The solution is to edit the above mentioned file and replace the wrong MAC address value(s) with the new ones.

After that the appropriate servies need to be restarted:


/etc/init.d/udev restart
/etc/init.d/networking restart

or in short:


reboot

That’s it! 🙂

NIC bonding (aka NIC teaming) with Debian Lenny

In order to move our Nagios installation from a virtual server to a dedicated hardware machine i installed Debian Lenny on a HP Proliant DL 380 G5. This server has two integrated NICs which can easily be used together as a network bond. So if one way to or from the server failes, the machine is still available through the other card.

All the necessary requirements such as the bonding module and stuff are available in the debain standard kernel (the time i wrote this: 2.6.26-2-amd64)

What’s still left to do is to install the ifenslave package:

apt-get install ifenslave-2.6

and to modify some configuration files
/etc/modprobe.d/arch/i386 or /etc/modprobe.d/arch/i386 (depending on your architecture):

alias bond0 bonding
options bonding mode=1 miimon=100 downdelay=200 updelay=200

Mode 1 (also called: active-backup) means, that only one interface is active. The other one comes only into play, when the first (active) card fails. So this mode is only for fault tolerance and not for loadbalancing, but the configuration of this mode is very simple, because it doesn’t require additional switch configuration.

Edit /etc/network/interfaces and configure the bond0 interface:

auto bond0
iface bond0 inet static
address 10.10.0.25
netmask 255.255.255.0
gateway 10.10.0.1
up /sbin/ifenslave bond0 eth0 eth1
down /sbin/ifenslave -d bond0 eth0 eth1

Don’t configure any additional network settings for eth0 and eth1!

For testing purposes you can now load the bonding module (will also be done automatically when the servers boots):

modprobe bonding

and restart your network:

/etc/init.d/networking restart

Now you should be able to ping the server from another host and plug/unplug the cables of the two integrated NICs while the server always answers the ping requests.

Terminal not fully functional when using rxvt-unicode-256color

After reading some interesting articles about rxvt-unicode (often called urxvt) I wanted to try it out myself on my Archbox. Installation is quite simple via pacman and further customization can be done be modifying the .Xdefaults fine in your home directory.

If you install the rxvt-unicode-256color package the TERM variable will be set to rxvt-256color and that’s a problem when connecting to the debian boxes, because the ncurses package does not have a valid entry for this under /lib/terminfo.
When using less, man and I assume some other tools too, you’ll get the following error message:


WARNING: terminal is not fully functional
- (press RETURN)

To avoid this, you can add the following line to your .bashrc file in your home folder to set the TERM variable to rxvt-unicode which is included in the debian ncurses package:


case "$TERM" in
rxvt-256color)
TERM=rxvt-unicode
;;
esac

monkey HTTP Server debianized

The „“famous“ monkey http server has made it to the Debian Sid repository.
You can find it’s website here: http://packages.debian.org/sid/monkey

Thanks to Romain Beauxis from rastageeks.org and of course Eduardo Silva – the upstream developer.

 

invoke-rc.d: initscript policyd-weight, action „stop“ failed

If you try to remove the policyd-weight package via apt-get on Debian Etch the process will fail, if the policyd-weight daemon is currently not running.
The second time you enter the apt-get remove command it is successful, because the daemon was started before during the first try of uninstallation.

I reported a bug for this behaviour and the maintainer of the policyd-weight package released a new version.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473225

mini_httpd with PHP as CGI

While playing around a bit with other webservers than Apache, I decided to give mini_httpd a try. The documentation is very "limited" and you have to find out the things yourself. So here are the steps I did to get mini_httpd running on Debian Etch. Downloading and extracting is very easy:

wget 'http://www.acme.com/software/mini_httpd/mini_httpd-1.19.tar.gz' tar xzvf mini_httpd-1.19.tar.gz

Next step is compiling. There is no configure script in the sources, so if you want to enable e.g SSL support you need to edit the Makefile manually. But for now I want to keep everything at the default-values. cd mini_httpd-1.19 make After the compilation you will find the binaries in the mini_httpd-1.19 source dir (htpasswd,mini_httpd). Most interesting for now is of course the mini_httpd binary. You may want to copy it to a more common place in the filesystem. Starting mini_httpd: mini_httpd knows some startupoptions like port, user, etc. You can either specify these options on the commandline when starting the server or create a separate configuration file (e.g. mini_httpd.conf) where you set all these values. Here are thorsten@debsrv:/usr/local/src/mini_httpd-1.19$ ./mini_httpd --help usage: ./mini_httpd [-C configfile] [-D] [-p port] [-d dir] [-dd data_dir] [-c cgipat] [-u user] [-h hostname] [-r] [-v] [-l logfile] [-i pidfile] [-T charset] [-P P3P] [-M maxage] I decided to create a configfile with the following content: port=88 (for testing purposes only - would be normally 80) user=nobody nochroot cgipat=**php dir=/opt/mini_httpd data_dir=./html logfile=./logs/mini-httpd.log pidfile=/var/run/mini-httpd.pid charset=iso-8859-1 The startup of the server goes like this afterwards: ./mini_httpd -C mini_httpd.conf I would also like to use PHP in mini_httpd. There is no module like mod_php in Apache, but you can implement it via CGI. There is not much configuration to be done (see cgi-pat in mini_httpd.conf) and the shebang in the php sourcefiles need to point to your php binary (e.g. /usr/local/php-cgi), but I couldn’t get it to work successfully. After some investigation with the help of google I found out, that I need to patch the sources of mini_httpd. There is already a patch available from the m0n0wall project but this patch is not feasible for me, because it adds some m0n0wall related functionality, too. So I modified the patch to fit just to my requirements. It also adds "index.php" to the list of default filenames.

mini_httpd.patch

Dowload this patch and apply it to the sources of mini_httpd. After patching you need to call "make" again to build the new binary. patch -p0 -i mini_httpd.patch make

Migrating MySQL dumps in default Debian installations

Debian uses a separate user for the maintanance of MySQL. That user is called debian-sys-maint and will be created automatically when you install MySQL. If you accidentally delete that user or import an old dump with the „mysql“ user database, the MySQL init-script will complain with such an error-message:

Access denied for user ‚debian-sys-maint’@’localhost‘ (using password: YES)

In that case you should recreate that user with the following steps:

1. Get the password of the user from /etc/mysql/debian.cnf
2. Login to your mysql-database and execute the following statement (Replace with the real password from the file /etc/mysql/debian.cnf


GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY '' WITH GRANT OPTION;

Now, everything should be fine again… 🙂