Ab und an reagieren SSH-Sessions nicht mehr und damit ist das komplette Terminal blockiert. Das liegt meist daran, das die Netzwerkverbindung unterbrochen wurde — sei es auf Grund von Netzwerkfehlern oder weil das Notebook in den Energiesparmodus gegangen ist. In solchen Fällen habe ich immer das Terminal-Fenster geschlossen, was ich ziemlich nervig fand (Stichwort: Fensteranordnung im iTerm). Irgendwann habe ich die Lösung gefunden, die ich Euch nicht vorenthalten möchte. Wenn man im Terminal-Fenster die Tasten [ENTER] [TILDE] und [PUNKT] der Reihe nach eingibt, wird die abgestürzte SSH-Session beendet und das Terminal freigegeben:

↩~.

Da ich mir das nicht merken kann bzw. mir die Tastenkombination zu kompliziert ist, habe ich damit einfach Typinator »missbraucht«

So ist es mir möglich mit der Tastenkombination »XXX« jede hängende SSH-Session zu beenden.

• Auf dem OpenVPN-Server muss IP-Forwarding angeschaltet sein

sysctl -w net.ipv4.ip_forward=1

bzw. dauerhaft in /etc/sysctl.conf eintragen.

• Ebenfalls muss das OpenVPN-Netz beim Übergang ins Internet geNATet werden. Dazu muss eine iptables Regel gesetzt werden. Diese Befehlszeile muss jedesmal ausgeführt werden, wenn OpenVPN gestartet wird, damit es funktioniert. Deswegen wird unter /etc/openvpn/firewall.sh ein Script angelegt, welches folgenden Inhalt hat.

#!/bin/sh
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Und anschließend muß noch in die OpenVPN-Konfigurationsdatei auf dieses Script gezeigt werden.

route-up /etc/openvpn/firewall.sh

Dann wird für in die clientspezifische Konfigurationsdatei in /etc/openvpn/ccd folgendes geschrieben:

push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

Ersteres weist den Client an den OpenVPN-Server als Default-Gateway einzutragen und die nächsten beiden Anweisungen geben dem Client die OpenDNS-Server als DNS-Server.

Ich habe dafür extra clientspezifische Konfigurationsdateien in /etc/openvpn/ccd abgelegt, damit man zukünftig die Wahl hat.

Wenn man öfter auf der Kommandozeile arbeitet lernt man die History-Funktion zu schätzen. Hier eine lose Aufstellung einiger Möglichkeiten, wie man die History-Funktion noch weiter aufbohren und an seine Bedürfnisse anpassen kann.
Update: Aufgrund von weiteren Recherchen und des Kommentars auf macfidelity habe ich diesen Artikel noch einmal überarbeitet und weitere Informationen hinzugefügt.

Einleitung

Die History ist eine eingebaute Funktion in dem Befehlsinterpreter bash — der Standardshell inzwischen vieler *nixe bzw. *BSDs, so auch von Mac OS X. Die History hat eingebaute Befehle, die man wunderbar im Handbuch von Bash nachlesen kann, oder in Kürze erklärt bei macfidelity findet. Das Grundverhalten der History kann man, wie auch ziemlich vieler anderer Funktionen, in den Profil-Dateien der bash definieren. Dazu möchte ich auf den Artikel Bash-Shell einrichten verweisen.

History von mehreren parallel laufenden Terminalsessions sichern

Oft genug hat man mehrere Terminalsessions zu einem Host offen um sich z.B. in der einen Session das Logfile anzuschauen, während man in anderen Session einen Befehl ausführt. Beim Beenden der Session wird aber nur eine History gespeichert. Um immer hinzuzufügen führt man folgenden Befehl aus

shopt -s histappend

History sofort speichern

Die History einer Sesion wird immer erst beim Beenden einer Session in die Datei .bash_history gespeichert. Um bei parallelen Terminalsessions auf die Befehle zuzugreifen, die gerade erst in einer anderen Session getätigt wurden, kann man mit der Umgebungsvariablen

