Qbi's Weblog

Michael Piotrowski hat auf der Linux Kernel Mailingliste einen Ratgeber zum Kerneltest veröffentlicht. Auf 68 Seiten werden recht hilfreiche Tips gegeben. Es lohnt sich, da mal reinzuschauen.

Enrico Zini hat ein Programm entwickelt, dass u.a. die Daten von Debian Poncon auswertet und daraus ein paar nette Informationen macht. Das Paket heißt ept-cache. Mittels der Kommandozeile ept-cache search -t clean -s t- | less kann man sich Anwendungen anzeigen lassen, die man selbst nutzt und andere nicht unbedingt installiert haben. Hier sind meine Programme:

1. newsbeuter: Das ist mittlerweile mein Lieblings-RSS-Reader.
2. signify: nutze ich, um eine zufällige Signatur unter meine E-Mails und Usenetbeiträge zu rezeugen
3. scid: brauche ich, um meine Schachpartien zu verwalten. Schön wäre es, wenn es einen Mailclient gäbe, mit dem man die Schachpartien versenden kann.
4. mixmaster: eine Remailersoftware, hat wohl mit meinem Projekt zu tun
5. lbdb: little brothers database, verwaltet diverse E-Mailadresse
6. nload: Anzeige der Netzlast auf einem Interface
7. djview: zum Betrachten von DjVu-Dateien
8. tsocks
9. feh: ein wunderbarer Bildbetrachter
10. tor

Wenn ich mal in der Liste die rein grafischen Programme suche, sieht es wie folgt aus:

1. scid
2. djview
3. icewm: mein Lieblings-Fenstermanager
4. dillo: mit einigen Einschränkungen mein Lieblingsbrowser
5. pidgin: war früher gaim
6. digikam: Verwaltung und Herunterladen der Bilder von der Digitalkamera
7. auctex: LaTeX-Umgebung für Emacs, momentan nutze ich für LaTeX eher jed
8. vim-gtk: Das Paket kann eigentlich weg. Den Gtk-vim nutze ich eigentlich nie.
9. xine-ui
10. gv: Betrachter für PostScript- und PDF-Dateien

via Bart’s Blog

Ich habe in meinem $HOME-Verzeichnis relativ verstreut diverse SVN-Verzeichnisse liegen. Das ist Software, die ich als SVN-Version nutze oder Vorlesungsmitschriften und z.T. auch Einstellungen (also Verzeichnisse mit einem Punkt am Anfang). Mein Ziel war ein Skript, was alle diese Verzeichnisse findet und dann dort ein svn update macht. Der letzte Punkt ist eher trivial. Als schwierig erwies sich das Finden der entsprechenden Verzeichnisse.

Meine erste Idee war, das Programm find zu nutzen. Mit der Zeile find $HOME -type d -name .svn erhalte ich alle Verzeichnisse, die .svn im Namen tragen. Im speziellen aber auch alle SVN-Unterverzeichnisse, die das Skript dann nicht benötigt. find hat ja noch die Option -maxdepth. Aber in diesem Falle bringt die mich nicht weiter. Nach einigem Überlegen kam ich dann dazu, die Ergebnisse an eine wilde Mischung aus sed und grep zu verfüttern. Irgendwie war das Ganze aber immer noch unbefriedigend und ich hätte lieber eine Shelllösung gehabt. Glücklicherweise war Stammtisch der LUG und ich diskutierte dort das Problem.

Nach einigem Hin und Her kamen wir dann auf die folgende zsh-Lösung:

ls_svn_dir() {
  if [ -d “$1/.svn” ]; then
    echo “$1”
  else
    for i in $1/{,.[!.]}*(/N); do
      ls_svn_dir “$i”
    done
  fi
}

ls_svn_dir “$1”

Das ist eine rekursiv definierte Shellfunktion. Diese schaut, ob das aktuelle Verzeichnis ein Unterverzeichnis .svn enthält. Falls ja, wird dieses ausgegeben. Andernfalls springt die Funktion in die for-Schleife. Das Konstrukt $1/{,.[!.]}*(/N) expandiert alle Unterverzeichnisse des in $1 stehenden (Dafür sorgt der ‘/’.) und gibt keinen Fehler aus, falls es keine Unterverzeichnisse gibt (Dafür sorgt das ‘N’.). Auf die Ergebnisse wird dann die Funktion rekursiv wieder aufgerufen.

Alles in allem ist das die Lösung, die ich mir vorgestellt habe. Falls jemandem der mitlesenden zsh-Nutzer eine Verbesserung einfällt, bin ich für Vorschläge gern zu haben.

Dies ist ein weiterer Beitrag in meiner Reihe “Optionen für Tor”. Heute möchte ich euch etwas zu Exitpolicies erzählen.

Exitpolicies betreffen euch, wenn ihr selbst einen Torserver betreibt. Denn da lässt sich einstellen, welche Rolle der Server innerhalb des Netzes übernimmt. Er kann zum einen einfach Traffic von einem Knoten zum nächsten weiterleiten ohne jemals ein Ausgang aus dem Tornetzwerk zu sein (Middleman). Zum anderen kann er auch so konfiguriert werden, dass selbst Verbindungen nach außen aufbaut (Exitserver). Der letzte Fall kann nochmal sehr fein mittels der Exitpolicies gesteuert werden, d.h. welche IPs oder Ports sollen angesprochen werden und welche nicht.

Grundsätzlich hat eine Exitpolicy die Form:

ExitPolicy accept ADRESSE/MASKE:PORT
ExitPolicy reject ADDRESSE/MASKE:PORT

Falls ihr keinerlei Verkehr zulassen wollt (Middleman), dann tragt ihr einfach ExitPolicy reject *:* in die torrc ein. Das bedeutet, dass sämtlicher Verkehr nach außen nicht zugelassen ist.

Nun könntet ihr auf die Idee kommen, dass euer Server auch allen Verkehr der auf meine Seite kommt zulassen wollt. Die IP meiner Seite ist 217.17.202.211. Also tragt ihr ExitPolicy accept 217.17.202.211:80 in die torrc ein. Wollt ihr eine ganze Spanne von Ports freigeben, dann könnt ihr ExitPolicy accept IP:n-m (n und m sind die Ports) schreiben. Ein kompletter IP-Adressraum kann mit der entsprechenden Maske angegeben werden, d.h. ExitPolicy accept 217.17.202.0/24:* würde die Adressen von 217.17.202.0 bis 217.17.202.999 freischalten. Der Stern sorgt gleichzeitig dafür, dass alle Ports bei diesen IP-Adressen angesprochen werden können (Keine Angabe von Ports bewirkt auch, dass alle angeprochen werden können.).

Die Optionen werden von oben nach unten bearbeitet und die erste passende Regel wird beachtet. Setzt ihr also:

ExitPolicy accept 217.17.202.211:80
ExitPolicy reject *:80

Darf kein HTTP-Port außer der obigen IP-Adresse angesprochen werden. Im Beispiel.

ExitPolicy reject *:80
ExitPolicy accept 217.17.202.211:80

dürfte kein HTTP-Port angesprochen werden, da bereits die erste Regel greift. Falls ihr also Exitpolicies fomuliert, arbeitet euch von speziellen zu allgemeinen Regeln durch.

Grundsätzlich solltet ihr Verkehr zu privaten IP-Adressen (10.*, 127.* etc.) verbieten. In den früheren Versionen musste man die Adressen explizit angeben. Heute kann man das Schlüsselwort private (Beispiel: ExitPolicy reject private) verwenden. Weiterhin könnt ihr auch die Option ExitPolicyRejectPrivate 1 (ist standardmäßig auch auf 1 gesetzt) setzen.

Ich hoffe, dass hilft euch, die Exitpolicies besser zu verstehen bzw. zu formulieren. Falls ihr noch Fragen habt, nutzt einfach die Kommentare.

Gerade eben versuchte ich, die Sprachtools von Google zu nutzen, um ein Wort zu übersetzen. Statt einer Übersetzung präsentierte mir Google einen Fehler 501 und meinte, dass die Zugriffsmethode nicht implementiert sei. Besonders schön, war der Codeblock, den ich als Bericht an Google senden soll:

/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/
nUepl36veZ8n4xP_H1XesL8hZj1iv7UEEGD-weBX7JfnSgBZH
s4quC6BhjJDLN2rKSFzPmdHurQp3GOCGhTTODiDtJ30yguDG7
AoeQNrV8WfMR09dRsKLTeRpmXKIhAEt6bvCuVPYWnbMvoZEsD
hxH-aANUGt-AagF-uW82KD-kbIFysjUaT7pDpJXZ4DFGgzKyD
wU83LYZwIBTmJHR9jmU7doRcRZTzwSgKLaEFFlN5C1itJOkH2
4D-kZ4dFV5FUKnGqvZtJ2tJsKWELqQ-WEFQ498AYJB2BzLAIJ
QbJMr-AAtTvlofmEYRgV7EaJqLvf7Fis2Iz0pGEYFexGiaiy_
tdzthTBQYyHtFBkiZ5f0QqYBxLPTZ_-CTMXGDNssmxQY5jifO
VK-qzOzirml5Rul8bhuegvpzOa63qN9vvb6VCXIUQABOjshYQ
J43uJXl11-mW5nvJBy_A-k-fhQwqnFKDsS2Oq5a5oJcNlAHhT
AsHWlA7DCBurPRS_cF4yQmkUO3E5MKDv4VtG-11NhnmQ7-WJN
Wnyj8FYETNkm1pPQvskJYBNeMZ80NV2kvBDsS-yO91alu_wY9
hK6PTPOVPTAE5im3sOjnjzbhwEaoq7HfQWPt3SdtX6kxaf21x
cEvnh9imH0em-2Fk-2YxTZdnDQ8JXlknmU_ndJB-F4uQ2Xwxh
y9zZI1sBmcH7EZCf3wF6jEC4OBb7ydf--7uqvg4mAi9zmG9MO
lCgLPOLv_48wSXcTZnP6BkEk2SMg-b1c_WxB7RlsrOicYUart
O62WzoSGcKwoH3dKYdBJnCHQbNsyfS9PZWCGuoWMfJMwMZ34I
F79G0CcabEUIyf9snkJX-1-XH9RAdWCoR5eMOkWWg59l7xPtr
5Wst8OUzB_HauUw8isVSjq2v8VNfMM26KonbJM2JrLAW_ns7x
K5KermbdLC2EaxntFRwhl8G8=
+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+

Beim zweiten Blick fiel mir eine Meldung der Erweiterung NoScript auf. Denn da stand, dass NoScript einen XSS-Versuch von Google geblockt hat. Die Konsole schrieb genauer: [NoScript XSS] Ein verdächtiger Upload zu [http://translate.google.com/translate_t] von [http://www.google.de/language_tools?hl=de] wurde bereinigt und in eine GET-Anfrage (nur Download) umgewandelt.. Die Einstellungen von NoScript haben für Google eine Ausnahme in Form eines regulären Ausdrucks definiert: ^http://([a-z]+)\.google\.[a-z\.]+/(?:search|custom|\1)\?. Dieser würde auf die Seite http://translate.google.com/translate passen. Die URL hat jedoch noch einen Unterstrich und ein t mit. Also passt das nicht. Aus meiner Sicht ist es daher sinnvoll, noch den String |translate_t nach custom| einzufügen. Damit wird dann auch dieser Fall als Ausnahme definiert und ich muss keine komischen Codeblöcke an Google senden oder Angst vor einer XSS-Attacke von Google haben.