Tag Archives: HowTo

Raspberry Pi automatisch mit dem Freifunk-WLAN verbinden

Ich setze gerade diverse Mini-Knoten auf Raspberry-Pi-Basis auf, die sich für den Internet-Zugang automatisch mit dem Magdeburger Freifunk verbinden sollen.

Anleitungen zur Verbindung mit einem WPA-verschlüsselten WLAN gibt es genug. Nur leider schweigen die zur Frage, was man denn mit einem unverschlüsselten WLAN1 macht.

Schließlich bin ich doch auf Stack Exchange und auf der man page des wpa_supplicant fündig geworden. An dieser Stelle sei die notwendige Konfiguration noch einmal zusammengefasst.

Ich nutze einen USB-WLAN-Adapter von CLS mit externer Antenne; intern ist das ein RTL8191SU 802.11n WLAN Adapter,der direkt unterstützt wird.

In /etc/network/interfaces wird für das WLAN-Device (wlan0) folgendes angefügt:

Der Eintrag in /etc/wpa_supplicant/wpa_supplicant.conf sieht dann so aus:

Durch den Eintrag key_mgmt=NONE , der  meist verschwiegen wird, stellt der wpa_supplicant keine verschlüsselte Verbindung her, sondern nutzt das WLAN unverschlüsselt, wie es für Freifunk notwendig ist. In einem anderen Freifunk-Netzwerk muss natürlich die ESSID angepasst werden.

Nach einem Neustart verbindet der Raspberry Pi sich nun automatisch mit dem Freifunk-Netzwerk, sofern es erreichbar ist.

  1. zum Beispiel einem Freifunk-WLAN []

HowTo: ownCloud mit lighttpd auf Debian Jessie

Der Fortschritt macht nicht halt und dass jemand™ sich jetzt ein Fairphone mit Android drauf gekauft hat, war eine willkommene Gelegenheit sich mal eine eigene ownCloud-Instanz aufzusetzen. Debian Jessie ist zwar derzeit noch »testing« aber schon ganz gut nutzbar und da es dort fertige Pakete für ownCloud 7 gibt und eine passende VM auf dem Server zu Haus bereits lief, fiel die Wahl darauf. Ein lighttpd mit PHP lief auch schon und der Rest war auch so schwer nicht.

Im derzeitigen Stand des Paktes muss man die Datenbank für ownCloud noch selbst anlegen. Ich hab das mit phpmyadmin gemacht, wo das Debian-Paket sich selbst schon einfach in lighttpd integriert. Die Zugangsdaten gibt man später beim Einrichtungswizard vom ownCloud an.

Im ownCloud Paket ist eine Möglichkeit dokumentiert, das Paket mit lighttdp zu nutzen, die automatische Integration wie bspw. bei phpmyadmin gibt es so nicht. Der falsch vorgeschlagene Pfad in der Doku, wurde von mir gemeldet und ich hab noch ein paar Dinge ergänzt:

Der untere Teil ist aus dem Vorschlag vom Paket übernommen, nur der alias-Pfad korrigiert. Der obere Teil ist für den direkten Zugriff über eine andere Subdomain statt über den hostname des Servers und einen Unterordner. An sich steht da aber das gleiche drin. Besonderes Augenmerk sei noch auf die redirects für die sogenannten well-known URLs nach RFC 5785 gelegt, die den Zugriff mit bestimmten Kalenderprogrammen deutlich vereinfachen.

Nachtrag: Dieses Mini-HowTo unterschlägt die Einrichtung von verschlüsseltem Zugriff über HTTPS. Ich habe das weggelassen, weil es a) an anderer Stelle gut beschrieben ist und b) ich hier noch einen nginx als Reverse Proxy vor dem lighty habe, der mit diesem HowTo rein gar nichts zu tun hat. ;-)

JavaMail and TLS: Turn on the security switch!

While talking to Ge0rg about latest issues in Java TLS we stumbled upon the question whether the JavaMail API would have similar problems.

Naturally one would expect that Java’s SSL implementation is secure. However, this is not the case: Special care needs to be taken regarding Man-In-The-Middle attacks: While a certificate may turn out to be valid, you cannot be sure that it has the right origin!

The problem is known for a while and library maintainers are taking steps to avoid it. However, for compatibility reasons those features may need to be turned on.

For JavaMail version 1.5.2 the SSLNOTES.TXT says specifically:

— Server Identity

Check RFC 2595 specifies addition checks that must be performed on the server’s certificate to ensure that the server you connected to is the server you intended to connect to. This reduces the risk of “man in the middle” attacks. For compatibility with earlier releases of JavaMail, these additional checks are disabled by default. We strongly recommend that you enable these checks when using SSL. To enable these checks, set the “mail..ssl.checkserveridentity” property to “true”.

