FreeDNS update mit FRITZ!Box

(This post is in german, since the router is commonly used in german-speaking countries)

Ich benutze seit längerem FreeDNS anstelle von Dyn.com oder ähnlichen Diensten, hauptsächlich weil das Update so einfach ist: einfach einen personalisierte URL per "wget" oder "curl" aufrufen und schon ist die eigene IP geändert, es wird keine spezielle Software benötigt. Dieser URL enthält eine Zeichenkette die den eigenen Account identifiziert, sie enthält aber nicht den Usernamen oder das Passwort. Somit ist es relativ ungefährlich, diesen URL in z.B. einem cronjob einzutragen: sollte jemand diesen String mitlesen, so kann er im schlimmsten Fall die IP falsch updaten, was zwar lästig aber relativ harmlos ist.

Nachdem Dyn.com küzlich die kostenlosen Accounts gekündigt hat, war das Thema FreeDNS für einige Bekannte auch aktuell, die größten Bedenken kamen allerdings daher, daß der in die FRITZ!Box eingebaute Dynamic DNS Unsterstützung FreeDNS nicht unterstützen würde. Das ist so nicht richtig:

Im Webfrontend, unter "Dynamic DNS" einfach "Benutzerdefiniert" auswählen, als "Update-URL" dann den URL einsetzen, die man in der Accountverwaltung auf http://freedns.afraid.org/dynamic/ als "Direct URL" bekommt.
Als "Domainname" wird der angemeldete Domainname eingetragen. Die FRITZ!Box prüft nach ob sich dieser auflösen lässt und meldet einen Fehler, wenn das nicht funktioniert.
Leere "Username" und "Passwort" akzeptiert die FRITZ!Box nicht, also habe ich in die Felder einfach "x" eingetragen. Fertig.

Getestet hier auf einer FRITZ!Box 7390 mit FRITZ!OS 06.03.

(Update 13.4.2014: "Domainname" ergänzt)

VDR updated to 2.0.x

I finally got around to update VDR to version 2.0.x
I'm using this version since some time and it is working fine for me. However, I'm quite sure that there are some kinks to be ironed out.
I'm not sure if updating from an old openSUSE VDR installation is a good idea or if it would be better to start from scratch. Personally, I'd do the latter and only keep my channels.conf.

The recommended way for starting VDR from systemd is now the runvdr-extreme-systemd package, the old runvdr init script is still available from the vdr-runvdr package, but is completely untested.

Configuration now happens in /etc/runvdr.conf, the old /etc/sysconfig/vdr is no longer read at all.

Normally, only the used plugins need to be added to runvdr.conf like

AddPlugin streamdev-server
AddPlugin epgsearch --logfile=/var/log/epgsearch/log --verbose=3
AddPlugin xineliboutput --local=none --remote=37890

This should be the equivalent of old sysconfig values

VDR_PLUGINS="streamdev-server epgsearch xineliboutput"
VDR_PLUGIN_ARGS_streamdev_server=""
VDR_PLUGIN_ARGS_epgsearch="--logfile=/var/log/epgsearch/log --verbose=3"
VDR_PLUGIN_ARGS_xineliboutput="--local=none --remote=37890"

The settings in runvdr.conf are commented, so the config file should be easy to understand.

If you are using vdradmin-am and are importing the old vdradmin.conf (I'd actually advise to start from scratch there, too) then you need to change the SVDR port setting to the new default of 6419 (or change the SVDRPORT variable for VDR to the old value).

The "supported" plugins are maintained in the "vdr" repository of the openSUSE Buildservice. I'm collection "unsupported" additional plugins in "vdr:plugins". The definition of "supported" right now is "the stuff that I use", simply because I cannot really test stuff that I don't use on a daily basis. Of course if someone wants to help maintain these things, I'm more than willing to move things into the main "vdr" repository.
Stuff that is in the supported repository will most likely end up in Factory and thus in openSUSE 13.2.

Bugreports via bugzilla or the opensuse-factory mailinlist, please ;-)

Nice kdump hack: get dmesg only

Last week during a kernel debugging trainig, I was asked by a participant if it would be possible to get only the dmesg of the crashed kernel, without capturing the whole crash dump.
The possibility is clear, since both current RHEL/CentOS versions as well as SLES11SP3 already put a "dmesg.txt" next to the vmcore in the crash dump directory.
But how would you achieve to get only the dmesg?
And why would one want that?
Well, the second question is easily answered: in order to deploy crash dump capturing in a large hardware pool, quite some preparation needs to be done. In my daily work, servers most of the time have more RAM than they have local disk storage, so you need to store the dumps on the network. Then you need to make sure that a large amount of crashing servers (a famous example was the leap second bug) does not fill up the storage and leads to further problems like machines not coming up again due to full storage etc. All solvable, but to be considered before deployment. If you just capture the dmesg, you can almost certainly store that locally without creating problems. Another reason would be to get the servers up again as soon as possible, while still capturing some useful information (dumping a few hundreds of gigabytes of RAM can take quite some time).

So how to do it?
SUSE's kdump infrastructure (tested on SLES11SP3) has a configuration option KDUMP_PRESCRIPT which allows to give a custom script which will be run before the crash dump is captured. This script now needs to call vmcore-dmesg and save the output somewhere for later inspection, then unmount the rootfs and issue reboot -f. Since this script never returns, the regular core-collector will not run. Problem solved.

The script is actually pretty trivial, so that it can be pasted here:

#!/bin/sh
# small script which can be used as KDUMP_PRESCRIPT in SLES
# it *only* saves the dmesg of the crashed kernel and then
# reboots immediately, *no* crash dump is saved.
# benefits:
# * get the machine up ASAP, while still collecting
#   some useful information.
# * can be always enabled without worrying about storage etc
#
# License: WTFPL v2
NOW=`date +%Y-%m-%d-%H%M`
OUT=/root/var/crash/vmcore-dmesg-${NOW}.txt
# in SUSE kdump initrd, real rootfs is mounted to /root
PRG=/root/usr/sbin/vmcore-dmesg                 # SLES12
test -x $PRG || PRG=/root/sbin/vmcore-dmesg     # SLES11SP3
$PRG /proc/vmcore > $OUT
umount /root
reboot -f       # do not continue the kdump initrd

It is slightly more complicated than absolutely necessary, but it should work in newer releases which now put the tools in /usr/sbin, too.
In my case, I saved it to /usr/local/sbin/vmcore-dmesg.sh and then changed the following in /etc/sysconfig/kdump:

KDUMP_REQUIRED_PROGRAMS="/usr/local/sbin/vmcore-dmesg.sh"
KDUMP_PRESCRIPT="/usr/local/sbin/vmcore-dmesg.sh"

After restarting kdump, the next crash gave me a nice:

sles11sp3:~ # ls -l /var/crash/
total 36
-rw-r--r-- 1 root root 33383 Mar 18 09:33 vmcore-dmesg-2014-03-18-0911.txt

and no crash dump, mission accomplished.

systemd makes boot slower

Why am I not surprised? Boot time going up from 1 minute to 4 minutes due to journald. Maybe journald is a secret plot by the SSD vendors to sell more units? :-P

Fix coolstream neo tuner voltage problem

After trying to use the EN50494 feature of neutrino-mp, I found that as soon as I attached the coolstream neo to my coax-"bus", all other receivers on the same bus could no longer tune any frequency. After quite some investigation, I found out, that the tuner does not lower the voltage to 13V if there is less than about 10mA of current load on the "LNB in" coax output.
I tried to work around the problem in software. However, that did not work too well, because if the neo was the only active receiver on the bus, then the SCR matrix would shut down if there was no voltage applied. So I checked if there is a way to simply fix the broken hardware.
There is. Next to the tuner "tin box" there is a transistor that has the 14/19V at one of its terminals. Just adding a 1.1kOhm resistor from there to ground made the voltage switch correctly even without any coax cable attached.

1.1kOhm resistor fixes tuner voltage problem

 The picture is not very good but it shows where the LNB power can be tapped.Note: use this at your own risk, soldering the resistor to the wrong terminal or shortening the wrong solder points might very well kill your box. You have been warned.
It is also very well possible that better soldering points exist, however this solution can be implemented without disassembling the box completely by just soldering on the top side of the PCB.

It would be interesting if this modification also solves the huge amount of DiSEqC switching problems that were reported last spring after some software update, it surely solved my EN50494 (aka unicable) bus blocking problem. After all the vendor has issued no statement until today, even though this clearly looks like broken (by design) hardware...

"rdmsr" implemented in perl

Today I needed the "rdmsr" tool to determine if machines are configured correctly for Hypervisor usage (VT-X enabled). Just after learning how to detect this (by looking at the cpu-checker ubuntu package), I found out that msr-tools is not available on SLES11. Instead of building the package, I just implemented a minimal version in perl (it will be integrated into a perl tool checking other aspects of the system anyway):

#!/usr/bin/perl
# License: WTFPLv2
# minimal "rdmsr" implementation
$msr = shift
        or die "need msr as parameter";
$msr = hex($msr) if ($msr =~ m/^0x/i);
open(FD, "/dev/cpu/0/msr")
        or die "open /dev/cpu/0/msr: $!";
sysseek(FD, $msr, SEEK_SET)
        or die "sysseek: $!";
sysread(FD, $reg, 8 ) == 8
        or die "sysread: $!";
$reg = reverse($reg);
$hex = unpack('H*', $reg);
$hex =~s/^0*//;
print "$hex\n";

Yes, i know, my perl is horrible :-) but maybe this is useful for someone else anyway.

Raspberry Pi: Another platform for Neutrino-MP

Last night I got video decoding via libilcore working on Raspberry Pi, so now the port of Neutrino-MP is starting to look like it will get usable some time in the future.

Most stuff is encapsulated inside libstb-hal, which means that only a small change in Neutrino-MP (just adding the proper LDFLAGS) was necessary. Later, with proper implementation / packaging of libstb-hal, this might also be unnecessary.

For those who dare to try it, I'd suggest to start with current raspbian, then use the Makefile for native building (after tweaking it to your needs) to build it directly on the Raspi -- this is how I did it :-) ). The stuff is not yet ready for cross compilation (too many hard-coded /opt/vc/lib etc).
You'll first need to build libdvbsi++ -- there's a target in the Makefile for that -- and install all missing devel packages -- hopefully, configure will compain. Otherwise the missing includes will be obvious, I guess.

The next step will be implementation of the audio decoder, which should be not too hard, then the thing will be truly useful :-) .