Linux: Saving energy using auto-poweroff

I used to have a headless Linux LAN server that ran 24/7, i.e. even when I actually didn’t use it. Now, it powers itself off automatically as soon as it doesn’t detect any running workstations/notebooks (with dynamically assigned IP addresses) in the LAN.

Here’s how to do it:

In /usr/local/bin, create a new bash script named “shutdown_if_no_dhcp_client_in_lan” with the following content:

#!/bin/sh
# Shutdown the box if there aren't any (not ignored)
# DHCP clients in the LAN

# ignore the skype base station
ignored_macaddr="aa:bb:cc:dd:ee:ff"

# dhcp range starts at 192.168.1.$dhcpstart
dhcpstart=32

# dhcp range ends at 192.168.1.$dhcpend
dhcpend=46

for i in $(seq $dhcpstart 1 $dhcpend)
do
  # returns 0, if ip reachable. returns 1, if not reachable
  ping -w 1 -q 192.168.1.$i >/dev/null
  if [ "$?" = "0" ]; then
    # check whether this ip should be ignored
    if [ "`ip neighbor|grep 192.168.1.$i|grep $ignored_macaddr|wc -l`" = "1" ]; then
      echo "192.168.1.$i is reachable but ignored"
    else
      echo "192.168.1.$i is reachable and NOT ignored"
      # exit the program without shutting down the box
      exit;
    fi
  else
    echo "192.168.1.$i is NOT reachable"
  fi
done
# we didn't find any (not ignored) DHCP client in the LAN
# we can thus shutdown this box
echo "warning the users and shutting down the box in 5 minutes"
shutdown -h -P +5 Please save your work now!

(Adjust the script to your LAN environment)

In /etc/crontabs, add:

*/20  * * * * root /usr/local/bin/shutdown_if_no_dhcp_client_in_lan >/dev/null 2>&1

Now the LAN server will shutdown automatically after a while when no workstations/notebooks are running anymore. Note that this can happen 5 to 25 minutes after the last activity and isn’t fault-tolerant at all. The script can easily be improved however.

Gentoo Anti-Spam: iXhash Ebuild

As spam levels increased quite a bit lately, I made a Gentoo Ebuild for the iXhash SpamAssassin plugin by Bert Ungerer / Heise iX, Germany.

So far, it’s available on bugs.gentoo.org only. In order to install it, download

iXhash-1.5.5.ebuild

and put it in your local Portage Overlay.

YMMV, but it performs really well on my server (particularly for German spam which is difficult to catch without). Don’t forget to adjust the according penalty scores to your liking, though!

Gentoo: Greylisting for Postfix using Postgrey

Finally, I’ve had to enable greylisting for this domain due to ever increasing levels of spam. Fortunately, setting it up is very easy. For Gentoo and Postfix, here’s a nice walkthrough:

postfix greylisting on gentoo (postgrey) | andreas d.’s.

Let’s hope that this, in conjunction with other anti-spam measures, will do it for a while.

Non-spammers shouldn’t experience any problems due to this change, but if you do, please contact me using Skype (mettlerd), phone or SMS.

Gentoo ebuild for Lx-Office ERP 2.6.0 beta 1

Finally, I’ve created Gentoo ebuilds for Lx-Office ERP 2.6.0 beta 1 and its dependencies. Lx-Office is a fork of the server-based open source accounting solution SQL-Ledger and customized for the German market (and to some extent, the Swiss and Austrian markets).

A screenshot of Lx-Office ERP 2.6.0 beta 1 showing the XUL menu:

Screenshot of Lx-Office ERP 2.6.0 beta 1 using the XUL menu

And here’s a flash video of Lx-Office ERP 2.6.0 beta 1 showing the XUL menu in action.

Lx-System (the company backing Lx-Office ERP) and LINET Services host a public demo of Lx-Office ERP 2.4.3 (user: demo, password: demo).