export PROMPT_COMMAND='history -a'

die Shell dazu zwingen bei jedem Generieren eines neuen Prompts (als einer Befehlseingabezeile) die History zu schreiben.

History mit Timestamp

Um im Historyfile sich pro Befehl auch einen Timestamp hinzufügen zu lassen gibt man folgendes ein:

export HISTTIMEFORMAT='%a %T '

Die Variablen dafür kann man sich von strftime abschauen.

Größe des History-Speichers in der Datei

Wie viele Zeile die History-Datei speichern kann weiß ich zwar nicht genau (ich denke aber das es 500 Zeilen sind), aber vergrößern kann man ihn mit

export HISTFILESIZE=1000

oder aber man schaltet gleich die Größenbeschränkung aus:

unset HISTFILESIZE

Mit der Variable

export HISTSIZE=500

kann man definieren, wie viele Zeilen maximal beim Beenden einer Terminalsession in die History-Datei geschrieben werden.

Ignorieren von Befehlen

Alle eingegebenen Befehle werden in die History gespeichert. Dieses Verhalten kann man etwas einschränken, indem man Befehle, welche mit einem Leerzeichen anfangen nicht in die History aufnehmen läßt

export HISTCONTROL=ignorespace

So kann man auch bewußt Befehle nicht in die History schreiben lassen, wenn man z.B. statt »ls« einfach « ls« eingibt.

Keine Duplikate in die History

Wie oben schon beschrieben werden alle Befehle in die History aufgenommen, auch die, die mehrfach eingegeben wurden. Möchte man das nicht

export HISTCONTROL=ignoredups

Möchte man weder Duplikate, noch die mit einem Leerzeichen am Anfang, so gibt man folgendes ein

export HISTCONTROL=ignoreboth

Spezielle Zeilen von der History ausschließen

Wenn die Variable HISTCONTROL nicht gesetzt ist, kann man auch selbst entscheiden, welche Zeilen nicht in die History aufgenommen werden sollen. Dies geschieht durch die Variable HISTIGNORE, welche mit Doppelpunkten getrennt

export HISTIGNORE='cat*:cd*:vi*:ls*'

Damit werden alle Zeilen, die mit cat, cd oder vi oder ls beginnen, nicht in der History gespeichert. Es bietet sich auch an hier alle selbst definierten Aliase anzugeben. Da theoretisch hier mit regulären Ausdrücken gearbeitet werden kann, stehen der Phantasie alle Möglichkeiten offen.

Fragen über Fragen

Kennt Ihr noch mehr Befehle um die History zu »pimpen«? Ich kann mich daran erinnern, das es einen Befehl gab, mit dem man automatisch gleich nach jedem Return den Befehl in die History schreiben lassen kann — aber wie hies der nur?

Gerade bei OSX kommt man ja meist drumherum mit der Kommandozeile zu arbeiten — dabei kann man in der Shell einiges schneller bzw. einfacher machen und um gewisse Einstellungen von OSX (wie zum Beispiel hier und hier beschrieben) zu ändern kommt man nicht umher das Terminal zu öffnen.

Vorgeplänkel

Wie man im Finder oder in jedem anderen Programm zuerst seine Benutzeroberfläche einrichtet, so macht man das auch in der Kommandozeile. Nur wird das hier nicht über eine Preference File gemacht sondern über (in OSX) versteckte Systemdateien. Da OSX diese Schreiben bzw. Erstellen dieser Dateien zum Teil für den normalen Benutzer verboten hat, muss man daran denken, das man sich root–Rechte holt. Das geht einmal mit dem Account root (Zur Aktivierung des root–Accounts verweise ich auf Apple), zu dem ich mit dem Shell-Befehl

su -

oder

sudo -s

wechsle. Oder aber zukünftig jedem Befehl ein

sudo

