Sessionname in Statuszeile von GNU screen

Grml ist das Live-Linux meiner Wahl für allerlei Zwecke. Das coole ist die Config, die dort für Zsh, Vim und GNU screen mitgeliefert wird und da ich wenig Lust hab, mir sowas selbst zusammenzubasteln und ich ebenso gern ein vertrautes Nutzerinterface habe, nutze ich die Configs auch auf anderen Rechnern, indem ich dort einmal grml-config.sh ausführe und dann nur noch kleine Anpassungen machen muss.

Screen benutze ich ausgiebig und meistens mit mehreren sessions und ab und zu kommt man da mal durcheinander. Deswegen habe ich die .screenrc jetzt doch mal ein bisschen angepasst und statt

  caption always "%{+b rk}$USER@%{wk}%H | %{yk}(load: %l)  %-21=%{wk}%D %d.%m.%Y %0c"

steht da jetzt bei mir

  caption always "%{+b rk}$USER@%{wk}%H | %S | %{yk}(load: %l)  %-21=%{wk}%D %d.%m.%Y %0c"

und dank des zusätzlichen Parameters %S hab ich die aktuelle Session direkt im Blick. :-)

HowTo: KMail wechselt Online/Offline je nach Netzwerkverbindung

Einige Probleme lassen sich schnell lösen. Zum Beispiel, dass KMail versucht, E-Mails abzuholen, selbst wenn es keine Netzwerkverbindung gibt.

Über den DBus lässt sich jede KDE-Anwendung fernsteuern, sofern die entsprechenden Interfaces angeboten werden. Mit dem Aufruf von

qdbus org.kde.kmail /KMail

erhält man eine Übersicht der Methoden, die KMail anbietet. Darunter sind auch stopNetworkJobs und startNetworkJobs – genau das, was wir brauchen.

Über die Toolbox des Network Managers, speziell nm-tools, ist es möglich, den Netzwerkstatus zu ermitteln. Jetzt fehlt nur noch ein kleines Script, das je nach Vorhandensein einer Netzwerkverbindung KMail in den Online- bzw. Offline-Modus versetzt.

#!/bin/bash

if [ `nm-tool|grep State|cut -f2 -d' '` == "connected" ]; then
       #Whatever you want to do if the network is online
       echo "Starting KMail network jobs"
       qdbus org.kde.kmail /KMail org.kde.kmail.kmail.resumeNetworkJobs       
else
       #Whatever you want to do if the network is offline - note, this and the else above are optional
       echo "Stopping KMail network jobs"
       qdbus org.kde.kmail /KMail org.kde.kmail.kmail.stopNetworkJobs
fi

Diese Script wird in der Ereignisverwaltung des Network Managers beim Ereignis “Schnittstellenstatus geändert” eingetragen und setzt nun den KMail-Status abhängig von der Verfügbarkeit einer Netzwerkverbindung.

Die Lösung ist sehr einfach, behebt aber die Fehlermeldungen und ist ein Ausgangspunkt für weitere Verbesserungen.

Nachtrag: Schöner wäre es, wenn KMail die Jobs beenden würde, bevor die Verbindung abbricht. Wer spontan einen Ansatzpunkt hat, bitte ab in die Kommentare damit.

Nachtrag2: Eigentlich brauchen wir eine Internetverbindung, d.h. streng genommen müsste ein Internet-Zugriff ausgeführt und dann abhängig vom Erfolg der KMail-Status gesetzt werden.

HowTo: FreeBSD als HVM-DomU in Xen auf Debian Wheezy

Zu Hause und im Netz39 e.V. läuft je ein Server mit Debian Wheezy auf amd64 und als Virtualisierungssystem wird Xen benutzt. Linux-Gäste werden paravirtualisiert und das läuft schon seit Jahren fluffig. Für bestimmte Zwecke muss es aber auch mal ein anderes System sein und das ist im Hackerspace ein aktuelles FreeBSD 9.1 und zu Hause ein Debian GNU/kFreeBSD, also kein Debian GNU/Linux, sondern eben das Debian mit dem ganzen GNU Userland und einem FreeBSD-Kernel. In beiden Fällen ist auch die VM die 64-Bit-Variante und die Hardwarevirtualisierung der jeweiligen Prozessoren soll genutzt werden. Was fehlt: die initiale Config für die VM und da hab ich gesucht, recherchiert und probiert und präsentiere jetzt, was bei mir funktioniert hat. Zu Hause sieht’s so aus:

vcpus = 2
memory = 1024
name = 'kleopatra'
builder = 'hvm'
kernel = 'hvmloader'
disk =  [
                'phy:/dev/mapper/heaven-kleopatra,hda,w',
                'file:/home/alex/debian-7.1.0-kfreebsd-amd64-netinst.iso,hdc:cdrom,r',
        ]
