seeseekey.net - Invictus Deus Ex Machina

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

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

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.

Wenn man einen Server mit einem Mail Transfer Agent wie Postfix betreibt, kann man von diesem auch Mails versenden. Auf der Konsole ist dies dabei mit dem Kommando mail möglich, welches sich im Paket mailutils befindet. Mit dem Kommando kann mittels:

echo "Nachricht" | mail -s 'Betreff' mail@example.com

eine Mail versandt werden. Natürlich können auch lokale Konten bespielt werden:

echo "Nachricht" | mail -s 'Betreff' root

Damit wird in diesem Fall dem Nutzer root eine Mail gesendet.

Vor einigen Tagen ist mir ein Mailserver (bestehend aus Postfix und Dovecot) begegnet, welcher in der mail.err regelmäßig folgende Ausgabe wiederholte:

Apr 2 13:16:35 service dovecot: lda(root): Error: chdir(/root/) failed: Permission denied (euid=65534(nobody) egid=65534(nogroup) missing +x perm: /root, dir owned by 0:0 mode=0700)
Apr 2 13:16:35 service dovecot: lda(root): Error: chdir(/root) failed: Permission denied
Apr 2 13:16:35 service dovecot: lda(root): Error: user root: Initialization failed: Namespace '': stat(/root/Maildir) failed: Permission denied (euid=65534(nobody) egid=65534(nogroup) missing +x perm: /root, dir owned by 0:0 mode=0700)
Apr 2 13:16:35 service dovecot: lda(root): Fatal: Invalid user settings. Refer to server log for more information.

Der Dovecot-Service versucht auf einen Maildir-Ordner im Nutzerverzeichnis des Nutzers root zuzugreifen, was allerdings nicht gelingt. Einfach lösen lässt sich dieses Problem in dem man einen Alias für die Mailzustellung zum Nutzer root anlegt. Dazu wird im ersten Schritt die Datei /etc/aliases bearbeitet. In dieser Datei kann der entsprechende Alias eingetragen werden:

root: webmaster@example.com

Nachdem die Datei gespeichert wurde, muss die Datei in ihre binäre Form überführt werden und die entsprechenden Services neugestartet werden:

newaliases
service dovecot restart
service postfix restart

Damit werden die Mails von root im entsprechenden Postfach hinterlegt und die Fehlermeldung gehört der Vergangenheit an.

Mein vor einiger Zeit aufgesetzter Proxyserver startete nicht mehr. Stattdessen bekam ich von Polipo nur noch die Meldung:

Starting polipo: Couldn't open log file /var/log/polipo: Permission denied

Allerdings ließ sich das ganze relativ problemlos aus der Welt schaffen:

touch /var/log/polipo
chmod 640 /var/log/polipo
chown proxy:proxy /var/log/polipo

Danach konnte der Dienst mittels:

service polipo restart

wieder gestartet werden.

Von Zeit zu Zeit laufen Zertifikate ab. So auch in meinem Fall, als sich mein XMPP Client beschwerte, das dass Server-Zertifikat nicht mehr gültig ist. Um für ejabberd neue Zertifikate zu erzeugen, sollte man sich auf seinem Server einloggen und dort folgenden Zeilen eingeben:

openssl req -newkey rsa:2048 -keyout ejabberd.pem -nodes -x509 -days 365 -out ejabberd.cer
cat ejabberd.cer >> ejabberd.pem
cp ejabberd.pem /etc/ejabberd/ejabberd.pem

Anschließend kann der Dienst mittels:

service ejabberd restart

neugestartet werden. Das neue Zertifikat ist damit aktiv und der Dienst kann wieder genutzt werden.

Wenn man einen OpenVPN-Server in der Standardkonfiguration betreibt, wird man sich unter Umständen wundern, an welcher Stelle ist das OpenVPN Log zu finden ist. Das liegt daran das der OpenVPN-Server das ganze in /var/log/syslog speichert. Möchte man nun die OpenVPN betreffenden Punkte filtern so sollte man auf der Konsole folgendes eingeben:

grep VPN /var/log/syslog

Alternativ kann man auch die OpenVPN-Konfiguration anpassen. Dazu muss die Datei /etc/openvpn/server.conf bearbeitet werden. Dort gibt es eine Option log-append, welche wie folgt angepasst wird:

log-append /var/log/openvpn.log

Nach einem Neustart des Service mittels:

service openvpn restart

wird die neu eingestellte Logdatei genutzt.

Möchte man Testen ob man vom Shellshock-Fehler betroffen ist, gibt man auf der Konsole folgendes ein:

env x="() { :;} ; echo Anfällig für Shellshock" /bin/sh -c "echo Shellshock-Test"

Wenn man betroffen ist gibt diese Kommandozeile:

Anfällig für Shellshock
Shellshock-Test

aus. Ist man nicht betroffen erhält man folgende Ausgabe:

Shellshock-Test

Versuche Shellshock von Außen zu nutzen kann man feststellen indem man seine Logdateien nach diesem Beispiel:

cat logfile.log | grep };

abgrast. Bei einem Webserver Log könnte das ganze dann z.B. so aussehen:

192.168.1.15 - - [27/Sep/2014:19:32:19 +0200] "GET / HTTP/1.1" 200 18804 "-" "() { foo;};echo;/bin/cat /etc/passwd"

Alternativ kann man ein Skript nutzen, welches von einem Golem Autor erstellt wurde. Der Quelltext für das Skript ist dabei auf GitHub zu finden.

Bei einer Aktualisierung eines Ubuntusystems mittels des Paketmanagers wurde der Vorgang am Ende mit der Zeile:

The link /vmlinuz.old is a damaged link
Removing symbolic link vmlinuz.old 
 you may need to re-run your boot loader[grub]

abgeschlossen. Die Lösung für das Problem ist dabei relativ unkompliziert. Es reicht auf der Konsole:

update-grub

einzugeben. Damit wird die menu.lst erneut geschrieben.