To install Lx-Office ERP 2.6.0 beta 1 on Gentoo, follow these steps:

1) Set up a local portage overlay (e.g. at /usr/local/portage), if you haven’t done so already.

# mkdir -p /usr/local/portage

In /etc/make.conf, set

PORTDIR_OVERLAY=/usr/local/portage

2) Download lx-office-erp-2.6.0_beta_p1-r1_plus_dependencies.tgz and extract it to your local portage overlay

# cd /usr/local/portage
# tar xzvf lx-office-erp-2.6.0_beta_p1-r1_plus_dependencies.tgz

3) In /etc/portage/package.keywords, add the line

www-apps/lx-office-erp ~amd64

(or ‘www-apps/lx-office-erp ~x86‘, depending on the architecture of your machine)

4) In /etc/portage/package.use, add the line

www-apps/lx-office-erp vhosts

5) Install Lx-Office ERP on your system by executing

# emerge -av lx-office-erp

Depending on your current portage settings and installed ebuilds, you may need to unmask additional ebuilds.

6) Use webapp-config to link your Lx-Office ERP installation to a specific host, e.g. by executing

# webapp-config -I -h localhost -d lx-erp lx-office-erp 2.6.0_beta_p1-r1

7) Follow the steps displayed on the screen to setup and configure Lx-Office ERP. Some of these steps might be automated in a later release of the ebuild.

8) Have fun using Lx-Office ERP on Gentoo! :)

(These ebuilds are sponsored by my company Printscreen GmbH, dedicated to the developers of Lx-Office ERP and Gentoo and released for free use under the terms and conditions of the GNU GPLv2 license.)

Gentoo: TLS/SSL and name-based Apache virtual hosts using mod_ssl

With the introduction of the TLS SNI extension (transport layer security server name indication), name-based virtual hosts (i.e. virtual hosts sharing the same IP address) can now use distinct SSL certificates.

Here’s how to configure TLS SNI on Gentoo, using Apache:

1) DON’T try to set up TLS SNI using mod_gnutls. When I tried it on January 30, 2009, mod_gnutls still seemed to be too experimental and unstable for reliable TLS SNI (I observed some non-deterministic behaviour).

2) It does work fine though with a reasonably current version of OpenSSL and a patched Apache mod_ssl. And here, Gentoo shines once again: With Gentoo, you don’t need to manually patch Apache or OpenSSL! All you have to do is add the “sni” use flag to Apache in /etc/portage/package.use:

www-servers/apache sni

and remerge Apache (’emerge -auDNv apache’).

Note that Gentoo’s OpenSSL is already SNI-enabled by default (since openssl-0.9.8g-r2.ebuild) – remerge/update OpenSSL if required.

The configuration of SNI-enabled name-based virtual hosts in Apache is transparent, i.e. works the same way as for SSL-enabled, non-SNI name-based virtual hosts (of course you’ll want to use different certificates for every virtual host and specify them, as explained on Kaspar Brand’s TLS SNI test site).

Have fun!

Thunderbird Add-on: S/MIME Security for Multiple Identities

I’ve just found and installed the following add-on for Mozilla Thunderbird:

S/MIME Security for Multiple Identities

It allows you to use a different S/MIME certificate for each of the different identities (i.e. “e-mail address aliases” or “profile aliases”) you defined in your Thunderbird profile.

It’s currently still marked as an experimental add-on and I’ve noticed a minor glitch in v0.3.0 when using it (see my add-on review), but this might also be related to the fact that I also use the Virtual Identity add-on (another nice add-on which allows you to use an arbitrary sender address for sending messages).

The “S/MIME Security for Multiple Identities” add-on is very convenient if you have multiple e-mail accounts and want to use S/MIME message signing and/or encryption with all of them.

Bonus hint: You can get your own, personal S/MIME certificates for free at Thawte (for e-Mail only) or StartCom/StartSSL (also offers free class 1 SSL/TLS certificates for FTP servers, web servers etc. -> the latter don’t “work” with Internet Explorer, however).

Gentoo: MOTD printed twice

With some recent changes, Gentoo now seems to print the message of the day (MOTD) twice, when logging in using SSH:

Last login: Mon Dec 29 04:45:22 UTC 2008 from box on ssh
(message of the day)
Last login: Mon Dec 29 22:55:09 2008 from box
(message of the day)

I tried the following solution

Looks like the answer was in the /etc/pam.d/login and /etc/pam.d/system-login files. I had to comment out the pam_motd.so lines.

as described on http://stackoverflow.com/questions/190912/etcmotd-printing-twice-on-gentoo-linux. With these quick fixes, the MOTD doesn’t get printed twice anymore.

In addition, I also had to comment out the

session    optional    pam_lastlog.so

lines in /etc/pam.d/login and /etc/pam.d/system-login in order to prevent the “last login” line from being printed twice.

Best practice tips for Gentoo sysadmins

Currently, there are some critical ebuild dependency issues in Gentoo’s portage tree that might seriously hurt your box. Symptoms: When updating your system, portage might display an error message similar to this one:

[ebuild     U ] sys-fs/e2fsprogs-1.41.2 [1.40.9] USE=”nls (-static%)” 4,263 kB
[ebuild  N    ] sys-libs/e2fsprogs-libs-1.41.2  USE=”nls” 479 kB
[blocks B     ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] sys-libs/e2fsprogs-libs (is blocking sys-libs/ss-1.40.9, sys-libs/com_err-1.40.9)

The important thing: DON’T unmerge ss or com_err, as it will break wget and other essential parts of your system! Portage thus won’t be able to download e2fsprogs-libs-1.41.2 which is required to replace the removed ss and com_err libraries (which are part of e2fsprogs-libs starting with v1.41.2).

Solution: Either wait until this issue gets resolved by the Gentoo core dev team or read through the following posts and Gentoo bug reports:

If you really know what you do, you might want to try this suggested quickfix (Important disclaimer: Looks reasonable and fine as a quick workaround to me, but I haven’t tried it yet. You apply it at your own risk, as usual! Note that this workaround doesn’t solve the real problem.)

