Kategorie-Archiv: Linux

Meine Erfahrungen unter Linux

Effizienter Gitlab-Server

Zur Verwaltung von Unidaten, geschäftlichen Daten und bestimmten privaten Daten verwende ich das Versionskontrollsystem git mit der komfortablen Weboberfläche gitlab, die Funktionen wie eine übersichtliche Darstellung der einzelnen Commits und einen Issue-Tracker bereitstellt.

Der Server muss nicht ständig in Betrieb sein, sondern nur, wenn ich an bestimmten Projekten arbeite und die Änderungen auf einen zentralen Server übertragen möchte. Somit kommen pro Monat meist  unter 100 Betriebsstunden zusammen – ein ständig betriebener Server lohnt sich also nicht. Trotzdem möchte ich nicht auf den Komfort und die Möglichkeiten der gitlab-Oberfläche sowie die zentralen Sicherung von Daten verzichten.

Bisher habe ich gitlab auf einem Server in der IaaS-Cloud jiffyBox von domainfactory gehostet. IaaS steht für Infrastructure as a Service – also Infrastruktur, die als Dienstleistung flexibel angemietet werden kann. JiffyBox ist ein toller Dienst, mit dem sich virtuelle Server leistungsmäßig skalieren lassen, ohne Daten zu verlieren. Durch die Möglichkeit, den Server einzufrieren, ist eine günstige Datenablage möglich, wenn der Serverbetrieb nicht ständig erforderlich ist. Je nach Nutzung hatte ich dafür monatliche Kosten von 4-6 Euro – also eine sehr günstige Lösung.

Da ich bei mir noch ungenutzte Hardware stehen hatte, habe ich mich trotzdem dazu entschieden, den Server in Zukunft selbst zu betreiben.

Die funktionalen Anforderungen sind:

  • Betrieb einer Gitlab-Instanz für einen Benutzer mit derzeit insgesamt 5 GB an Repositories, Platzbedarf steigend
  • Eine zusätzliche Standleitung ins Internet soll nicht erforderlich sein.
  • Der Server muss aus der Ferne startbar und wartbar sein.
  • Der Betrieb muss auch bei  Abwesenheit am Standort sicher sein.
  • Der Betrieb soll möglichst energieeffizient erfolgen.

Internetanbindung

Der Server wird an einem normalen Telekom-DSL-Anschluss für Geschäftskunden (DeutschlandLAN Connect S) betrieben. Als Router kommt eine Fritz!Box 7360 von AVM zum Einsatz. Die Datenraten sind:

  • Upload: ca. 2,5 MBit/s
  • Download: ca. 17 MBit/s

Für die von mir benötigen Anwendungsfälle sollte dies ausreichend sein, zumal ich derzeit der einzige Nutzer des Servers sein werde.

Starten aus der Ferne

Die Fritz!Box unterstützt über die Weboberfläche das Starten eines per LAN angebundenen Rechners per Wake-on-LAN. Da die Weboberfläche passwortgeschützt über das Internet erreichbar ist, lässt sich der Server weltweit starten.

Fernüberwachung

Um eine bestmögliche Kontrolle über den Server zu haben, hängt er an einer FRITZ!DECT 200-Steckdose. Dabei handelt es sich um eine schaltbare Steckdose, die sich an die Fritz!Box anbinden lässt. Als Funkstandard wird dabei verschlüsseltes DECT verwendet.

Über die Weboberfläche lässt sich die Steckdose einerseits ein- und ausschalten, andererseits lässt sich damit aber auch der Stromverbrauch überwachen. Es kann sowohl die aktuelle Leistung angezeigt und grafisch dargestellt werden, als auch der Energieverbrauch über verschiedene Zeiträume (Tag, Woche, Monat, Jahr) aufgezeichnet und dargestellt werden.

Mittels der Schaltfunktion lässt sich der Server sicher vom Strom trennen, wenn er nicht benötigt wird. Zudem besteht die Möglichkeit, den Server bei Softwareproblemen (z.B. „aufgehängt“) aus der Ferne physikalisch vom Stromnetz zu trennen, wenn beispielsweise ein Zugriff über ssh nicht mehr möglich ist.

Durch die Überwachung der aktuellen Leistung lassen sich zudem Schlüsse über den aktuellen Betriebszustand des Servers ziehen, welche die Handhabung aus der Ferne deutlich erleichtern:

  • Wurde der Server nach dem Versenden des Wake-on-LAN-Paketes gestartet?
  • Wurde der Server nach dem Absenden des shutdown-Befehls erfolgreich heruntergefahren?

Erreichbarkeit unter eigener Domain trotz dynamischer IP-Adresse

Der verwendete DSL-Anschluss beinhaltet leider keine feste IP-Adresse. Diese wechselt täglich, da alle 24 Stunden eine Zwangstrennung erfolgt. Die Fritz!Box bringt allerdings einen Dienst mit, der dem Gerät einen festen Domainnamen der Form xxxxxxxxxxxx.myfritz.net zuweist. Die aktuelle IP-Adresse wird automatisch mit diesem Domainnamen verknüpft.

Der Server soll aber auch unter einer eigenen Subdomain erreichbar sein. Meine Domains habe ich über domainfactory gebucht. Dieser Anbieter unterstützt das manuelle Editieren der Nameserver-Einstellungen.

Durch das Hinzufügen eines Eintrags vom Typ CNAME lässt sich ein Alias für die xxxxx.myfritz.net-Adresse anlegen. Die eigene Domain löst so immer korrekt auf die aktuelle IP-Adresse der Fritz!Box auf.

Portweiterleitungen

Damit Anfragen an diese Domain auch beim gitlab-Server und nicht bei der Fritz!Box landen, müssen noch die benötigten Ports an den Server weitergeleitet werden. Dies lässt sich sehr einfach über die Weboberfläche der Fritz!Box einstellen.

Folgende Ports müssen weitergeleitet werden:

  • Port 22 (SSH – für Fernwartung)
  • Port 80 (HTTP – für unverschlüsselten Zugriff)
  • Port 443 (HTTPS – für SSL-verschlüsselten Zugriff)

Der Port für die Fritz!Box-Weboberfläche muss noch auf einen anderen Port umgestellt, da sonst der SSL-Port (443) belegt ist.

Wie stabil der Betrieb auf die Dauer läuft, muss sich zeigen. In der Übergangszeit bleibt die JiffyBox-Instanz erhalten – falls unerwartete Probleme auftreten sollten.

Bilder per bash-Skript verkleinern

Mit folgendem einfachen Bash-Skript lassen sich bequem alle Bilder in einem Verzeichnis auf einen bestimmten Prozentsatz verkleinern. In diesem Beispiel werden alle Bilder im Verzeichnis auf 70% der Originalgröße verkleinert.

#!/bin/bash

for file in ./*
do
echo "Resizing file " ${file}
convert ${file} -resize 70% ${file}
done

Git mit normalem Webspace nutzen

Bei der Entwicklung von Software setzt man gerne Versionsverwaltungen ein. Man hat so die Möglichkeit, auf einen alten (und damit unter Umständen noch funktionierenden) Stand einer Datei zurückzuspringen. Vorallem lässt sich  mittels einer Versionsverwaltung Softwareentwicklung im Team realisieren, was sonst ein sehr nervenaufreibender Prozess wäre.

Normalerweise benötigt man dazu einen Server mit Shell-Zugang über ssh. Eine kostengünstige Möglichkeit, ein git-Repository zu nutzen ohne einen eigenen Server betreiben zu müssen oder auf spezielle Repository-Hosting-Dienste (z.B. github) zurückzugreifen werde ich im Folgenden beschreiben.

Wichtig dabei: Der Hosting-Anbieter muss git trotzdem auf seinen Servern installiert haben!

Meinen Webspace habe ich bei der Firma domainFACTORY
(http://www.df.eu/)angemietet. In meinem Tarif steht kein ssh-Zugang zur Verfügung. Allerdings kann ich per sftp auf meinen Webspace zugreifen und es steht php und git zur Verfügung.

Unter Ubuntu wurde ein über GNOME (Places -> Connect to server…) eingebundenes sftp-Verzeichnis automatisch nach /home/user/.gvfs/… gemountet. Unter Debian – was ich momentan nutze – scheint dies nicht der Fall zu sein.

Unter http://blog.flameeyes.eu/2007/02/how-to-use-git-via-sftp-only habe ich den entscheidenden Hinweis gefunden, wie ich das Verzeichnis in den normalen Verzeichnisbaum einbinden konnte.

Hier das Vorgehen, ein leeres git-Repository auf dem Webspace zu erstellen und zum pullen und pushen zu  nutzen:

  1. Verzeichnis in einem einer Domain zugeordneten Verzeichnis erstellen. Dieses Verzeichnis ist dann z.B. unter http://www.xy.de/git erreichbar.
  2. In diesem Verzeichnis eine .php-Datei mit folgendem Inhalt anlegen:
    <?php
        system("git init --bare");
    ?>
  3. Diese Datei mit dem Browser aufrufen – z.B. http://www.xy.de/git/init.php . Wenn eine Meldung angezeigt wird, dass das Erstellen eines leeren Repository erfolgreich war dieses Verzeichnis samt seiner Unterverzeichnisse an einen Ort auf dem Webspace verschieben, der möglichst nicht über eine Domain erreicht werden kann. Man will ja schließlich nicht, dass seine Daten für jedermann einsehbar sind. Die erstellte php-Datei kann jetzt gelöscht werden.
  4. Nun das Verzeichnis mit sshfs mounten:
    sshfs user@host:path/to/git /mnt
  5. Nun kann dem lokalen git-Repository das Verzeichnis als neues origin zugewiesen werden. Das –track master  wird benötigt, wenn ein bereits lokal existierendes Repository in ein leeres entferntes Repository gepusht wird. Dabei entferne ich zuerst eventuell vorhandene alte Origins:
    git remote rm origin
    git remote add --track master origin file:///mnt/
  6. Als nächstes in das neue Repository pushen – also den aktuellen Stand des lokalen Repository auf den Server schieben:
    git push origin HEAD
  7. Fertig!

(Weitere Quellen: http://stackoverflow.com/questions/7630574/git-push-everything-to-new-origin und http://splitshade.wordpress.com/2010/01/18/remote-repositories-mit-git-einrichten/)

Große Uploads mit MediaWiki

Für ein Projekt an der Uni setzen wir ein Wiki auf Basis von MediaWiki zur Teamarbeit ein. Dabei nutzen wir die Upload-Funktion von MediaWiki, um aktuelle Versionsstände eines mit Hilfe von LaTeX erstellten Berichts sichern zu können.

Dabei ergab sich das Problem, dass sich Dateien größer 8 MB trotz der Einstellung eines großen Wertes bei der Option upload_max_filesize in der php.ini nicht hochladen ließen.

Entscheidend ist es für diesen Anwendungszweck, die Option post_max_size in der php.ini auch auf einen höheren Wert zu setzen.

Herkunft des Tipps: http://www.dokuwiki.org/de:faq:uploadsize

Windows 7 Start nach GRUB-Update

Da ich meinen Bootloader (GRUB) wiederherstellen musste, weil Windows ihn bei der Installation überschrieben hatte, ging ich nach dieser Anleitung vor: http://wiki.ubuntuusers.de/GRUB#Methode-3-Chroot-ueber-ein-Live-System

Leider fand „update-grub“ meine Windows 7 Installation nicht.

Der entscheidende Tipp kam aus einem Forum:

Einfach statt „update-grub“ den Befehl „update-grub2“ verwenden.

Manchmal kann’s so einfach sein 🙂