seeseekey.net - Invictus Deus Ex Machina

Wenn man Let’s Encrypt Zertifikate erzeugt, so landen diese im Ordner /etc/letsencrypt/. Die Rechte sind dabei so gewählt das nicht privilegierte Prozesse auf diese Zertifikate nicht zugreifen können. Läuft nun z.B. ein Server mit solchen Rechten, so kann er das Zertifikat nicht ohne weiteres nutzen. Um diesem Umstand zu beseitigen sollte eine neue Nutzergruppe angelegt werden:

groupadd tls-certificates

Dieser Gruppe wird nun der Nutzer hinzugefügt, welcher den Serverdienst betreibt:

usermod -a -G tls-certificates git

Damit wird der Nutzer git der Gruppe tls-certificates hinzugefügt. Nun müssen nach der Zertifikatsgenerierung die Berechtigungen angepasst werden:

#!/bin/sh
service gogs stop
letsencrypt renew --agree-tos
chgrp -R tls-certificates /etc/letsencrypt
chmod -R g=rX /etc/letsencrypt
service gogs start

In diesem Skript wird im ersten Schritt der Service gestoppt. Anschließend werden neue Zertifikate erzeugt und die Berechtigungen angepasst. Damit kann die Gruppe tls-certificates auf die Zertifikate zugreifen. Danach wird der Service wieder gestartet, was nun dank Zugriff auf die Zertifikate ohne Probleme funktioniert.

Um unter Git einen Branch umzubenennen nutzt man den entsprechenden Terminalbefehl:

git branch -m oldBranchname newBranchname

Damit wird der Branch im lokalen Repository umbenannt. Wenn dieser nun mittels git push auf den entfernten Remote übertragen wird, so entsteht dort ein neuer Branch. Um die Umbenennung auch auf dem Remote durchzuführen muss der alte Branch auf dem Remote gelöscht werden:

git push origin :oldBranchname

Damit wird der alte Branch auf dem Remote gelöscht und die Umbenennung ist abgeschlossenen.

Vor kurzem stand ich vor dem Problem, das ich eine Menge Git-Repositories auf der Festplatte hatte und diese um den .git Ordner bereinigen wollte. Unter Linux und Mac OS X kann man sich für diese Aufgabe mit der Kommandozeile behelfen. Dazu wechselt man in den entsprechenden Ordner und gibt im Terminal folgendes ein:

find . | grep .git | xargs rm -rf

Damit werden sämtliche .git Ordner rekursiv gesucht und gelöscht. Was übrig bleibt sind die aktuellen Arbeitskopien der jeweiligen Git-Repositores.

Nutzt man die freie Git-Hosting-Lösung Gogs, so kommt man regelmäßig in den Genuss von Updates. Möchte man das Upgrade einspielen, so gibt es einige Dinge zu beachten. Im ersten Schritt sollte der Dienst auf dem Server natürlich beendet werden:

service gogs stop

Anschließend wird in den Kontext des Nutzers gewechselt unter welchem Gogs betrieben wird:

su git
cd

Der nächste Schritt ist der Download der neuen Version, sowie die Verschiebung der alten Version und das Kopieren der Konfigurationsdatei von der alten zur neuen Version:

mv gogs gogs_old
wget https://github.com/gogits/gogs/releases/download/v0.8.10/linux_amd64.zip
unzip linux_amd64.zip 
cp -R gogs_old/custom gogs
cp -R gogs_old/data gogs
cp -R gogs_old/log gogs

Danach wird in den Gogs Ordner gewechselt und Gogs manuell gestartet.

cd gogs
./gogs web

Bei diesem Start wird die Migration der Datenbank durchgeführt. Anschließend kann Gogs wie gehabt genutzt werden. Die heruntergeladene Datei sowie der Ordner gogs_old können anschließend entfernt werden.

Normalerweise nutze ich als grafische Git-Oberfläche für Mac OS X, die freie Software GitX. Allerdings scheint die Entwicklung des Clients (wieder mal) eingeschlafen zu sein, so das ich mich nach Alternativen umgeschaut habe.

SourceTree unter Windows

SourceTree unter Windows

Fündig geworden bin ich dann bei SourceTree vom Hersteller Atlassian, welcher vor allem durch seine Projekmanagmentlösungen bekannt geworden ist. Der Client verfügt über eine Menge Funktionalität, welche der normale Anwender sicherlich nicht auf Anhieb benötigen wird, ist aber ansonsten sehr solide aufgebaut. Neben Git unterstützt der Client auch das Versionsverwaltungssystem Mercurial. Der Client selbst ist dabei neben Mac OS X auch für Windows verfügbar.

Vor ein paar Tagen schrieb ich in einem Artikel wie man Gogs (einen Git-Service) auf einem Ubuntu-Server aufsetzt. Das aktuelle Release v0.6.15 wird dabei mit einem Init-Script für Debian mitgeliefert. Dieses Skript funktioniert allerdings nicht wie gewünscht.

Die Änderung welche das Init-Script wieder repariert

Die Änderung welche das Init-Script wieder repariert

Wenn man das Skript mittels:

service gogs start

ausführt wird Gogs angeblich gestartet. Allerdings zeigt:

service gogs status

das dies nicht der Fall ist. Das Problem am Init-Skript ist die nicht gesetzte USER-Variable. Mit der aktuellen Version des Skriptes funktioniert der Start von Gogs über service wieder ohne Probleme.