voransetze.

Für die Individualisierung der Shell sind verschiedene Dateien und Verzeichnisse wichtig. Zuerst wird zwischen den Benutzereinstellungen und den Einstellungen für den ganzen Rechner unterschieden. Die Benutzereinstellungen liegen im Userverzeichnis, also /Users/BENUTZERNAME (Ausnahme hier ist der Benutzer root, der sein Homeverzeichnis in /root findet) und die Systemeinstellungen im Verzeichnis /etc. Wie die Namen schon sagen, sind die ersteren nur für den angemeldeten Benutzer gültig, die Systemeinstellungen für jeden Benutzer.

Individuelle Anpassungen kann man einmal für das Tastaturmapping machen — hier sind die Dateien /etc/inputrc bzw. ~/.inputrc verantwortlich und für  das Aussehen bzw. das definieren von Umgebungsvariablen — dafür sind die Dateien /etc/profile und /etc/bash.bashrc bzw. ~/.bash_profile, ~/.profile, ~/.bashrc und ~/bash_login. Eine gute Zusammenfassung der Reihenfolge der Abarbeitung der Dateien findet man hier. Der Einfachheit halber benutze ich in diesem Artikel die Datei profile.

Farben für den tristen Alltag

Mit Farben kann man sich die Shell übersichtlicher machen. Dazu hat fidel schon mal was geschrieben. Definiert werden diese in der Profil-Datei. Man kann den Prompt bearbeiten (Farbe und Aussehen).  Standard ist folgendes Aussehen

In meinem Fall brauche ich die Angabe des Rechner-Namens nicht und ein nettes Gelb kann auch nicht schaden

export PS1="\[\e[33;1;40m\][\u] \w>\[\e[0m\] "

Das Gleiche kann man auch für den Prompt definieren, wenn man mit sudo sich temporäre root–Rechte gibt. In meinem Fall möchte ich gelbe Schrift auf einem rotem Untergrund.

export SUDO_PS1="\[\e[33;1;41m\][\u] \w>\[\e[0m\] "

Das sieht jetzt alles recht kryptisch aus, was daran liegt, das die Programmierung des Prompts in Escape-Sequenzen erfolgen muss. Wenn man etwas tiefer in die Materie einsteigen will, seinen ganz persönlichen Prompt bauen möchte oder schlicht einfach verstehen will, was hier gemacht wird, dem sein pimp my shell ans Herz gelegt. Es gibt dann auch noch Informationen von IBM und Ring of saturn.

Ein oft benutzter Befehl in der Kommandozeile lautet ls zum Anzeigen eine Verzeichnisinhalts. Um die verschiedenen Inhalte wie Verzeichnisse, Dateien, Symlinks und Co. auseinanderzuhalten ist eine farbige Darstellung sehr nützlich. Dies kann man entwerder durch das Aufrufen des Befehls ls mit dem Schalter –G erreichen, oder aber, wenn man die Farben selber definieren will, mit folgenden Umgebungsvariablen

export CLICOLOR=1
export LSCOLORS=dxfxcxbxegedabagacad

Die Bedeutung der jeweiligen Optionen kann man sich hier anschauen. Für ganz Faule gibt es einen Generator.

Um dem Befehl grep etwas Farbe zu geben, muss folgende Umgebungsvariable gesetzt werden

export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'

Einfacher Zugriff auf die History

Ich hatte hier schon mal was über die Einstellungen der bash history geschrieben. Die Einstellungen dort werden in der Profil-Datei gemacht. Wie in den Kommentaren hinzugefügt benutze ich folgendes Tastaturmapping in /etc/inputrc

"e[5~": history-search-backward
"e[6~": history-search-forward

Damit kann ich mit den Tasten Bild rauf/Page up bzw. Bild runter/Page down durch die History scrollen. Das funktioniert sogar basierend auf dem, was schon auf der Kommandozeile steht. Gebe ich zum Beispiel less ein, dann werden mir mit den genannten Tasten nur die History-Einträge angezeigt, die mit dieser Buchstabenfolge anfangen.

Damit die history gleich geschrieben wird und nicht erst beim Beenden der shell session kann in der Profil-Datei mit

# Append commands to the history every time a prompt is shown,
# instead of after closing the session.
PROMPT_COMMAND='history -a'

erzwungen werden, dass mit jedem Erzeugen eines neuen Prompts die history geschrieben wird.

Leichteres Admin-Leben mit Aliasen

Standardmäßig wird dem normalen Benutzer beim Aufrufen von ls die Ansicht auf dotfiles verwehrt. Mit dem Eintrag

alias "ls=ls -a"

wird das korrigiert. Ansonsten kann man hier Programmaufrufen feste Parameter mitgeben und auch langen Befehlszeilen Kürzel vergeben.

Zusätzliches

Möchte man zusätzliche Pfad als Standardpfad einzurichten, damit man beim Aufrufen nicht den gesamten Pfad angeben muss, dann gibt man diesen wie folgt an:

export PATH=$PATH:/usr/local/src/bin

Wenn man Änderungen an den Profil-Dateien macht, dann werden diese Änderungen erst gültig, wenn die Profil-Datei erneut eingelesen wird. Das erreicht man entweder mit dem Öffnen einer neuen Terminal-Session oder aber mit dem Befehl

source ~/.profile

Fragen über Fragen

Wie sieht Eure Individualisierung der Kommandzeile aus? Welche Möglichkeiten habe ich vergessen zu erklären? Kanntet Ihr schon alle Möglichkeiten?

Ich betreibe meinen eigenen kleinen Mail-Server, auf dem auch eine Filterung nach Spams und Viren mit den OpenSource-Produkten amavisd-new und spamassassin stattfindet. Trotz alledem rutscht die eine oder andere Mail durch, was mich natürlich dazu animiert, meiner Filterkombination diese Mails noch einmal explizit als Spam vorzuwerfen, damit diese dazulernen kann. Ich möchte zeigen, wie einfach man das mit Apple Mail machen kann.

In meinem Postfach habe ich mir einen Ordner (keine Ahnung, warum das bei Apple Mail Mailbox bzw. Postfach heißt) Spam erstellt, dort werden alle unerkannten Spammails hinverschoben.

Dieser Ordner wird nun mit einem Rechtsklick/Archivieren … bzw. über das Menü Postfach/Archivieren … ins Dateisystem exportiert

Der Einfachheit halber lass ich mir den auf den Desktop legen. Im Dateisystem sieht das dann so aus

Eigentlich ist es ein Ordner mit weiteren Dateien bzw. Ordnern drin, MacOSX zeigt das aber vereinfacht als eine Datei an. Dieses Datei/Ordner-Konstrukt wird nun auf den Mail-Server übertragen — ich verwende dazu Cyberduck.

Anschließend öffnet man eine Terminalsession zu Mail-Server wechselt in das Verzeichnis, in das der Spam-Ordner kopiert wurde und verändert zuerst einmal die Zugriffsrechte des Ordners

chmod -R 777 Spam.mbox/

Anschließend wechselt man den Benutzer, da nur der Benutzer den Spam lernen kann, der auch für die Filterung zuständig ist. Bei mir heißt der Benutzer amavis

su amavis

Nun kann man den Lernprozeß anstoßen

sa-learn --spam --mbox Spam.mbox/mbox

Und erhält anschließend die Nachricht

Man kann den ganzen Export und Transferprozess auch mit einem Service automatisieren — dazu war ich bisher aber schlichtweg zu faul

Wie geht es Euch? Habt Ihr einen Spamfilter? Wenn ja, wie füttert Ihr ihn mit nicht erkannten Spammails?

Nachdem ich, wie in dem Artikel OpenWRT und eigenes Image bauen beschrieben, meine Kompilierungsumgebung für OpenWRT gebaut und mein erstes eigenes Image für meinen Router kompiliert habe, möchte ich jetzt zeigen, wie man sich ein neueres Image kompilieren kann.

OpenWRT wird ständig weiterentwickelt — Fehler werden ausgemerzt, neue Funktionen werden eingebaut. Der Quellcode, gerade in dem Trunk-Zweig, ist also in ständiger Veränderung. Es verändert sich, neben den einzelnen Paketen von OpenWRT und LuCI auch das Basissystem andauernd. Wenn man also ein neues Image erstellen will, ist es angeraten immer die neuesten Entwicklungen einzuspielen. Es kann natürlich, davor sei hier gewarnt, sein, das bestimmte Dinge nicht funktionieren — eben aufgrund der ständigen Arbeiten am Quellcode. Wenn man aber die neuesten Entwicklungen haben möchte, muss man dies bewusst in Kauf nehmen.

Nun aber zu den Abläufen. Zuerst wechseln wir (das Ganze als Nicht-Root-User) in das Verzeichnis, indem OpenWRT liegt

cd openwrt

Anschließend aktualisieren wir das Basissystem

svn up

um danach die Paketliste zu aktualisieren

./scripts/feeds update

und schließlich die aktualisierten Pakete zu installieren

./scripts/feeds install -a -p

Und schon kann man sich mit einem

make V=99

ein neues Image bauen oder aber mit

make menuconfig && make V=99

die bestehende Konfiguration verändern und anschließend neu bauen lassen.

Wer kennt das nicht? Da experimentiert man mit virtuellen Maschinen rum und jedes Mal wenn man eine VM neu installiert bekommt man die obige Fehlermeldung. Bisher habe ich mit vi in der  Datei ~/.ssh/known_hosts die entsprechende Zeile gelöscht.

Mit folgender Befehls-Zeile

sed -i -e 10d ~/.ssh/known_hosts

kann man schnell die Zeile 10 der entsprechenden Datei löschen.

Wie ich schon geschrieben hatte, bin ich ein Fan des OpenWRT-Projektes. Um die Neuerungen schneller nutzen zu können, wie zum Beispiel die Weboberfläche für OpenVPN, kompiliere ich mir in unregelmäßigen Abständen selbst eine neue Firmware um diese auf meinen ASUS-Router auszuprobieren. Ich habe aber leider nur den einen Router und mit dem Flashen und anschließendem Neukonfigurieren ist natürlich auch meine Internetleitung tot. Da man OpenWRT nicht nur auf kleinen Hardware-Routern sondern z.B. auch auf x86-Plattformen laufen lassen kann, probiere ich gerade mal aus was man machen muss um OpenWRT als virtuelle Maschine laufen zu lassen.

Zuerst muss man auf der Maschine, die die Firmware kompiliert, neben den schon beschrieben Voraussetzungen noch die Programme nachinstallieren, die nach der fertigen Kompilierung der Pakete diese als fertiges VM-Image zusammenbauen. Es gibt folgende Image-Versionen, die gebaut werden können:

Soll das fertige Image in VirtualBox laufen, dann muss folgendes gemacht werden:

Neue Quelle für APT/Aptitude

echo "deb http://download.virtualbox.org/virtualbox/debian lenny non-free" >> /etc/apt/sources.list

Herunterladen des public keys

wget -q http://download.virtualbox.org/virtualbox/debian/sun_vbox.asc -O- | apt-key add -

Aktualisieren der Paketliste

aptitude update

Installieren von VirtualBox

aptitude install virtualbox

Aber Achtung: Bei einem frischen Debian Lenny wurden 171MB heruntergeladen, da viele zusätzliche Pakete benötigt wurden.

Soll das spätere Image unter VMware laufen dann muss Qemu installiert werden:

aptitude install qemu

Nun kann mit

make menuconfig

sich wie gewünscht das Firmware Image zusammenbauen.

Am Besten arbeitet man sich von oben nach unten.

Als target system wählt man x86 aus, subtarget und target profile bleiben auf Generic. Bei target images muss man sich entscheiden, wofür man das Image braucht: VMware oder VirtualBox.

Anschließend müssen noch die OpenWRT-Pakete ausgewählt und beim Beenden des Programms die Konfiguration gespeichert werden. Danach

make

ausgeführt. Nach einer langen Zeit liegt im Unterverzeichnis bin eine Verzeichnis mit dem x86-Image. Dieses Image kann man sich auf seinen Rechner kopieren. Wie man eine virtuelle Maschine für OpenWRT zu erstellt möchte ich am Beispiel von VMware Fusion zeigen.

Mit dem Erstellen einer neuen VM öffnet sich der Assistent

Mit dem Fortfahren »Ohne Datenträger« öffnet sich eine Dialog zur Auswahl des gerade kompilierten Images

Als Nächstes gibt man das zu installierende Betriebssystem an

Anschließend kann man die Einstellungen der VM noch anpassen.

RAM

allzu viel RAM braucht OpenWRT nicht und man möchte es ja so reel wie möglich machen.

Netzwerkkarten

Hier kommt es auf die Reihenfolge an, da OpenWRT die erste Netzwerkkarte als eth0 für LAN und die zweite als eth1 für WAN nimmt.

Je nach Reihenfolge sieht die Zuordnung wie folgt aus:

Meine VM sieht abschließend so aus

Nun kann man die VM das erste Mal starten.

Nun muss zuerst die Netzwerkkonfiguration vorgenommen werden:

uci delete network.lan.ipaddr
 
uci delete network.lan.netmask
 
uci set network.lan.proto=dhcp
 
uci commit network

Nun kann man vom Host-Computer aus auf die OpenWRT-VM zugreifen.

Backup von bestimmten Dateien

Häufiger möchte man, wenn man mal schnell etwas in einer Config-Datei etwas ändert, davon fix ein Backup anlegen. Klassisch habe ich das meist schnell mit

cp DATEI.conf DATEI.conf.orig

gelöst. Was aber passiert, wenn man dann später nochmal was ändern will respektive ein neues Backup angelegt werden soll?! Wie man dieses Problem erschlägt, habe ich schon mal in diesem Artikel erklärt — das war aber nur ein Schnellschuß. Das Problem dabei ist nämlich, das man ja jeweils die alten Backups nochmal mitsichert und dadurch die Backups immer größer werden. Dies kann man durch einen Exclude-Parameter von tar auschließen. Der Befehl um in einem Verzeichnis alle Dateien zu sichern lautet also

tar -cz --no-recursion --exclude=backup-*.tar.gz -f backup-$(date +%F-%H-%M).tar.gz *

Backup von ganzen Pfaden inkl. der Unterverzeichnisse

In einigen Fällen will man nicht nur die Dateien in einem Verzeichnis sichern sondern lieber gleich den Inhalt gesamte Verzeichnis inklusive aller Unterverzeichnisse

tar -cz --exclude=backup-*.tar.gz -f backup-$(date +%F-%H-%M).tar.gz .

Backup von Dateien bzw. Pfaden, die im gesamten System verteilt sind

Und schließlich hat man den Fall, das man alle wichtigen Dateien eines Systems sichern will, die aber über das gesamte System verteilt sind. Dies erreicht man mit einer Include-Datei

tar cvzf /backup-$(date +%F-%T).tar.gz -T /etc/backup-include-dir.conf

wobei man in die Datei /etc/backup-include-dir.conf alle Pfade bzw. alle Dateien reinschreibt, die gesichert werden sollen. Wichtig ist dabei nur: Pro Datei/Pfad jeweils eine Zeile.

Und denkt daran: Solche Befehlszeilen eignen sich wunderbar dazu als alias definiert zu werden, damit man schnell drauf zugreifen kann, wenn man es mal braucht.

Ich nutze schon seit Jahren Router, die ich mit der alternativen Firmware OpenWRT betreibe. Mir geht es dabei nicht darum, das ich den Herstellern misstraue, sondern primär darum, das mir OpenWRT die Möglichkeit lässt selbst zu entscheiden, welche Dienste ich auf dem Router anbieten will und welche nicht. Dazu kommt, das die Firewall deutlich besser konfigurierbar ist und das ich mich per SSH auf den Router und über darüber gesetzte Tunnel auch auf das Netzwerk dahinter Zugriff habe. Davon einmal ganz abgesehen ist es natürlich auch gut zu wissen, das die Macher hinter OpenWRT Sicherheitslöcher stopfen — ein Verhalten, was man sich von den Hardware-Herstellern wünschen würde. Ich bin bis dato immer gut mit den Routern der Firma ASUS gefahren — zuerst hatte ich einen Asus WL-500g Deluxe, später einen Asus WL-500g Premium. Der Vorteil dieser Router: Sie haben zwei USB 2.0-Ports — da kann man z.B. Festplatten dranhängen und diese als Netzwerkplatten freigeben.

Aber zurück zu OpenWRT: Mit der neuesten Version von OpenWRT Kamikaze 8.09.1 ist aber über die Weboberfläche LuCI keine Steuerungs– und Konfigurationsmöglichkeit von OpenVPN möglich. Deswegen kann aus dem OpenWRT-Forum der Tipp, es mit der Trunk-Version von OpenWRT zu probieren. Da es diese Versionen aber nicht als fertiges Image gibt, muss man diese selbst kompilieren.

Dazu habe ich mir in einer VM ein frisches Debian Lenny aufgesetzt und mit

apt-get install build-essential mercurial subversion cvs zlib1g-dev gawk bison flex libncurses5-dev unzip

die Basis geschaffen.

Update: Also entweder hat noch nie jemand versucht meine Anleitung nachzuvollziehen, Ihr wart zu faul was zu schreiben oder aber Ihr hattet schon fertige Debian-Installationen — in der Aufzählung der benötigten Pakete fehlte noch unzip. Ich habe die Befehlszeile mal vervollständigt.

Anschließend legt man sich am besten ein neues Unterverzeichnis an

mkdir openwrt

und wechselt in dieses Verzeichnis

cd openwrt

Jetzt kann man sich die OpenWRT-Dateien herunterladen

svn co svn://svn.openwrt.org/openwrt/trunk/ .

Wichtig dabei ist, das man dies alles als normaler Nutzer macht — nicht als root.

Da die LuCI-Weboberfläche für OpenVPN nur in den Trunk-Paketen ist, müssen die Quellen für die Pakete noch angepasst werden

echo "src-svn packages svn://svn.openwrt.org/openwrt/packages" >> feeds.conf
echo "src-svn luci http://svn.luci.subsignal.org/luci/trunk/contrib/package" >> feeds.conf

Jetzt noch die Paketliste aktualisieren

./scripts/feeds update

Und die Pakete für LuCI einbinden

./scripts/feeds install -a -p luci

Und schon kann man mit

make menuconfig

das Image vorbereiten — sprich die Auswahl machen, was alles in das Image hinein soll.

Abschließend ein

make

und nach ewig langer Zeit liegt ein Imagefile in dem Unterverzeichnis bin, welches geflasht werden möchte.

Links

http://openwrt.org/

http://de.asus.com/products.aspx?l1=29&l2=172&l3=743&l4=59&model=1121&modelmenu=1

http://de.asus.com/products.aspx?l1=12&l2=43&l3=0&l4=0&model=359&modelmenu=1

http://kamikaze.openwrt.org/8.09.1/

http://www.openvpn.net/index.php/open-source.html

https://forum.openwrt.org/viewtopic.php?pid=94844#p94844