Here is the thing that most examples forget: You need to switch that feature on!

To use SSL at all, you need to turn it on, either by specifying “imaps” in the property mail.store.protocol or by setting mail.imap.starttls.enable to “true”. Replace imap respectively for other protocol suites (e.g. smtp).

Update 2014-08-05: Inserted the Link to Georg’s blog post about latest issues in Java TLS.

HowTo: gitolite auf Debian Wheezy

Das Netz ist natürlich voll von HowTos zum Thema gitolite, in diesem hier nutze ich aber nicht die bleeding edge Version von upstream sondern das Debian-Paket. Eine gewisse Hilfe für’s Verständnis und bei der Installation war die Dokumentation für gitolite 2.x, denn in Wheezy ist Version 2.3 verpackt.

Installation

Geht los mit Installation des Pakets gitolite. Wenn der bei der Installation dpkg nichts konfiguriert haben will, dann gibt man danach nochmal ein:

Dort wird dann ein SSH public key abgefragt für den Admin-Nutzer. In meinem Fall hab ich hier für die Testinstallation auf dem selben Rechner den folgenden Pfad angegeben, ansonsten kopiert man seinen public key ins Eingabefeld:

Damit liegt jetzt hier unterhalb von /var/lib/gitolite1 folgendes:

Da mein public key bereits hinterlegt ist, kann ich direkt zum nächsten Schritt übergehen und das Admin-Repo clonen, welches bei der Installation angelegt wurde:

Wie man sieht, hatte ich den dedizierten Nutzer gitolite genannt, für Produktionsumgebung ist vielleicht git eine bessere Wahl.

Ganz wichtig: beim Ändern der Config muss man stets drauf achten, dass man sich nicht selbst aussperrt. Für das Repository gitolite-admin muss man Schreibrechte für irgendeinen Key behalten, auf den man auch Zugriff hat und der unterhalb von keydir im Repo liegt, sonst hat man keine Möglichkeit mehr ohne große Schmerzen diese Rechte wiederzuerlangen.

Konfiguration

Als nächstes habe ich die Datei /var/lib/gitolite/.gitolite.rc angepasst. Berücksichtigt sind hier bereits, dass ich sowohl git-daemon als auch gitweb einsetzen und die Repos auf einen anderen Rechner spiegeln will. D.h. ich habe folgende Einträge geändert:

Der letzten Zeile ist erhöhte Beachtung zu schenken. Die bereits angelegten Repositories gitolite-admin und testing aus /var/lib/gitolite/repositories müssen nämlich in den geänderten Pfad verschoben werden.2 Damit der Zugriff über gitweb funktioniert, habe ich den Nutzer www-data der Gruppe git hinzugefügt und die Rechte des Repository-Verzeichnisses gelockert:3

Die eigentliche Konfiguration erfolgt dann wie bei gitolite üblich über das admin-Repository nachdem man es geklont hat:

Wie man das im Einzelnen macht, kann man in der Doku zu gitolite v2 nachlesen. Das ist nicht Debian-spezifisch.

gitweb mit lighttpd

Für einen schnellen Überblick mit dem Webbrowser ist das Paket gitweb installiert. Als Webserver kann vermutlich irgendein Webserver dienen. Für lighttpd habe ich eine Datei /etc/lighttpd/conf-available/80-gitweb.conf angelegt und mit den für diesen Browser üblichen Mechanismen aktiviert. Der Inhalt sieht so aus:4

Es ist außerdem das Modul 10-cgi.conf zu aktivieren:

In der /etc/gitweb.conf sind auch noch Anpassungen zu tätigen. Hier meine geänderten Zeilen:

Urspünglich war jetzt hier noch eine Beschreibung zum Mirroring, ich verschiebe das auf später und tu es in einen separaten Artikel … O:-)

  1. auch den Pfad kann man beim dpkg-reconfigure angeben. []
  2. Dieser Schritt kann natürlich entfallen, wenn man die Repositories im Standard-Pfad belässt. []
  3. Die Rechte der bei der Installation angelegten Repositories sind allerdings immernoch so restriktiv, dass sie nicht über gitweb angezeigt werden können. Bei <code>gitolite-admin</code> will man das sowieso nicht und statt <code>testing</code> legt man sich vielleicht ein weiteres Testrepository an, um zu sehen, ob das mit den Rechten beim neu anlegen richtig klappt. []
  4. Siehe auch gitweb im ArchWiki. []

Port based VLAN mit Netgear GS108Tv2