boot = 'dc'
vif = [ 'mac=00:16:3E:XX:XX:XX,bridge=xenbr0' ]
vfb = [ 'type=vnc' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

Und im Space:

vcpus       = 1
memory      = 512
name        = 'hydrogen'
builder     = 'hvm'
kernel      = 'hvmloader'
disk        = [
            'phy:/dev/mapper/vgmarx-wasserstoff,hda,w',
            'file:/media/images/FreeBSD-9.1-RELEASE-amd64-disc1.iso,hdc:cdrom,r',
          ]   
boot        = 'dc'
vif     = [ 'mac=00:16:3E:XX:XX:XX,bridge=xenbr0' ]
vfb     = [ 'type=vnc' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

In beiden Fällen hatte ich zuvor Xen nach der Anleitung im Debian-Wiki aufgesetzt. Die XX in den Mac-Adressen sind durch zufällige Werte zwischen 00h und FFh zu ersetzen. Die Erzeugung von Zufallszahlen und die Umrechnung ins Hexadezimalsystem überlasse ich als Hausaufgabe.

Nach dem Start der DomU macht man einen SSH-Tunnel auf für den VNC-Port und verbindet sich mit seinem bevorzugten VNC-Client1 auf localhost:

ssh -L 5900:localhost:5900 yourxenhost

Nach der Installation in der Config die Bootreihenfolge anpassen bzw. das CD-Image rausnehmen, fertig.

  1. unter KDE benutze ich krdc, auch wenn ich den Namen grauslig finde []

echo echo echo

Der Netzwerkdienst echo ist laut allwissender Müllhalde im inetd implementiert. Muss man wissen. Und dann muss man noch wissen, wie der aktiviert wird, ist er per default logischerweise nicht. Unter Debian Wheezy mit dem inetd aus dem Paket openbsd-inetd fügt man an geeigneter Stelle folgende Zeile zu /etc/inetd.conf hinzu:

echo    stream  tcp     nowait  root    internal

Nicht mehr mein Betriebssystem

Gerade eben, Büro: Build-Umgebung für Mikrocontroller auf Embedded Device angeworfen. Dort holt ein selbst geschriebenes Perl-Skript die Versionsinformationen aus dem Mercurial und erzeugt daraus eine Datei version.h, die beim Build eingebunden ist, so dass eine Versionsnummer im fertigen Binary landet. Automatisch. Ging immer. Eben nicht.

Es hat mich eine halbe Stunde gekostet rauszufinden, dass nicht mehr wie üblich das von mir installierte Strawberry Perl aufgerufen wird, sondern ein von MinGW mitgeliefertes, dem (mindestens) ein Modul fehlt, welches in meinem Skript genutzt wird.

Abhilfe schaffte die Umsortierung der Einträge in einer der Variablen %PATH% in den Umgebungsvariablen, damit mein Perl vor dem von MinGW gefunden wird. Dass das zusätzliche Perl übrigens bei MinGW dabei war und nicht in einem der anderen Pfade versteckt war, war übrigens nur gut geraten. Vermutlich gibt es noch mehr Perl-Instanzen, die irgendwelche Software hier mitgebracht hat. Unter Windows muss ja jeder immer wieder extra seinen eigenen Scheiß mitbringen.

Mal sehen, an wieviel anderen Stellen das später knallt. Wer den entsprechenden Dialog in Windows XP sofort findet und bei der (unter Entwicklern) üblichen Anzahl von zweistelligen Einträgen auch noch ohne Copy’n’Paste in externen Editor bearbeitet, werfe den ersten Stein.

Bei Linux gibt es ein Perl und in $PATH stehen maximal 5 Ordner.

Links klicken in Icedove Mail

Debian Stable und aktuell Wheezy ist das System, was ich auf meinen Rechnern benutze und die Thunderbird-Variante Icedove ist da auf Version 17.x und damit gibt es ein Problem: Icedove hält sich so gar nicht an eine der üblichen Varianten um einzurichten welche Anwendung sich öffnen soll, wenn man einen Link anklickt, nicht an die KDE-Mechanisem (eigentlich logisch), nicht an die vom System und nicht mal an seine eigenen. Konkret muss man über preferences → advanced → general → config editor an die Innereien ran. In den Optionen network.protocol-handler.app.http[s] steht hier x-www-browser was üblicherweise ein symbolischer Link ist, der auf /etc/alternatives/x-www-browser zeigt und das bedeutet auf Debian-basierten Systemen, dass man das über

sudo update-alternatives --config  x-www-browser

einstellen kann. Bei mir steht das auf iceweasel, aber Icedove öffnete alle Links mit Google Chrome. :-(

Ich hatte das vor längerer Zeit mal auf der deutschen Debian User Mailingsliste gefragt, aber die passende Antwort da im Archiv zu finden, ist umständlich und ich stand jetzt auf einem anderen Rechner vor dem selben Problem und hab’s ohne im Archiv zu suchen dann genauso gemacht:

network.protocol-handler.warn-external.http[s]

hab ich dann auf true gesetzt und bekam dann einen Auswahldialog. Was ich da auswähle taucht dann in den Preferences unter attachments → incoming auf, wo es vorher jedoch nicht stand. WTF?!

Also ganz ehrlich, egal wer sich das ausgedacht hat bei den Entwicklern, den würde ich gern mal persönlich sprechen! *motz*

Link

meanwhile in Frankreich: Frankreich setzt auf freie Software an den Hochschulen

:-)

HowTo: DSL-Router loggt zu rsyslog auf Debian Wheezy

Gestern schrieb ich, wie ich mal eben schnell Daten sammle wie oft mein Router sich neu verbindet. So ganz elegant ist das nicht, weil es quasi am Router vorbei geschieht und der Router ja selbst am besten weiß, was er tut. Das vorliegende Modell kann den Output seines syslog an einen anderen Server schicken und da wertet man dann direkt die Logs aus, nur wie macht man das, wenn der Server ein rsyslog auf einem Debian Wheezy ist?

Zunächst aktiviert man mal die Funktion, dass der syslog überhaupt Nachrichten von anderen annehmen soll. Das passiert in /etc/rsyslog.conf und es sind die Zeilen auszukommentieren, die die entsprechenden Module laden.

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

Ich hab der Einfachheit mal beide aktiviert, weil ich nicht wusste, was der Router probieren wird. Dann wollte ich, dass alle Logmeldungen des Routers in einer Datei landen und nicht zwischen die normalen Log-Dateien des Systems mit dem rsyslog geraten. Wichtig ist, dass hier rsyslog 5.8.11 arbeitet und daher die Änderungen an der Config-File-Syntax bei v6 und höher, die upstream in der Doku beschrieben sind, noch nicht gelten. Mit ein bisschen manpage, HowTo, Wiki und dergleichen lesen und etwas Rumprobieren, habe ich dann folgendes in die neu angelegte Datei /etc/rsyslog.d/remote.conf geschrieben:

$template PathWithHostName, "/var/log/remote/%HOSTNAME%.log"
:source, !isequal, "falbala"    -?PathWithHostName
& ~

Ich schmeiße quasi alles, was nicht vom loghost “falbala” kommt, auf dem der rsyslog läuft, in einen Unterordner remote und in nach dem Host getrennt, wo es herkommt. Jetzt muss ich nur noch ein paar Tage Daten sammeln und dann hab ich ein bisschen Statistik in der Hand, die hoffentlich ausreicht damit mein ISP eine sofortige Kündigung akzeptiert …

Nachtrag: Damit das Log nicht irgendwann überläuft, empfiehlt es sich auch noch logrotate anzupassen. Ich habe dazu /etc/logrotate.d/rsyslog als Beispiel für eine separate /etc/logrotate.d/rsyslog-custom genommen und das dort eingetragen:

/var/log/remote/*.log {
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Externe IPv4-Adressen sammeln

Im Beitrag online oder O₂ drüben in meinem privaten Blog habe ich mich bereits über meinen neuen DSL-Anschluss ausgelassen. Was ich dort nicht schrieb: die Leitung ist nicht nur langsam, sondern es bricht auch regelmäßig die Verbindung ab. Damit ich bei zukünftigen Auseinandersetzungen mit meinem Provider ein paar Daten in der Hand hab und um selbst mal zu sehen, wie oft sich der Router am Tag neu einwählt, habe ich jetzt einen Cronjob laufen, der alle 5 Minuten die von außen sichtbare IPv4-Adresse holt und erstmal in ein CSV-File speichert. Sieht so aus:

#!/bin/sh
UTCNOW=$(date -u +%s)
CURRENTIP=$(wget -q -O - checkip.dyndns.com | sed -e 's/^.*<body>\(.*\)<\/body>.*$/\1/' | cut -f2 -d: | tr -d [:space:])
echo "${UTCNOW},${CURRENTIP}"
exit 0

Und weil ich das praktisch finde, hab ich’s auch zu GitHub Gist getan.

alex

2013-06-13

Dieses Blog ist quasi umgezogen, man sieht nur nichts davon. ;-)

Genau genommen, haben wir es vom alten Server gerettet und in eine frische WordPress-Netzwerk-Installation verfrachtet, d.h. es gibt jetzt nur noch eine Installation für die vielen Blogs auf dem selben Server, das was früher WordPress MU hieß. Es ist noch Finetuning nötig, aber wenigstens der Text aller alten Beiträge ist wieder erreichbar. In diesem Sinne: bitte gehen Sie weiter, es gibt hier nichts zu sehen …