futterblog

VimWiki - Das Wiki-Plugin für Vim

2014-02-16T22:16:57+01:00

Ich habe vor ein paar Tagen ein neues Vim-Plugin gefunden, dass ich mittlerweile so sexy finde, dass ich es euch nicht vorenthalten möchte. Das Plugin heisst VimWiki und kann hier heruntergeladen werden. Wahlweise kann man das Plugin auch direkt aus dem Github Repository heraus installieren.

Das Plugin verwaltet verlinkte Textdateien innerhalb eines Ordners und bietet dafür allerhand nützlicher Key-Bindings. Daneben bietet es Unterstützung für Checklisten, mehrere Wikis in verschiedenen Ordnern, sowie einen HTML Renderer mit einer mitfelieferten style.css zum individualisieren.

Installation

Das Plugin herunterladen und nach /tmp/ auspacken
Die Datei vimwiki-?-?.vba mit Vim öffnen
Sourcen mit: :so %

Bedienung

Es gibt eine umfangreiche Dokumentation auf Github.

Zum öffnen der Index-Seite in Vim einfach \ww tippen.
Einen neuen Link erstellt man durch drücken von Return auf einem beliebigen Wort.
Einen neuen Artikel erstellt man durch drücken von Return auf einem Link.
Einen Artikel zurück kommt man mit der Backspace Taste.

Ein kurzer Blick lohnt sich!

Wie ich am lokalen Datenverkehr teilhabe

2013-12-28T04:39:09+01:00

Weil mir der Network-Manager vor langer Zeit einmal zu viel auf den Sack gegangen ist, bin ich auf WICD umgestiegen. Der machte mir dann aber aus verschiedenen Gründen auch nicht all zu lange Spaß. Etwa zu dieser Zeit flog mit dann zufällig ein kleines Shell-Script von 'grenouille' in die Hände, mit dem er seine diversen Netze direkt aus der Shell verwaltete.

Ich habe ein paar encfs Zeilen in das Script gehackt und es viele Jahre lang absolut zufrieden benutzt und gelegentlich ausgebaut. By popular demand ist es dann irgendwann in ein Git-Repo gewandert und veröffentlicht worden. Plötzlich benutzen Member das Script, die ich kaum bis garnicht kenne, und das finde ich super.

Das grobe Ganze

Am Laptop will man häufig das WLAN wechseln. Das soll schnell und komfortabel von statten gehen. Schnell und komfortabel heisst bei mir 'wpa_supplicant'. Alles Geläufige, was es da so drum herum gibt ist meiner persönlichen Ansicht nach... nicht ganz so überzeugend.

Der große Nachteil bei wpa_supplicant ist, dass für verschlüsselte WLANs eine Konfigurationsdatei mit dem Klartextpasswort fuer das jeweilige WLAN im Dateisystem hinterlegt werden muss. Die Dateien gehören zwar root, allerdings ist das kein großes Hindernis, wenn das Notebook mal geklaut werden sollte. Ich persönlich bin kein großer Freund davon ganze Partitionen oder gar die ganze HDD zu verschlüsseln - das schafft nur Komplexität an Stellen wo man keine haben will. Der Benefit sind zahlreiche verschlüsselte open-source Binaries und Libs, während das Betriebssystem unnötig ackern muss und ich am Ende nicht mehr booten kann, weil "Nein? Doch! Oh!".

Darum benutze ich seit Jahren encfs, um einzelne Verzeichnisse zu verschlüsseln, wo es Sinn ergibt - unter Anderem, um meine ganzen wpa_supplicant Konfigurationsdateien zu verschlüsseln. Um meine ganzen encfs Verzeichnisse besser verwalten zu können, habe ich einen kleinen Wrapper namens enconfig drum herum gehackt.

Und weil ich so verdammt faul bin, habe ich einen Bash-Alias fuer alle meine Netze, die die beiden Wrapper wrappen. :P

Einrichtung

Hier versuche ich mal eine kleine Anleitung zusammen zu stellen, um mein Setup nach zu bauen. Feedback und Verbesserungsvorschläge gerne per Mail.

enconfig

Zuerst installieren wir encfs, wpa_supplicant und enconfig. Wir brauchen den wpa_supplicant zwar noch nicht wirklich fuer enconfig, aber wir installieren ihn einfach gleich mal mit.

Als root:

aptitude install encfs wpa_supplicant
git clone git@github.com/baccenfutter/enconfig.git
ln -s $PWD/enconfig/enconfig /usr/local/bin/
ln -s /usr/local/bin/enconfig /usr/local/bin/encup
ln -s /usr/local/bin/enconfig /usr/local/bin/encdown
echo "/etc/wpa_wupplicant/.wpa /etc/wpa_supplicant/wpa" > ~/.privatedirs
encup 1