Möchte man Git-Repositories auf einem Ubuntu-Server hosten, so ist das schnell erledigt. Wenn etwas mehr Komfort aller GitHub gewünscht ist, so sollte man sich Gogs anschauen. Gogs steht dabei für Go Git Service. Wie der Name andeutet handelt es sich um einen komplett in Go geschriebenden Git-Service. Im ersten Schritt muss Git auf dem Server installiert werden:

apt-get install git

Nachdem Git installiert ist, muss der für Gogs verwendete Nutzer angelegt und in diesen gewechselt werden:

useradd -m gogs
su gogs
cd

Danach kann das Gogs Binary heruntergeladen:

wget https://github.com/gogits/gogs/releases/download/v0.6.15/linux_amd64.zip
linux_amd64.zip
unzip linux_amd64.zip

und anschließend entpackt werden. Nachdem man mittels cd in den Ordner gogs gewechselt ist, kann gogs gestartet werden:

./gogs web

Damit wird ein Webserver auf Port 3000 gestartet. Mit dem Aufruf der passenden URL im Browser (z.B. http://example.org:3000) öffnet sich die Installationsroutine von Gogs.

Die Installationsroutine von Gogs

Die Installationsroutine von Gogs

In der Routine wird die gewünschte Datenbank eingestellt und einige weitere Punkte konfiguriert. Die Installationsroutine erstellt eine app.ini im Verzeichnis custom/conf/. Dort können die Optionen später geändert werden. Damit Gogs automatisch startet – wird der Nutzer verlassen und ein Initscript angelegt, an die Konfiguration angepasst und zu den automatisch startenden Prozessen hinzugefügt:

cp /home/gogs/scripts/init/debian/gogs /etc/init.d/gogs
nano /etc/init.d/gogs
chmod +x /etc/init.d/gogs
update-rc.d gogs defaults

Damit sollte sich der Service über:

service gogs start

starten lassen. Bei mir führt das allerdings zu dem Problem das der Service angeblich gestartet wird, aber trotzdem nicht läuft. Wird der Service manuell per:

sh -x /etc/init.d/gogs start

gestartet funktioniert er ohne Probleme – hier ist noch der entsprechende Fehler zu finden.

In größeren Projekten arbeiten meist mehrere Entwickler an einem Git-Repository. Und wie es bei der Software-Entwicklung nun einmal ist kommt es ab und an zu Fehlern. Bei einer komplexen Versionshistorie ist es allerdings schwierig den Ursprungscommit eines Fehlers zu finden. An dieser Stelle hilft das Git-Kommando bisect weiter. Zum Start muss Git mitgeteilt werden welcher der letzte (aus Sicht des Entwicklers) korrekt funktionierende und der erste fehlerhafte Commit ist. Dies geschieht im Terminal auf dem Repository mittels:

git bisect start
git bisect good <hash>
git bisect bad <hash>

Danach checkt bisect einen Commit aus. Dieser Commit muss nun auf den gesuchten Fehler überprüft werden. Ist der Fehler weiterhin vorhanden, so teilen wir dies Git mittels:

git bisect bad

mit. Ist der Fehler nicht mehr vorhanden, so teilen wir Git dies ebenfalls mit:

git bisect good

Dieser Prozess wird dabei so lange durchlaufen bis Git uns am Ende des Prozesses mitteilt, in welchem Commit der Fehler seinen Ursprung hat. Danach können wir uns den Commit notieren und bisect mittels:

git bisect reset

mitteilen das der Prozess zu einem Ergebnis geführt hat. Dadurch wird das Repository in seinen Ursprungszustand versetzt.

Ein Git-Repository kann aus vielen Branches bestehen welche ab und an mit dem Hauptentwicklungszweig gemergt werden. Dies führt dazu das man die Geschichte eines solchen Repositories in Form eines Graphen darstellen kann. Ein Tool um sich sein Repository in Form eines Graphen anzeigen zu lassen ist dabei SeeGit.

SeeGit mit einem geöffneten Repository

SeeGit mit einem geöffneten Repository

Problematisch wird die Bedienung von SeeGit bei größeren Repositories. Dort nimmt der Ladevorgang sehr lange in Anspruch, während der Graph aufgebaut wird. Lizenziert ist SeeGit unter der MIT-Lizenz und damit freie Software – der Quelltext ist auf GitHub zu finden. SeeGit läuft auf Grund einiger Abhängigkeiten zur Windows-API leider nur unter Windows.

Spätestens mit verteilten Systemen wie Git, ist bei vielen der Erklärungsbedarf gestiegen. So werden in Firmen Richtlinien definiert, wie nun gebrancht und gemergt werden darf. Da eine grafische Visualisierung solcher Prozesse wesentlich eingängiger ist, gibt es Frameworks und Bibliotheken wie Gitgraph.js. Dabei handelt es sich um eine JavaScript-Bibliothek um solche Graphen schnell und einfach zu erzeugen und diese auf Webseiten einzubinden.

gitgraphjs.com

gitgraphjs.com

Lizenziert ist der Quelltext unter der MIT-Lizenz und damit freie Software. Der Quelltext kann über GitHub bezogen werden. Die offizielle Seite des Projektes ist unter gitgraphjs.com zu finden.