Viel Spaß beim Lesen, ich hoffe die hinterlegten Inhalte haben für den ein oder anderen einen gewissen Nutzen. Wer möchte, ist herzlich eingeladen, sich zu registrieren und eigene Inhalte einzufügen bzw. die vorhandenen zu verbessern oder zu ergänzen.

Viele Leute heutzutage kennen SVN und finden die Möglichkeiten, die es bieten, recht nett – allerdings ist SVN vergleichsweise langsam (besonders für große Projekte) und benötigt einen zentralen Server bzw. ein zentrales Repository. Der erste einleuchtende Grund für mich, zu Git zu wechseln, war die Feststellung, dass Git sämtliche in SVN enthaltenden Funktionen selbst beherrscht, allerdings wesentlich schneller und das absolut dezentral. Allerdings kenne und beherrsche ich selbst noch lange nicht alle Funktionen von Git, daher überlasse ich die Vorstellung davon anderen.

Um mich selbst ein wenig in Git einarbeiten zu können bestand mein erster Versuch darin, einen eigenen Git-Server aufzusetzen, um meine (Test-)Repositories selbst hosten zu können. Für alle, die dies ebenfalls versuchen möchte, beschreibe ich hier die Schritte, die notwendig waren, um den Server einrichten zu können.

Für mich war es wichtig, sowohl Lese-/Schreibzugriff per HTTP zu haben als auch einen webbasierten Browser, um sich die Inhalte per Browser ansehen zu können. Als WebGUI verwende ich GitPHP (http://www.xiphux.com/programming/php/gitphp/). Dazu habe ich das verlinkte Paket heruntergeladen, es in /var/www/git/ entpackt und meine Domain git.ml.vg in der Apache-Konfiguration auf dieses Verzeichnis eingestellt (Config-Datei befindet sich weiter unten). Dadrin habe ich dann das Unterverzeichnis projects/ erstellt, in dem nachher meine Git-Projekte liegen werden. Einen laufenden Apache-Server mit installiertem WebDAV setze ich an dieser Stelle einfach mal voraus, ebenso sollte man sich durch die Config von GitPHP durchlesen, um diese je nach Situation anzupassen.

Mit folgender Apache-Konfiguration habe ich meinen Apache dazu überredet, WebDAV-Server zu spielen:

<VirtualHost 12.34.56.789:80>
ServerName git.ml.vg
ServerAdmin mail@…net

DocumentRoot /var/www/git

<LocationMatch “/projects/([a-zA-Z0-9\-]+).git”>
DAV on
</LocationMatch>

<Directory /var/www/git/projects/>
AllowOverride AuthConfig
Options FollowSymLinks SymLinksIfOwnerMatch Indexes
</Directory>

</VirtualHost>

Nun kann man (als Benutzer www-data, damit Apache Lese- und Schreibzugriff darauf hat) unter /var/www/git/projects pro gewünschtem Repository ein Verzeichnis erstellen und dieses mit git –bare init initialisieren. GitPHP sollte es sofort als vorhanden Anzeigen. Um die Schreibrechte zu limitieren, ist es sinnvoll, per Basic Auth einen Passwort-Schutz einzurichten, dazu lege ich pro Repository im entsprechenden Verzeichnis eine .htaccess-Datei ab (diesmal als Root, damit sie nicht per WebDAV überschrieben werden kann):

AuthType Basic
AuthName “My repo with git”
AuthUserFile /var/www/git/projects/test.git/.htpasswd
<Limitexcept GET HEAD PROPFIND OPTIONS REPORT>
Require valid-user
</Limitexcept>

Diese Konfiguration sorgt dafür, dass jeder lesen, aber nur authentifizierte Benutzer in das Repository schreiben können.

Apache neustarten, ggf. Fehlermeldungen totschlagen, dann sollte der Git-Server funktionieren . Bei Fragen und/oder Problemen meldet euch per Kommentar.

Meine Leser sind aber auch herzlich dazu eingeladen, die Kommentar-Funktion der Beiträge zu benutzen

Also hab ich mich auf die Suche gemacht, wie man wohl diese Buttons wieder nach rechts verschieben kann. Den Qualvollen Weg, bis ich die Lösung hatte, will ich meinen Lesern ersparen, daher direkt die Lösung, wie es funktioniert:

Im Tool gconf-editor gibt es unter der Kategorie /apps/metacity/general einen Schlüssel mit dem Namen button_layout. Der Wert davon steht nach der Aktualisierung auf maximize,minimize,close:. Durch Anpassung dieses Wertes kann man die Position beeinflussen, die von mir nun benutzte Variante ist :minimize,maximize,close, das kann aber jeder für sich selbst entscheiden. Jedes Fenster noch einmal Anklicken, dann sollten alle diese neue Einstellung übernommen haben.

Siehe dazu:

• Entsprechende Bugmeldung bei Launchpad: https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/533566
• Englischer Blogbeitrag mit der Lösung: http://blog.daviey.com/blogroll/anything-but-the-buttons.html

http://www.tagesschau.de/inland/bundesverfassungsgericht144.html

Abzuwarten bleibt, ob ggf. eine Überarbeitung des Gesetzes nachfolgt, welche Inhalte diese Überarbeitung hat und ob man sich erneut vor dem Bundesverfassungsgericht wiedersieht.

http://www.tagesschau.de/inland/vorratsdatenspeicherung126.html

Hier direkt auch ein Artikel zur Entscheidung des Bundesverfassungsgerichts, man darf gespannt sein, was entschieden wird.

Auf http://www.fixmbr.de/opendns-und-andere-freie-dns-server/ findet man eine Vielfalt von alternativen DNS-Servern und sogar Anleitungen, wie man diese konfiguriert.

Beleuchten wir kurz die Funktionsweise dieser Sperre: Bei jedem Zugriff auf eine Internetseite schickt der Browser zunächst einen DNS-Request an den im PC eingestellten DNS-Server, meist den des Providers (z. B. Telekom). Dieser Server prüft nun, ob der zu dem angeforderten Namen (z. B. matthias-lohr.net) auch eine IP kennt. Wenn ja, liefert er diese zurück, wenn nein fragt er den nächst “höheren” Server (bei einer .de-Domain die Nameserver der DENIC) “wer kennt denn die IP zu dieser Domain?”. Dieses Fragespielchen geht solange, bis der erste angefragte DNS-Server die Antwort kennt, diese speichert (falls noch mehr Anfragen zu dieser Domain kommen) und das Ergebnis an den Kunden zurückliefert. Die Telekom und alle anderen Internetzugangsprovider werden im Rahmen der Internet-Sperren dazu verpflichtet, bestimmte Domains, die im Zusammenhang mit Kinderpornographie bekannt geworden sind, immer auf eine feste IP umzuleiten, die nicht mehr dem Original-Ziel entspricht. Auf dem damit angefragten Server hat Frau Von der Leyen ein Stoppschild mit Apellen an die Menschlichkeit hinterlassen, welches sich der Internetbenutzer nun ansehen darf.

Wie schon oft und reichlich diskutiert, kann der Benutzer aber in seinem Betriebssystem selbst wählen, welche DNS-Server er benutzt. Beispielsweise kann man, statt die IP der heimischen FritzBox, einfach die DNS-Server von Google eintragen (8.8.4.4, 8.8.8.8). Schon ist man nicht mehr auf DNS-Server, die der deutschen Gerichtsbarkeit unterliegen, angewiesen, und merkt von den Websperren nichts.

Nun ist aber DNS dafür bekannt, dass es relativ leicht zu beeinflussen und die Daten darin zu fälschen sind (siehe Heise-Meldung). Um DNS ein klein wenig sicherer zu machen, wurde das DNSSEC-Protokoll entwickelt, welches es ermöglichst, gefälschte DNS-Antworten zu erkennen und ggf. auf andere Server auszuweichen, von denen man eine korrekte Antwort erhalten hat. Zur Zeit beraten die Betreiber der root-Zone, sowie auch die DENIC, wie der Betrieb mit DNSSEC aussehen kann und stellen entsprechende Testszenarien zusammen.

Der interessante Punkt ist nun folgender: Die Eingriffe der Provider in das DNS-System sehen für jeden Rechner, der DNSSEC versteht und überprüft, nun wie Fälschungen aus. Ein gut konfigurierter Rechner meldet also seinem Benutzer, dass jemand versucht, offensichtlich falsche Daten zuzustellen bzw. ignoriert der Rechner diese sogar und fragt direkt andere Nameserver. Der Effekt dabei ist, dass die IP mit dem schönen Stoppschild nie zum Kunden kommt, sie ist ja eine Fälschung. Also wird auch niemand das Stoppschild sehen, sondern nach ein wenig Arbeit (nämlich der Konfiguration anderer Nameserver) die Original-Inhalte.

(Für diejenigen, die wissen, wie DNSSEC funktioniert) Natürlich ist es möglich, in der einer gesperrten Domain übergeordneten Zone einen eigenen DS-Schlüssel hinterlegen zu lassen, mit dem sich die Echtheit der gefälschten Daten beweisen lassen würde (welch ein Satz…), allerdings untersteht nur ungefähr eine TLD der deutschen Regierung, weswegen diese Lösung ausschließlich für die de-Zone anwendbar wäre. Eine weitere Alternative wäre die komplette Filterung des innerdeutschen Datenverkehrs, um die Nutzung von nicht erlaubten DNS-Servern aufzuspüren. Allerdings wandere ich vorher nach China aus!

Nach soviel destruktiver Kritik noch ein wenig Konstruktives: Mir ist kein Staat bekannt, der Kinderpornographie befürwortet. Daher sollte es in einer internationalen Initiative doch eigentlich möglich sein, ein Informations-Netzwerk aufzubauen, in dem Regierungen sich untereinander informieren, wenn Sie in einem nicht unter ihrer Kontrolle stehenden Internet-Bereich einen Server aufgespürt haben, der kinderpornographische oder sonstige verwerfliche Inhalte enthält. Damit wäre dann auch die Löschung – die meines Erachtens ohnehin vorgenommen werden sollte, allerdings nicht ohne Anordnung eines Richters – von Seiten möglich und die Welt ein klein wenig schöner…

Zuersteinmal sollte man sich die Zertifikate der jeweiligen Zertifizierungsstelle im pem-Format herunterladen. Diese Dateien kann man nun (als root) im Verzeichnis /etc/ssl/certs ablegen, dabei sollte man einen aussagekräftigen Namen verwenden, damit man diese Dateien, falls nötig, wiederfindet. Damit nun das Zertifikat auch von Programmen gefunden werden kann, ist es nötig, einen speziellen Symlink auf die Zertifikats-Datei anzulegen. Dazu benötigt man zuerst den Hash-Code des Zertifikats. Diesen bekommt man z. B. mit folgendem Befehl:

mlohr@home:/etc/ssl/certs$ openssl x509 -in CACert_root.pem -noout -hash
5ed36f9

Die Zeichenkette 5ed36f9 ist der gesuchte Hash. Für den Namen des Symlinks hängt man noch .0 (Punkt Null) hintendran:

mlohr@home:/etc/ssl/certs$ sudo ln -s CACert_root.pem 5ed36f9.0

Dieses war der erste Streich, doch der zweite folgt sogleich. Da man nicht immer root ist um solche Vorhaben durchzuführen gibt es von gnupg auch eine Variante, Zertifikaten zu vertrauen (inwiefern dieser und der eben beschriebene Mechanismus zusammen arbeiten weiß ich nicht, da muss ich mich wohl nochmal schlaulesen): In seinem Home-Verzeichnis einfach die Datei ~/.gnupg/trustlist.txt erstellen und in diese Datei die Hashes der zu vertrauenden Zertifikate eintragen. Als Beispiel hier meine Datei mit den Hashes der beiden CACert-Zertifikate:

mlohr@home:~/.gnupg$ cat trustlist.txt
135CEC36F49CB8E93B1AB270CD80884676CE8F33
DB4C4269073FE9C2A37D890A5C1B18C4184E2A2D

Ich hoffe, das hilft erstmal weiter. Wenn jemand Wissenswertes zu den Themen weiß, kann er mir das gerne mitteilen, dann erweitere ich diesen Artikel – oder eben als Kommentar gerade hinterlegen. Gleiches gilt natürlich auch bei groben Fehlern etc.

Ich bedanke mich für die Aufmerksamkeit, die Ihr meinem Blog widmet und freue mich auf ein wiederlesen im neuen Jahr!

Viele Grüße
Matthias Lohr