Dann erstellen wir eine erste wpa_supplicant.cfg:

ssid="access-point-ssid"  # hier die SSID des AP eintragen
encup 1
cat << EOF > /etc/wpa_supplicant/wpa/foo.conf
network={
    ssdid=$ssid
    key_mgmt=NONE
}
EOF
encdown 1

Fertig.

Net-Conf

Kommen wir zur Installation von Net-Conf.

Als root:

aptitude install python-ipaddr pip
pip install net-conf
ln -s /usr/lib/python2.7/site-packages/netconf/netconf.sh /usr/local/bin/netconf

Dann erstellen wir eine kleine Public-AP config:

netconf     # einmal durchlaufen lassen, damit das
            # Konfigurationsverzeichnis erstellt wird
cd ~/.config/net_conf
cp static-wifi-example foo.py
cd -

... und probieren sie auch gleich mal aus:

netconf foo

Runde Ecken

Jetzt einfach beliebig viel wpa_supplicant.cfgs nach /etc/wpa_supplicant/wpa/ legen und dann einen Bash-Alias für die Wichtigsten einrichten:

alias net_mywifi='encup 1 && netconf foo && encdown 1'
net_mywifi

Die meisten Orte, an denen ich mein Laptop aufklappe sind Orte, an denen ich mich häufiger aufhalten (e.g. zu Hause, auf der c-base, etc). Ich klappe mein Notebook auf und tippe 'net_cbase' und schwupps bin ich online.

# net_cbase 
Mounting /etc/wpa_supplicant/wpa
EncFS Password:

utils      killing all daemons...
utils      resetting all interfaces...
iface      ifup: wlan0
supplicant connecting: /etc/wpa_supplicant/wpa/c-base-crew.cfg
iface      ifup: wlan0
address    configuring: 10.0.x.xx/23 -> wlan0
gateway    routing via: 10.0.1.254
iface      ifup: wlan0
address    configuring: 2a02:f28:4::x:x:x:1/64 -> wlan0
gateway    routing via: 2a02:f28:4::1
resolver   resolving via: 10.0.1.254
Unmounting /etc/wpa_supplicant/wpa

Apple MagicMouse unter Gentoo/Linux

2013-06-27T20:48:23+02:00

Ich bewege mich eher in der Linux Welt und bin alles Andere als ein Apple Fanboy. Eine kleine Schwäche muss ich allerdings zugeben... die Apple MagicMouse.

Schon als ich sie das erste Mal benutzt habe, habe ich mir gesagt: "Also die, die wuerde ich kaufen." Das habe ich dann auch gestern getan. Wie gesagt, bewege ich mich allerdings eher in der Linux Welt.

Mein Setup

Lenovo T420
Gentoo (~amd64)
gentoo-sources-3.11.1
Xserver
Fluxbox
Bluetooth

Howto

Mittlerweile hat der Linux Kernel einen nativen Treiber fuer die Apple MagicMouse. Input-devices (vor allem, via BlueTooth) kompiliere ich mir in aller Regel als Kernelmodul, damit nicht mein ganzes System die Hufe hebt, wenn das Device mal spinnt.

Symbol: HID_MAGICMOUSE [=m]
Type : tristate
Prompt: Apple Magic Mouse/Trackpad multi-touch support
Location:
  -> Device Drivers
    -> HID support
      -> HID bus support (HID [=y])
(2)     -> Special HID drivers
Defined at drivers/hid/Kconfig:402
Depends on: INPUT [=y] && HID [=y]

Mit dieser Konfiguration fuer die Maus baue ich meinen Kernel dann neu und rolle ihn aus.

make
make install
make modules_install

Anschließend lade ich das Kernelmodul nach.

modprobe hid_magicmouse

Unter Fluxbox kann ich BlueMan als Bluetooth-Manager sehr empfehlen. Warum? Er funktioniert einfach out-of-the-box.

emerge -av net-wireless/blueman
echo "blueman-applet &" >> ~/.fluxbox/startup

Fertig. Nie wieder Bluetooth Gefrickel!

Den Blueman-Manager öffnet man durch Klick auf das Icon im Tray. Dann einfach auf "Suche" klicken und die Maus einschalten. Jetzt kann die Maus hinzugefuegt. Die PIN lautet "0000". Zuletzt empfielt es sich das Device auf "trusted" zu stellen, damit beim Einschalten automatisch eine Verbindung hergestellt wird.

Out of Inodes - Dateien in Verzeichnissen zählen

2013-06-27T20:48:23+02:00

Wenn die Inodes mal wieder volllaufen sollten, bin ich vorbereitet. >:]

#!/usr/bin/env python2
# -*- coding:utf8 -*-
__author__ = 'baccenfutter'
__licence__ = 'Academic Free 3.0'
__date__ = '2013-06-27'

import os
import sys


class Basedir(object):
    def __init__(self, base="/tmp"):
        """Representation of a base directory

        :param base:    str -- absolute path of base directory
        """
        self.base = base
        self.hiddenfiles = True
        self.__data = {}

    def __repr__(self):
        """repr(self) -> <Basedir|base=%s|layers=%i>"""
        return '<Basedir|%s>' % self.base

    def __get_dirs(self, base):
        """Helper for obtaining a subdirectory list

        :param base: str    -- absolute path of directory to traverse
        :returns: Generator
        """
        for d in os.walk(base).next()[1]:
            if self.hiddenfiles and d.startswith('.'):
                continue
            else:
                yield d

    def __get_files(self, base):
        """Helper for obtaining a file list

        :param base: str    -- absolute path of directory to traverse
        :return: Generator
        """
        for f in os.walk(base).next()[2]:
            if self.hiddenfiles and f.startswith('.'):
                continue
            else:
                yield f

    def __traverse(self, base, max_recursion, current=0):
        """

        :param base:            str -- absolute path of base directory
        :param max_recursion:   int -- max recursion level
        :param current:         int -- current recursion level
        """
        if current < max_recursion:
            for d in self.__get_dirs(base):
                self.__traverse(os.path.join(base, d), max_recursion, current + 1)
        elif current >= max_recursion:
            self.__data[base] = len(list(self.__get_files(base))) - 1
            for root, dirs, files in os.walk(base):
                self.__data[base] += 1

    def traverse(self, depth=0):
        """Traverse this basedir

        :param depth: int   -- maximum number of recursion, e.g. level of depth
        :return: list
        """
        if not self.__data:
            self.__traverse(self.base, max_recursion=depth)
        return sorted(self.__data.items(), key=lambda x: x[1])

if __name__ == '__main__':
    try:
        basename = sys.argv[1]
    except:
        basename = '/tmp/test'
    try:
        depth = int(sys.argv[2])
    except:
        depth = 1
    basedir = Basedir(basename)
    for d, i in basedir.traverse(depth):
        print '%8i %s' % (i, d)

IPv6 Support für OpenVZ Gäste auf Debian-basis

2013-06-09T20:50:49+02:00

Ich habe eine Weile gekämpft, um den IPv6 Support für meine OpenVZ Gäste auf einem Debian Lenny zum Laufen zu kriegen. Im Wesentlichen, ist es auch garkeine Raketenwissenschaft, wenn man erstmal weiß, wo denn genau das Problem liegt.

Meine gesammelten Erkenntnisse möchte ich euch nicht vorenthalten.

Ausgangsszenario

Zugrunde liegendes Betriebssystem ist ein Debian Lenny (funktioniert vermutlich auch mit späteren Releases), auf dem bereits grundsätzlicher IPv6 Support eingerichtet ist.

Am Einfachsten überprüft man dies mit dem Kommando:

# ip -0 a

In der Ausgabe sollten IPv6 Link-Local Adressen zu sehen sein, die mit dem Block fe80 beginnen, bspw. fe80::2a0:86ef:ff2d:93a4/64.

Selbstverständlich muss IPv6 Support auf dem Internet-Uplink anliegen und geroutet werden, unabhängig davon, ob es sich um nativen Support oder einen Tunnel handelt.

Desweiteren gehen wir in diesem Fallbeispiel davon aus, dass es auf dem Host ein physikalisches Interface eth0, sowie ein virtuelles Interface venet0 gibt, und ansonsten keine weiteren Interfaces vorhanden sind.

Der Prefix, von dem hier ausgegangen wird, lautet:

2a02:bace:bace::/48

Unser Default-Gateway ins Internet ist ein DSL-Router irgendwo im LAN. Wir folgen der Konvention und konfigurieren hier die erste Host-IP des Prefixes.

2a02:bace:bace::1/64

Konfiguration des Hosts

Wenn der IPv6 Support im Betriebssystem fertig eingerichtet ist, beginnen wir mit der Konfiguration von OpenVZ.

Hierfür editiert man die Datei /etc/vz/vz.conf und fügt folgende Zeilen hinzu:

IPV6="yes"
IP6TABLES="ip6_tables ip6table_filter ip6table_mangle ip6t_REJECT"

Anschließend muss der Daemon durchgestartet werden.

# /etc/init.d/vz restart

Auf dem Host wird irgendeine zufällige Host-IP aus unserem Prefix konfiguriert und eine Default-Route eingerichtet.

# ip a a 2a02:bace:bace::bace/64 dev eth0
# ip r a default via 2a02:bace:bace::1

Damit diese IP auch nach jedem Neustart zur Verfügung steht, muss sie in die Datei /etc/network/interfaces eingetragen werden.

iface eth0 inet6 static  
    address 2a02:bace:bace::bace  
    netmask 64  
    gateway 2a02:bace:bace::1

Ein kurzer Test, ob das Internet via IPv6 erreichbar ist und weiter geht`s.

# ping6 -c3 google.de

Damit der Host IPv6 Packete seiner Gäste forwarded, müssen einige Sysctl Parameter gesetzt werden. Diese werden am Besten direkt ans Ende der Datei /etc/sysctl.conf geschrieben...

net.ipv4.conf.eth0.proxy_arp=1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.proxy_ndp = 1
net.ipv6.conf.all.proxy_ndp = 1

... und dann geladen...

# sysctl -p /etc/sysctl.conf

Konfiguraiton der Gäste

IPv6 Adresen werden genau so konfiguriert, wie IPv4 Adressen.

# vzctl set $VEID --ipadd 2a02:bace:bace::2 --save

Host und Gast sollten sich nun erreichen können.

#host# ping6 -c3 2a02:bace:bace::2
#gast# ping6 -c3 2a02:bace:bace::bace

Pitfall

Wenn die Gäste nicht in der Lage sind das Internet zu erreichen, liegt es daran, dass die ARP-Requests, die vom Router stammen, vom Host nicht an seine Gäste weitergeleitet werden. Somit weiß der Router nicht wohin er die Antwortpackete leiten soll. Vom Gast aus stellt sich die Situation so dar, als ob es keine Route vom Host ins Internet gäbe, was aber nicht den Tatsachen entspricht. Die Route ist da, aber die Rueckroute nicht.

Damit der Host ARP-Requests, die für seine Gäste bestimmt sind, durchreicht, muss er als Neighbor-Proxy für alle seine Gäste konfiguriert werden.

# ip -6 n add proxy 2a02:bace:bace::2 dev eth0

Hierbei ist die IPv6-Adresse die des Gastes und das Device das physische Interface des Hosts.

Um auch diese Konfiguration persistent gegen Neustarts zu kriegen, habe ich ein kleines if-up Script geschrieben, das sich stumpf alle IPv6-Adressen aller Gäste holt und als Proxy konfiguriert.

Hierzu legt man die Datei /etc/network/if-up.d/ipv6vzneighproxy an und schreibt folgende Zeilen hinein.

prefix="${1:-2a02}"
ext_iface="${2:-eth0}"

guests="$(grep -r "$prefix" /etc/vz/conf/*.conf | sed 's/.*\(2a02\)/\1/' | tr '"' ' ')"
for ip in $guests; do
    ip -6 n add proxy ${ip} dev ${ext_iface}
done

Done.

NIPAP - The Neat IP Address Planer

2013-06-09T00:09:54+02:00

Schonmal mehr als nur ein einziges /24 IPv4 Netz verwaltet?

Admins mit größeren oder gar mehreren Prefixen kennen den Aufwand und die organisatorischen Probleme, die die Verwaltung solcher Adressräume mit sich bringt. Große Adressräume werden meist in Subnetze zerteilt und den verschiedensten Aufgabenbereichen zugewiesen. Um nicht alle IPs in einem großen Adressraum durcheinander zu würfeln, werden kleinere Adressräume reserviert, aus denen später bei Bedarf IPs vergeben werden. Durch die Reservierungen sollen aber keine allzu großen ungenutzten Löcher im Adressraum entstehen.

Tools für die Verwaltung von Layer-3 Netzen, gibt es unzählige.
Neulich bin ich auf eins gestoßen, dass ich sehr gerne weiterempfehlen möchte - NIPAP.

NIPAP steht für 'Neat IP Address Planer' und das Tool wird seinem Namen gerecht. In seinem Kern handelt es sich um ipaddr-py, dass mit einer praktischen Google Suchmaske versehen ist, doch nach genauerem Hinsehen entdeckt man einige richtig ausgeklügelte Features, die einem die Arbeit echt erleichtern.

Neben einem Web-Frontend, wird ein CLI mitgeliefert, was sich leicht in Scripte einbetten lässt. Zum Einpflegen von Daten, werden die Meisten wohl das Web-Frontend benutzen.

Ausprobieren

Auf Derivaten von Debian lässt sich NIPAP ohne Probleme kurz und schmerzlos anschauen. Einfach das APT-Repo hinzufuegen und installieren:

echo "deb http://spritelink.github.io/NIPAP/repos/apt stable main extra" > /etc/apt/sources.list.d/nipap.list
apt-get update
apt-get install nipapd nipap-common nipap-www nipap-cli python-pynipap

Die RPM Benutzer müssen sich ihre Packete mithilfe des mitgelieferten Makefiles selbst bauen:

cd /tmp
virtualenv nipap
cd nipap
source bin/activate
pip install docutils pypi2rpm 
git clone git://github.com/SpriteLink/NIPAP.git
cd NIPAP
make buildrpm
rpm -ivh *.rpm

NIPAP richtet wärend der Installation die benötigte Postgres Datenbank ein und legt seine Config nach /etc/nipap/.

Objekt-Typen

NIPAP kennt die folgenden Objekt-Typen:

VRF

Steht für Virtual Routing and Forwarding. Es ist das Root-Object aller Reservations. Die Meisten von euch werden hier eure AS eintragen.
Reservations

Reservations sind zusammenhängende Adressräume, die keinen bestimmten Verwendungszweck haben, wohl aber existieren. Sie dienen als Container-Objekte fuer Assignments oder andere Reservations.
Assignment

Assignments liegen immer in Reservations. Ein Assignment ist ein zusammenhängender Adressraum, der für einen bestimmten Verwendungszweck vorgesehen ist. Es besteht aus einem Prefix und einem Verwendungszweck.

Hosts

Ein Host liegt immer in einem Assignment; er hat einen Node-Namen und eine IP-Adresse.
Pools

Ein Pool ist ein weiteres Container-Objekt. Allerdings können in Pools auch nichtzusammenhängende Adressräume zusammengefasst werden. Wenn beispielsweise fuer alle Kunden-IPs die Prefixe 192.168.1.0/24 und 192.168.42.0/24 zur Verfügung stehen, so können diese im Pool 'Kunden' zusammengefasst werden.

Neue Objekte lassen sich mit wenigen Klicks und einem benutzerfreundlichen AJAX-Frontend hinzufügen. Die Bedienung ist sehr intuitiv, die Lernkurve progressiv (vorausgesetzt, man bringt das entsprechende Hintergrundwissen mit). Im Handumdrehen sind die existierenden Assignments und Hosts eingepflegt und der Admin muss sich nie wieder Gedanken um die Verwaltung seiner Adressräume machen.

Bash: Alle Childs beim Erreichen eines Timeouts toeten

2013-05-18T21:57:05+02:00

Hin und wieder kann es vorkommen, das ein Bash-Script eine oder mehrere Subshells öffnet, um diverse Jobs im Hintergrund zu erledigen. Dabei kann es aber in vielen Fällen vorkommen, dass eine der Subshells in einen Blocking-State verfällt und hängen bleibt. Das ist vor allem dann verhängnisvoll, wenn das Script automatisiert von beispielsweise CRON ausgeführt wird.

In solchen Szenarien empfiehlt es sich eine Routine zu implementieren, die beim Erreichen eines definierten Timeouts alle Subshells tötet.

Für diesen Fall bietet sich das Linux-Signal SIGALRM an. Wenn das Haupt-Script ein SIGALRM erhält, soll es alle seine Childs töten und sich mit ungleich Null beenden. So muss zusätzlich zu den Workern einfach nur eine weitere Subshell mit GNU/sleep + GNU/kill installiert werden, die nach Ablauf des Timeouts das Signal an den Hauptprozess sendet.

Hier ein Code-Schnipsel, der die Lösung erklärt:

#!/bin/bash

alarmtime=3
childs=3
parentpid=$$
childpids=()

exit_timeout() {
    echo "Alarm signal received : killing all children"
    for child in ${childpids[@]}; do
        kill -STOP $childpid &>/dev/null
    done
    exit 1
}

trap exit_timeout SIGALRM

for i in $(seq $childs); do
    sleep 4 &  # very long task that may timeout
    childpids+=($!)
done

(sleep $alarmtime; kill -ALRM $parentpid) &
alarmpid=$!

wait ${childpids[@]}
echo "Alarm never reached, children exited cleanly."
kill $alarmpid

Ich freue mich, wenn es jemandem hilft. =)