Wir bauen im Netz39 gerade das Netzwerk ein bisschen um und wollen dabei auch mehrere logisch getrennte Netze einrichten. Die Routerhardware hat genau zwei Netzwerkkarten und kann nicht mehr bekommen, aber der Switch kann VLAN. D.h. was ich prinzipiell gern aufbauen möchte, ist etwa folgendes:

vlan

VLAN auf dem Router konfigurieren ist mit fli4l kein Problem, aber der Switch in meinem Testsetup1 hat mich grübeln lassen. So ging es dann. Erstmal die VLANs unter VLAN Configuration anlegen, hier mit den IDs 11 und 22:

netgear_vlan_1

Dann kommt sozusagen die Einrichtung des ausgehenden Verkehrs unter VLAN Membership. Hier wollen wir den Netzwerkverkehr aus den VLANs 11 und 22 beide auf dem Port zum Router haben und dort sollen die Tags drin bleiben, damit der Router das auch wieder aufdröseln kann. Deswegen wird Port 2 am Switch für beide VLANs mit T markiert, damit der Verkehr auf dem Port getaggt wird.2 Bisschen umständlich ist es, dass man jedes VLAN einzeln auswählen und dann unten noch die Liste mit den Ports aufklappen und alles einzeln bestätigen muss.3 Für den Netzwerkverkehr zu unseren dummen Geräten, die kein VLAN können oder davon nichts wissen sollen, lassen wir den Switch die Tags entfernen, markieren also die Ports 6 bis 8 mit U wie untag, was aber dennoch heißt, dass der Verkehr aus diesen VLANs über diese Ports rausgeht. Das sieht dann hier so aus:

netgear_vlan_2

… und …

netgear_vlan_3

Jetzt müssen wir uns noch um den eingehenden Verkehr kümmern, also das was ohne VLAN-Tag in den Switch gelangt. Dazu geht man auf Port PVID Configuration und kann dort dann einem Port genau ein VLAN zuordnen:

netgear_vlan_4

Ich hoffe, ich hab das alles richtig verstanden und keinen Quatscht jetzt hier erzählt. Es scheint aber zu funktionieren.

Update: Wenn man sich die PVID-Konfiguration nochmal ansieht, so wird Traffic auf den Ports 1 bis 5, der kein Tag hat, der VLAN-ID 1 zugewiesen. Da per default auf allen Ports U aka untag für die ID gesetzt ist, verlässt also ungetagter Verkehr von allen Ports den Switch auf allen Ports wieder. Was man jetzt vermutlich will: auf den Ports 6 bis 8 das U bei VLAN-ID noch rausnehmen, damit da wirklich nur Traffic des jeweiligen VLANs ankommt, und nicht noch der andere Traffic auch noch.

  1. welches leider nicht der Switch ist, der später auch Verwendung finden wird. []
  2. Das was wir hier mit Port 2 gemacht haben, also Tags von verschiedenen VLANs in den Paketen belassen, wird an einigen Stellen im Netz als VLAN-trunk bezeichnet. []
  3. Wegen so dämlichem UI gibt es solche HowTos … []

Wireshark als normaler Nutzer ausführen

Mit jedem neuen Rechner und damit jeder neuen Installation kommen jedesmal die gleichen Probleme auf einen zu. Aktuell hab ich hier im Büro eine neue Maschine mit Debian Wheezy und ich will Wireshark als normaler Nutzer ausführen. Laut /usr/share/doc/wireshark/README.Debian muss dumpcap installiert sein und richtig eingerichtet und man muss selbst der Gruppe wireshark angehören. Das genannte Tool ist Teil des Pakets wireshark-common und das lässt sich wie folgt umkonfigurieren:

Es öffnet sich ein Menü, man stellt das gewünschte ein. Nutzer zur passenden Gruppe hinzufügen mit Debian-Mitteln sieht dann so aus:

Ausloggen und neu wieder einloggen, damit die Gruppenberechtigungen wirksam werden und dann tut das.

HowTo: GnuPG mit unbegrenztem Signing-Key und ablaufendem Encryption-Key

Sperrig, die Überschrift, also worum geht’s? Ich zitiere mal aus dem GnuPG-Handbuch:

Wenn Sie ein neues Schlüsselpaar erzeugen, werden standardmäßig ein DSA-Hauptschlüssel zum Unterschreiben und ein ElGamal-Unterschlüssel zum Entschlüsseln erzeugt. Dies ist von Vorteil, weil die Aufgaben der beiden Schlüssel verschieden sind und es sinnvoll sein könnte, den beiden Schlüsseln verschiedene Verfallsdaten zu geben. Der DSA-Hauptschlüssel wird benutzt, um digitale Unterschriften zu leisten, und er bestätigt Ihre Identität dadurch, daß andere ihn signiert haben. Der ElGamal-Unterschlüssel wird nur benutzt, um an Sie geschickte verschlüsselte Daten zu entschlüsseln. Typischerweise sollte eine digitale Signatur eine lange oder unbegrenzte Gültigkeitsdauer haben; Sie wollen ja auch die Unterschriften auf Ihrem Schlüssel, die Sie mühsam zusammengetragen haben, nicht verlieren. Andererseits sollte der ElGamal-Unterschlüssel in gewissen Zeitabständen gewechselt werden, um Ihre Datensicherheit zu erhöhen, da ein Angreifer, wenn der ElGamal-Unterschlüssel geknackt ist, alle Dokumente lesen kann, die für diesen Schlüssel verschlüsselt worden sind oder es noch werden.

Darauf folgt noch ein kurzer Hinweis, dass das etwas umständlich ist, aber wie genau man das anstellt, ist quasi als Hausaufgabe überlassen und deswegen1 zeige ich das jetzt hier.

Zunächst erstellt man sich einen Schlüssel ohne Ablaufdatum, der Wizard packt sonst auf beide Unterschlüssel ein Ablaufdatum und das wollen wir ja eigentlich nicht:

Heutzutage ist das kein DSA/ElGamal-Paar, sondern beides sind RSA-Schlüssel, aber Details kann man in einem beliebigen HowTo zur Schlüsselerstellung nachlesen. In meinem Fall hab ich zu Testzwecken das hier erhalten:

Als nächstes bearbeite ich diesen Schlüssel:

Hier gibt es jetzt eine Reihe von Befehlen, die man sich mit help anzeigen lassen kann. Zunächst ist list ganz hilfreich. Die Ausgabe davon:

Den Unterschlüsseln ist ein »sub« vorangestellt, allerdings nicht nummeriert. Man wählt nun den Encryption-Key aus mit key 1 oder wenn man bereits mehrere Unterschlüssel hat, muss man durchzählen, die sind freundlicherweise geordnet. GnuPG markiert den soeben ausgewählten Unterschlüssel mit einem Sternchen:

Der nächste Befehl ist expire. Zuvor kann man sich mit list nochmal überzeugen, dass auch nur der Unterschlüssel ausgewählt ist. GnuPG ist an der Stelle aber so freundlich bei der Nachfrage nochmal klar zu stellen, dass man nur das Ablaufdatum des Unterschlüssels ändert. Sieht dann so aus:

Hier sieht man jetzt, dass der Key, dem das »pub« vorangestellt ist und bei dem es sich um den Signing-Key (SC) handelt, immernoch kein Verfallsdatum hat, der Encryption-Key (E) hingegen schon.

Bis hier hin wäre das das Vorgehen, wenn man sich einen neuen Schlüssel erstellt oder bereits einen hat, der bisher kein Ablaufdatum hat. Hat man seinen Schlüssel bereits auf einen Keyserver geladen, empfehle ich nicht am Ablaufdatum rumzufummeln. Solche Änderungen kommen womöglich nie beim Gegenüber an. Dann lieber neuen Schlüssel machen.

Was nun, wenn der Encryption-Key droht abzulaufen? Man fügt mit addkey einen neuen hinzu. GnuPG fragt dann nach allerlei Details, u.a. wie lange der neue Unterschlüssel gültig sein soll. Bei der Frage, was für ein Unterschlüssel es werden soll, wählt man einen für »nur verschlüsseln« und dort sinnvollerweise die Variante RSA mit der vorgebenen oder einer größeren Schlüssellänge:

Hier hab ich jetzt gleichzeitig zwei gültige Encryption-Keys, aber das diente ja nur zum Zeigen und Ihr werdet den Key auch auf keinem Keyserver finden.

Mit save verlässt man den Editiermodus und dann lädt man den mit neuem Encryption-Key versehenen Schlüssel wie gewohnt auf den Keyserver hoch.

Übrigens habe ich meinem eigenen PGP-Schlüssel mit dieser Methode auch gerade einen frischen Encryption-Key spendiert. Falls sich Euer Mailprogramm beschwert, dass Ihr mir keine verschlüsselten Mails mehr schicken könnt, ladet Euch mal meinen aktuellen Public-Key! ;-)

  1. und weil ich Frank Lanitz das mal auf einer Keysigningparty bei den Chemnitzer Linux-Tagen versprochen hatte, ach und wegen der im Netz39 bevorstehenden Keysigningparty, na und natürlich, weil der Encryption-Key bei mir bald abläuft … []

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:

Und im Space:

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:

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:

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.

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:

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: