System Tray Icon to Monitor a Linux Software RAID Locally //at 04:09 //by abe

About a year ago I bought a new workstation computer for myself at home. It’s a Tuxedo XUX_Cube which is advertised as gaming PC. But I ordered a slightly atypical non-gamer configuration:

• As much RAM as possible (64 GB)
• Intel i7 CPU, but the low power variant
• Only with the onboard Intel graphics card. (No need for NVidia binary crap drivers.)
• 2× Samsung 128 GB SSD for OS and $HOME plus 2× 3 TB WD Red disks for media storage; both pairs set up as RAID 1
• Bitfenix Prodigy-M case in Orange. (Not available in Tuxedo Computer’s online shop, but they nevertheless ordered it for me. :-)

Of course the box runs Debian. To be more precise, it runs Debian Sid with sysvinit-core as init system and i3 as window manager. As I usually have no monitoring clients on my laptops and private workstations, I rather often felt the urge to do a cat /proc/mdstat on that box.

So at some point I wanted something like smart-notifier, but for Linux Software (MD) RAIDs. And since I found nothing, I did what Open Source guys usually do in such cases: I wrote it myself — of course in Perl — and called it systray-mdstat.

First I wondered about which build system would be most suitable for that task, but in the end I once again went with Dist::Zilla for the upstream build system and hence dh-dist-zilla for the Debian packaging.

Ideas for the actual implementation were taken from Wouter’s fdpowermon for the systray icon framework in Perl and Myon’s mdstat Xymon plugin for an already proven logic to parse /proc/mdstat. (Both, Wouter and Myon have stated in a GnuPG-signed e-mail that I copied less code than would validate their copyrights, so I was able to license it under a single license, namely GNU GPL version 3.)

As of now, systray-mdstat is also available as package in Debian Unstable. It won’t make it to Stretch as its first line of code has been written after the soft-freeze for Stretch was already in place.

Xen: Running a Sid DomU with PyGrub on a Squeeze Dom0 //at 03:07 //by abe

I’m running one Debian Sid and one Jessie (Testing) Xen guest domain on a Debian Squeeze (Oldstable) Xen 4.0 running host server.

Recently I had to reboot one these virtual machines after more than a year of uptime. But the new 3.14 kernel from Debian Experimental didn’t boot. Neither did 3.13 from Debian Unstable. Nor did any other kernel image newer then the 3.5-trunk (from Debian Experimental back than) work.

Everytime pygrub bailed out with this error message:

Error: (2, 'Invalid kernel', 'xc_dom_find_loader: no loader found\n')

(Yes, the parentheses and the “\n” were part of the error message.)

After some searching on the web I found hints that this message may be caused by an unsupported compression type in the kernel image.

And indeed, if I unpack the “vmlinuz” with the extract-vmlinux tool which is part of Linux’ source code (but not yet part of any binary package in Debian), and use the extract file in grub’s menu.lst (which is then read by pygrub) instead, the DomU boots Linux kernel 3.14 again, even on a Squeeze-running Dom0.

Debian-Stammtisch in Zürich //at 12:49 //by abe

Wir (Michael Stapelberg und ich) wollen in Zürich einen regelmässigen Debian-Stammtisch, eine Debian-Lokalgruppe etablieren.

Das erste Treffen findet statt:

• am Dienstag, den 5. November 2013, ab 19 Uhr (CET)
• im Gloria, Josefstrasse 59, 8005 Zürich.

Jeder, der sich für Debian interessiert, ist eingeladen. Eine Anmeldung ist nicht notwendig.

Als regelmässigen Termin visieren wir den ersten Dienstag im Monat an.

Diesen Termin haben wir gewählt, weil er unseren Recherchen nach keine Terminkonflikte mit den Lokalgruppen der LUGS in Zürich und Winterthur, der FSFE in Zürich, dem CCC ZH, den Tuxeros oder dem Webtuesday gibt. In Kauf genommen haben wir Kollisionen mit wöchentlichen Treffs in der Hackerspaces Ruum42 in St. Gallen und Reaktor23 in Waldshut-Tiengen.

Es kam aber dennoch bereits die erste Meldung bzgl. potentieller Terminkonflikte rein. Wir diskutieren gerne noch über den Termin, sowohl am Stammtisch selbst, aber auch auf der Debian.ch Community-Mailingliste. Bevorzugte Sprache auf der Mailingliste ist Englisch, Deutsch ist aber auch in Ordnung.

Potentielle Terminänderungen werden primär auf der Debian.ch Community-Mailingliste und im Debian-Wiki auf der Lokalgruppen-Seite bekanntgegeben.

Die Termine wollen wir aber auch über die LUGS-Termine-Liste, die es auch als iCal oder E-Mail-Reminder gibt, publizieren. Danach sollten die Termine auch auf Freie Termine erscheinen.

Hui, ist das lange her, daß ich hier was auf Deutsch geschrieben habe. :-)

Multiple Move & Co. //at 00:08 //by abe

nion’s blog made me notice that many people don’t know mmv (multiple move), which approximately works like this:

mmv '*.htm' #1.html
mmv '*.foo.*' #1.#2.bla

Additionally, mmv also can copy, link or even append files when called as mcp, mln or mad respectively with the appropriate command line options.

When I told nion in IRC on #debian.de about mmv, HE pointed me to the Perl script /usr/bin/rename, which is in Debian’s perl package and therefore installed on nearly every Debian system by default. It moves files by applying perl subsitutions to file names:

rename 's/\.htm$/.html/' *.htm
rename 'y/A-Z/a-z/' *

Being curious, if the newly found tool is not only available in Debian, I looked on a SuSE 9.0 box and indeed, I also found there a /usr/bin/rename. But — surprise, surprise — it’s not a Perl script but an ELF binary. And although it does similar things than mmv and Debian’s rename, it is the simplest of the three commands:

rename .htm .html *.htm
rename foo foo00 foo?
rename foo foo0 foo??

Note to my self: Nice add-on for your command line efficiency talk.

SuSE sucks! //at 05:44 //by abe

Since SuSE closes the security support two years after release and the recent KDE JavaShit remote code execution hole wasn’t patched as fast as I would have expected it (the patch came out after the upgrade I’m writing about here) in the SuSE 9.0 which was installed on my 2.66 GHz AMD desktop at work (it started as in 2002 as a SuSE 7.3 on a 400 MHz box and has been upgraded since then to 8.0, 8.2 and 9.0 IIRC), I decided, it’s now really time to upgrade to SuSE 10.0. (Although 10.1 will be out soon, I just don’t want to wait for it.) And since my boss only wants SuSE boxes and neither Debian (which I would prefer) nor Gentoo (which a colleague prefers), I couldn’t simply install Sarge on this box although I would have chosen that option if it would have been available.

Since my former SuSE experiences told me that this would mean a lot of trouble, I took notes from the beginning, once for the blog and once for my boss to show him, that most trouble doesn’t come from me being a power user used to being allowed to touch any config file (like I am on Debian).

Preparations

So I begin with the preparations: Starting the 400 MHz Debian Woody box on my desktop (whose operating system is more than a year older than SuSE 9.0 and still has security support, yeah!) I usually need to build custom Debian packages for customers. There I could chat in IRC and took notes while trying to upgrade and get the whole thing working again.

When everything was ready, I put the SuSE DVD in — just to notice, that it’s just a CD-ROM. So I put the SuSE 10.0 CD1 in the CD-ROM drive and typed “sudo shutdown -r now” in the shell. The box starts shutting down and tells me:

Please stand by while rebooting the system…

But it didn’t reboot. I waited for several minutes, nothing happend. Well, seems as if the SuSE upgrade already starts as I expect it to end: Horrible.

Read more…

Still happy with the ASUS EeePC 701 //at 16:02 //by abe

Recently Eric asked on the LUG Vorarlberg mailing list about netbook experience. I wrote a lengthy reply summarizing my experiences with the ASUS EeePC 701. And I thought this is something I probably should share with more people than only one LUG:

I ordered an ASUS EeePC 701 (4G) with US keyboard layout at digitec in Spring 2008, got it approximately one month later and posted a first resumé after one month in my blog.

I’m still very happy with the EeePC 701, despite two commonly mentioned drawbacks (the small screen resolution and the small SSD – which I both don’t see as real problems) and some other minor issues.

What matters

• Very robust and compact case. And thanks to a small fan being the only moving part inside, the EeePC 701 is also very robust against mobile use.
• Very pleasing always-in-my-daypack size (despite the 7" screen it’s the typical 9" netbook size) and easily held with one hand.
• Black. No glossy display. Neither clear varnish nor piano laquer. Short: No bath room tile. Textured surface, small scratches don’t stick out and don’t matter.
• Debian (previously Lenny, now Sid) runs fine on it, even the webcam works out-of-the-box.
• Despite all those neat features, it was fscking cheap at that time. And it was available without Windows.

Nice to have

• There’s power on the USB sockets even if the EeePC is turned off but the power supply is plugged in.
• The speakers are impressingly good and loud for their size. (But my demands with regards to audio are probably not too high, so audiophiles shouldn’t run to ebay because of this. ;-)
• It has three external USB sockets.

What doesn’t matter

• The small 7" 800×480 screen: I like small fonts and do most things inside a terminal anyway. And even with 800×480, those terminals are still much bigger than 80×25 characters. Only some applications and webpages have no heart for small screens.
• The small disk size: Quite a lot of programs fit on 4 GB of disk space. Additionally I use tmpfs a lot. And music and video files are either on a external 500 GB Western Digital 2.5" “My Passport” disk (which I need quite seldomly) or much more come via sshfs and IPv6 from my home server anyway. :-)
• The small keyboard: I just don’t have any problems with the size or layout (right shift right of the cursor up key, etc.) of the keyboard. Well, maybe except that any standard sized keyboard feels extremely large after having used the EeePC exclusively for some weeks. ;-)
• The to 630 MHz underclocked 900 MHz Intel Celeron: It’s enough for most of the things I do with the EeePC. Also the original 512 MB RAM are somehow ok, but for using tmpfs, but no swap space at all, 1 GB or 2 GB are surely the better choice.
• A battery runtime of 2.5h to 3h is fine for me.

What’s not so nice

• The “n” key needs to be pressed slighty stronger than other keys, otherwise no “n” appears. So if one of my texts in average misses more “n” than other letters, I typed it on the EeePC. ;-)
• Home, End, Page-Up, and Page-Down need the Fn key. This means that these keys can only be used with two hands (or one very big hand and I have quite small hands). This is usually no problem and you get used to it. It’s just annoying if you hold the EeePC with one hand and try to type with the other.
• What looks like a single mouse button is a seesaw and therefore two mouse buttons below one button. This makes it quite hard to press both at the same time, e.g. for emulating a middle mouse button press. It usually works in about half of all cases I tried it. My solution was to bind some key combination to emulate a middle mouse button in my window manager, ratpoison:

  bind y ratclick 2

  And that mouse button bar already fell off two times.
• The battery reports only in 10% steps, and reporting in percentage instead of mAh is an ACPI standard violation because reporting in percentage is only allowed for non-rechargable batteries. It also doesn’t report any charging and discharging rates. But in the meanwhile nearly all battery meter can cope with these hardware bugs. This was quite a problem in the early days.
• Now, after approximately 1.5 years, the battery slowly fritzes: When charging there are often only seconds between 10% and 40%. Rigorously using up all power of the battery helped a little bit. Looks like some kind of memory effect althought the battery is labeled Li-Ion and not Ni-MH and Li-Ion batteries are said to have no memory effect.
• The SD card reader only works fine if you once completed the setup of the original firmware or set the corresponding BIOS switch appropriately. No idea why.

Similar models

Technically, most of this also counts for the EeePC 900SD (not 901) which only differs in screen, resolution and disk size as well as CPU, but not on the the case. So same size, same robustness, same battery, same mainboard, bigger screen, resolution, disk and faster CPU. (The 901 has a different CPU, a different battery, and a different, glossy and partially chromed case.) See Wikipedia for the technical specifications of all EeePC models.

ASUS’ only big FAILure

Stopping to sell most EeePCs with Linux and cowardly teaming up with Microsoft after having shown big courage to come out with a Linux only netbook. Well, you probably already know, but it’s better without Windows…

So basically you no more get these really neat netbooks from ASUS anymore and you get nearly no netbooks with Linux from ASUS in the stores anymore. It’s a shame.

Would I buy it again?

Sure.

Well, maybe I would also buy the 900SD, 900AX (replacing the harddisk with an SSD) or 702 (8G) instead of the 701, but basically they’re very similar. See Wikipedia for the differences between these EeePC models. And of course I still prefer the versions without Windows.

But despite the low price, the EeePC 701 is surprisingly robust and still works as on the first day (ok, except battery, the mouse button bar and the “n” key ;-), so I recently bought a second power supply (only white ones were available *grrrr*) and ordered a bigger third party battery plus an adapter to load the battery directly from the (second) power supply without EeePC inbetween.

What desktop do I use on the EeePC?

None.

I use ratpoison as window manager, uxterm, urxvt, and yeahconsole as terminal emulators (running zsh with grml based .zshrc even as root’s login shell :-), wicd-curses as network manager and xmobar (previously dzen2) with i3status as text-only panel. Installed editors are GNU Emacs 23, GNU Zile and nvi. (No vim. :-)

And of course a netbook wouldn’t be a netbook if it wouldn’t have a lot of network applications installed. For me the most important ones are: ssh, scp, autossh, sshfs, miredo, conkeror, git, hg, and rsync.

NSLU2 in a Tux Case //at 18:23 //by abe

It started harmless when Thomas asked on Linux User Group Switzerland mailing list if someone knows a tux-shaped alarm clock. But the topic of that thread quickly moved to two other things in tux shape: the Tux Droid, a device similar to the Nabaztag, but needs a Linux host with USB, and ACME Systems’ Tux-Server, a ETRAX CRIS based Foxboard inside a tux-shaped case.

We found out that Telion, the Swiss importer for Foxboards, also imports ACME Systems’ Tux Case — although the Tux Case is not mentioned on their website. Even better: They had a few old Tux Cases in stock which don’t fit anymore on current Foxboards since the position of the power socket changed. (So only one hole in the case was missing.) And they wanted to get rid of them quite fast: They offered us the Tux Cases for 10 CHF (6€) each instead of 28 CHF each (17€) if we buy all of them. Of course we couldn’t reject this offer and bought all five remaining cases.

Another part of the thread was about performance. Although ETRAX CRIS is used by its inventor AXIS in many of its products (they’re famous for the Linux based web-cams) many were not sure if the board’s performance would be sufficient for their ideas. Another disadvantage of the ETRAX CRIS architecture is that no mainstream Linux distribution supports it.

Another point was the Foxboard’s price (169€, ca. 268 CHF). Bones just mentioned that an NSLU2 costs only about 100 CHF (60€).

Probably on IRC someone (probably Bones, too) wondered if it’s possible to fit a NSLU2 into such a quite inexpensive Tux Case. We took Wikipedia’s picture of the NSLU2 board, compared the size of the USB ports on that picture, compared them with real-life USB ports and found out the size of the board that way. And when I got my Tux-Case I noticed that the NSLU2 board really could fit into the Tux-Case.

Since I’m already building a bigger NAS-like home server, I have no use for another, much slower NAS. But since I more or less gave up the also ARM-based Thecus N4100, another ARM-based machine in my hardware collection wouldn’t be bad.

So it didn’t took long and the idea was born to build the NSLU2 board into a Tux-Case and let the website tux.ethz.ch run on it. (I inherited its administration from Beat and it’s currently just a virtual host on one of our webservers.) Then it would be a server named Tux, serving Tuxes, looking like a Tux and running Tux’ operating system Linux. :-)

I ordered an NSLU2 at Brack for 117.60 CHF (ca. 70€). Played around with the original firmware for a moment, but it’s horrible from a security point of view: You can’t even change the admin password (default: “admin”) if no USB harddisk is attached. And no, a USB stick doesn’t suffice. So I didn’t wait long and tried to install Debian’s “armel” (ARM, Little Endian) port on it. But the NSLU2 refused the “new firmware” with the error message “Upgrade: no enough free space.”. While this is not in the Debian specific NSLU2 FAQ, it is mentioned in the general troubleshooting FAQ. As described in there, first upgrading to the most recent firmware version and then uploading the Debian installer worked fine.

After I had successfully installed Debian Lenny on a pqi 4 GB USB sticked into the NSLU2 and verified that everything is working fine, I opened the NSLU2 case and checked if it really would fit into a Tux Case.

It does, but very, very close. You’ll have to drill some holes and the ethernet socket will stick out Tux’s shoulder, but everything else should fit perfectly after a few mounting parts inside the Tux Case have been removed. As a proof of concept I laid the NSLU2 board on the Tux Case’s back:

Pictures taken with my Nokia E51

So later the LEDs will be in Tux’ one shoulder while the network socket will be in his other shoulder. And the USB stick will be inside his paunch via a USB hub.