As serious issues like these are quite common in Gentoo, here are some best practice tips for Gentoo sysadmins that help prevent some of the potential problems:

  • First of all, try to use stable ebuilds only. If this is not possible for some reason, try to minimize the number of unstable ebuilds (~amd64 etc.) on your system.
  • It’s rather tempting, but DON’T setup a cronjob to do automatic emerges! Portage only catches the most evident issues, but emerging new ebuilds is never without risks (not updating your system is risky too, however). The best approach would be testing any updates on a test box first before installing them on a production system. The second best approach is probably doing a monitored, manual update in small, incremental steps with immediate testing afterwards. This helps isolating problems, should they occur (it’s difficult to isolate a problem that was detected after an automatic update of hundreds of ebuilds).
  • Automate ’emerge –sync’ by putting it in your daily crontab in order to refresh your portage tree regularly. That’s neither particularly safe nor unsafe, but it guarantees that you don’t emerge that weeks-or-months-old broken ebuild that has been fixed in the meantime.
  • Regularly fetch new source packages by setting up a cronjob for ’emerge -uDN –fetchonly world’ (or -f). Like this, portage uses some additional hard disk space for the package sources (always make sure you have enough free space and properly setup partitions/volumes!). It makes sense though as one day, you’ll use most of these source packages anyway and having a source package locally can be very helpful in a situation like the one described in this post. IOW: If you aren’t able to download anything anymore due to a severely broken system, chances are, that you can still solve the problem on localhost, if you have source packages at hand.
  • Append “buildpkg” to the FEATURES variable in /etc/make.conf. Like this, portage will additionally create binary packages in /usr/portage/packages/All when emerging new ebuilds. This will require some spare free space on your hard disk again, but having a prebuilt, binary package at hand can be very helpful if there are any problems with the gcc toolchain or any other compiler chain needed. If you don’t like to enable this feature permanently, you can use the -b or –buildpkg option when executing emerge.
  • If you haven’t used the “buildpkg” feature so far, you can create binary packages of all the installed ebuilds on your system using the “quickpkg” utility and my quickpkg_all bash script.
  • Keep old, compiled kernel images in /boot and listed in your /boot/grub/menu.lst. Booting a new manually configured and compiled kernel is always a bit of an adventure (unless it was tested on an identical box before), and it’s good to keep previous kernels that are known to work. Even if it doesn’t work perfectly, it can take you to a console login prompt at least.
  • Instead of doing things the regular “remove old packages first, then install new packages” way, get used to the Gentoo way of doing things: “install new packages first, then remove old packages (if at all)”. Avoids serious problems that can occur when accidentally deinstalling an old, seemingly no longer used package that other important packages depend on and don’t work without.
  • When merging new configuration files, use dispatch-conf instead of etc-update. dispatch-conf uses CVS to create backups of old config files (which can be a helpful source of information in some situations). See the value of the “archive-dir” setting in /etc/dispatch-conf.conf.
  • Add files and directories to CONFIG_PROTECT, if in doubt. It’s better to have one ._cfg0000_XXX file too much than an important configuration file accidentally overwritten by portage.
  • Use emerge’s -D option for improved (deep) dependency checking.
  • Do regularly use revdep-rebuild to check for broken dependencies and to remerge the according ebuilds.
  • And of course, create automated, incremental backups of your systems regularly. You’ll sleep better, believe me ;)
  • Monitor your systems for errors. I do it with some custom bash scripts I wrote, but there are many full-fledged monitoring solutions for general purpose health monitoring.
  • As a fallback for (some) DNS problems with DHCP-based systems, I regularly send a heartbeat of a DHCP system to a box in another network, revealing the DHCP system’s last known/assigned IP address.
  • Not limited to Gentoo sysadmins: Having a (hardware) remote console accessible via a different IP address is worth a lot in case there are serious troubles with the operating system or the hardware.

Feel free to add other helpful best practice tips for Gentoo sysadmins!

Simultaneously using multiple accounts with Skype 4.0

As an addendum to my earlier post, I’ve just noticed that a) Skype 4.0 Beta 2 runs pretty stable on Windows Vista 64 and b) has built-in support for managing multiple Skype accounts! With the help of this feature, you could for example set up a private account and a business account and use both of them at the same time, using the same Windows user account. The setup is straightforward:

1) Install Skype 4.0 Beta 2

2) Create a shortcut to Skype.exe and place it on the quick launch bar. Rename the shortcut to “Skype Private Account”, for example. Start Skype using this shortcut and setup your first account (in this case, your private account).

3) Create another shortcut to Skype.exe (add it to the quick launch bar, too) and name it “Skype Business Account”. Open the “Properties” dialog of this shortcut by right-clicking on it. In the “Target” text field of the properties dialog box, append ” /secondary” (without double quotes) to the Skype.exe path that is already there. For example, in my case, the “Target” text field contains:

“C:\Program Files (x86)\Skype\Phone\Skype.exe” /secondary

Rename this shortcut to “Skype Business Account” (right-click->rename). Having done this, start Skype using this shortcut. Skype will then prompt you to enter the credentials of another Skype account of yours (in this example, of your business account).

You can also choose different icons for the two shortcuts. Further, I’d assume the /secondary feature isn’t limited to managing two Skype accounts, though I haven’t tested it with more than two accounts. The main advantage of this “/secondary” feature is that you don’t need to have a separate Windows user account for each of your Skype accounts. Note however that, even with this solution, a new instance of Skype will be created for each of your Skype accounts – every instance consuming about 40 MB of RAM.

I think that’s a very useful feature and I like it a lot.