in diesem Blogpost möchte ich euch das Tool „Integrit“ vorstellen. Damit lässt sich ein Snapshot des Dateisystems erstellen und zu späteren Zeitpunkten überprüfen, ob sich Dateien geändert haben.

Die Installation und Konfiguration

Das Programm gibt es als Paket in den meisten Paketquellen, sodass man es einfach installieren kann:

sudo apt-get install integrit

Danach findet man zwei Konfigurationsdateien in /etc/integrit/

ls /etc/integrit 
insgesamt 16K
drwxr-xr-x 2 root root 4,0K Nov 30 16:43 .
drwxr-xr-x 117 root root 4,0K Dez 1 00:00 ..
-rw------- 1 root root 2,3K Nov 30 16:43 integrit.conf
-rw------- 1 root root 836 Nov 30 16:10 integrit.debian.conf

Eine ausführliche Dokumentation der Konfiguration bzw. Nutzung von Integrit findet man hier: http://integrit.sourceforge.net/texinfo/integrit.html

In der „integrit.debian.conf“ sollte man unbedingt die folgenden zwei Variablen setzen:

CONFIGS="/etc/integrit/integrit.conf"
EMAIL_RCPT="meine@email.tld"

Danach muss man sich an die Hauptkonfiguration setzen. Diese ist meiner Meinung nach ganz gut kommentiert. Man kommentiert die Optionen „known“ und „current“ aus:

known=/var/lib/integrit/known.cdb
current=/var/lib/integrit/current.cdb

Danach kann man sich überlegen, welches das Wurzelverzeichnis der zu überprüfenden Dateien sein soll. Ich hab mich mal auf „/var/www/virtual“ beschränkt, um nur die Webseiten zu überwachen.

root=/var/www/virtual

Falls man bestimmte Unterverzeichnisse ignorieren möchte, so schreibt man die Pfade mit einem vorangesetzten Ausrufezeichen in die Datei:

!/var/www/virtual/meine.website/tmp
!/var/www/logs/accces_log

Erste Ausführung

Integrit nutzt zwei separate Datenbanken für die Überprüfung. Die erste der Datenbanken ist die Ausgangsdatenbank „known.cdb“, welche die zu überwachenden Dateien in einem sicheren Ausgangszustand beinhaltet. Diese sollte man nach Möglichkeit auf einem schreibgeschützten Medium aufbewahren.

Um diese Datenbank zu erstellen, geht man folgendermaßen vor:

sudo integrit -C /etc/integrit/integrit.conf -u

Nun erstellt Integrit die zweite Datenbank namens „current.cdb“, in der die aktuellen Dateiinformationen gespeichert werden. Nachdem der erste Durchlauf erfolgreich durchgelaufen ist, macht man die „current.cdb“ zur „known.cdb“:

sudo mv /var/lib/integrit/current.cdb /var/lib/integrit/known.cdb
sudo chmod -w /var/lib/integrit/known.cdb
sudo chattr +i /var/lib/integrit/known.cdb

Die letzten beiden Kommandos sorgen dafür, dass man die Datei nicht so leicht wieder bearbeiten kann. (Das ist aber immer noch keine Ausrede für ein getrenntes Backup ;))

Automatische Überprüfung

Bei der Installation wird direkt die Datei /etc/cron.daily/integrit angelegt. Diese lädt bei der Ausführung die /etc/integrit/integrit.debian.conf, welche wiederum die dort eingetragenen Konfigurationsdateien einbindet.

Emailbenachrichtigung

Hat man in der /etc/integrit/integrit.debian.conf eine Email angegeben, so wird einem der Überprüfungsbericht per Email zugeschickt:

start: integrit -C /etc/integrit/integrit.conf -cu
integrit: ---- integrit, version 4.1 -----------------
integrit:                      output : human-readable
integrit:                   conf file : /etc/integrit/integrit.conf
integrit:                    known db : /var/lib/integrit/known.cdb
integrit:                  current db : /var/lib/integrit/current.cdb
integrit:                        root : /var/www/virtual
integrit:                    do check : yes
integrit:                   do update : yes
changed: /var/www/virtual/meine.website   m(20141115-212730:20141201-100653) c(20141115-230630:20141201-100653) 
new:     /var/www/virtual/meine.website/foo   p(644) t(100000) u(0) g(0) z(0) m(20141201-100653) 
new:     /var/www/virtual/meine.website/foo   s(9c1185a5c5e9fc54612808977ee8f548b2258d31) 
integrit: checking for missing files --------------
integrit: current-state db RMD160 -------------- 
integrit: 9dde6c7cf3f5def49702a2513211f0e4ebf170bd  /var/lib/integrit/current.cdb
exit: 1

So hat man immer im Blick, ob sich Dateien geändert haben.

~ Sebastian

manchmal überkommt einen die Lust etwas neues auszuprobieren bzw. etwas umzusetzen. Bei mir führte das heute dazu, dass ich meinen Dedi @ Kimsufi im Rescue-Modus starten musste. Wie man sich in diesem zurecht findet und warum man nicht am Freitagabend „Sysadmin“-Arbeiten durchführen sollte, mag ich kurz erläutern.

Alles fing damit an, dass wir in der Uni an einem Semesterprojekt arbeiten und wir auf „vagrant“ setzen, um eine virtuelle Maschine auf fast allen Hosts „gleich“ aussehen zu lassen.

Da nächsten Montag die Vorstellung des Projekts ansteht, wollte ich eine „Live“-Version auf meinem Server starten. Nach ein wenig hin-und-her mit der korrekten Version von Vagrant (Repo < Gem < Offizieller Download), meldete sich bei der Installation von virtualbox die Installationsroutine mit der Nachricht, dass sie die Quelldateien fürs Kernel-Modul nicht finden könne, bzw. das sie das „vboxdrv“-Kernelmodul nicht laden könne.

Gleichzeitig wurde mir ein kompatibler 3.2-er Kernel mitinstalliert. Nach ein wenig Googlen im Kimsufi/OVH Forum kam ich zu dem Schluss, dass der Standard-OVH-Kernel nicht mit virtualbox läuft (da die Module fehlen).

Jeder, der nur 3.5 Stunden Schlaf in der letzten Nacht bekommen hat, wird einfach zu dem Schluss kommen den neuen Kernel im Grub auszuwählen und den Server neuzustarten. Genau das tat ich auch.

Nachdem sich mein Server verabschiedet hatte und die SSH-Verbindung versiegte, wartete ich 30 Sekunden bis eine Minute. Normalerweise war die kleine Box danach wieder online. Der Versuch sich per SSH zu verbinden scheiterte natürlich und ein Ping kam auch nicht wieder zurück. Ein ungutes Gefühl legte sich über mich und nach weiteren 2 Minuten gab es immer noch keine Reaktion.

Wir halten fest: Auf dem Server laufen einige gut besuchte Webseiten, sodass man die Downtime möglichst kurz halten sollte.

Nunja, dann bleibt einem nichts weiter übrig als sich im Kimsufi-Kundencenter einzuwählen und über „Netboot->Rescue“, sowie einem darauffolgendem Neustart, die Kiste in den Rescue-Modus zu versetzen.

Nach ein paar Minuten bekam ich dann auch schon eine (unverschlüsselte [sic!]) Email mit dem neuen Root-Passwort (sic!!!). Nach dem Einloggen auf dem Server sah ich mich etwas um und stellte fest, das man sich um alles selbst kümmern darf (was natürlich logisch ist ;)).

Im Gegensatz zur Rescue-Dokumentation von Kimsufi/OVH muss man die Mounts des Soft-RAIDs anders ausführen.

mount /dev/md1 /mnt
mount /dev/md2 /mnt/home

„md1“ ist bzw. sollte in den meisten Fällen die Root-Partition (/) sein. Auf „md2“ befindet sich laut der Dokumentation die home-Partition (ehrlich gesagt, hab ich da nicht nochmal reingeschaut).

Bevor wir das Chrooting ausführen können, sollten wir noch ein paar benötigte Sachen in das Chroot-Directory mounten:

cd /mnt
mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/

Ist dieser Schritt getan, so können wir uns in ein Chroot begeben, um auf dem Server arbeiten zu können.

chroot /mnt/

Nun kann man wie zuvor gehabt den alten Kernel im Grub wieder aktivieren, oder andere Sachen gerade biegen.

Ist man mit allen Rettungsmaßnahmen fertig, so darf man nicht vergessen im Kundencenter unter „Netboot->Festplatte“ die Bootoption zurückzustellen. Zuletzt führt man in der Rescue-Shell ein „/sbin/reboot“ aus.

Was lernen wir aus der Geschichte? Man sollte nicht übermüdet und leichtsinnig an einem Produktivsystem arbeiten. Zudem sollte dieser Zeitpunkt nicht auf einen Freitagabend fallen. Besser ist da wohl der Samstagmorgen, wenn man ausgeschlafen und mit klarem Kopf an die Sache ran geht.

~ Sebastian

Das Einrichten der Daemontools ist insofern sinnvoll, da man sich von der „Alternative“, den virtuellen Screens, ablösen kann. Der Vorteil liegt auf der Hand: Der Supervisor-Prozess wird beim Booten des Servers gestartet, und mit ihm auch die angelegten Services. Es entfällt das lästige händische Neustarten von verschiedenen Diensten in virtuellen Screens.

Da mein Vserver bei Netcup ein paar Krankheiten zum Opfer viel, nach welchen ich sämtliche Dienste von Hand neustarten musste, wollte ich die Daemontools einrichten.

Die Installation der Daemontools

Alles was man zur Installation wissen muss beschreibt der Author des Programms auf seiner Webseite recht kompakt. Ich möchte das ein wenig ausführlicher behandeln, um den Einstieg zu vereinfachen.

Zunächst legen wir einen neuen Ordner an, ändern dessen Rechte und wechseln dort hinein:

sudo mkdir /package
sudo chmod 1755 /package
cd /package

Dorthin werden wir später die Daemontools installieren. Die Quelltexte laden und entpacken wir im nächsten Schritt:

sudo wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
sudo tar xfv daemontools-0.76.tar.gz 

Danach wechseln wir in die neuen Verzeichnisse und stoßen den Kompilierungsprozess an:

cd admin/daemontools-0.76
sudo ./package/compile

In manchen Fällen beendet sich der Compiler mit der folgenden (oder ähnlichen) Fehlermeldung:

/usr/bin/ld: errno: TLS definition in /lib/arm-linux-gnueabihf/libc.so.6 section .tbss mismatches non-TLS reference in envdir.o
/lib/arm-linux-gnueabihf/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [envdir] Fehler 1

Dieses Problem lässt sich sehr leicht fixen. Man muss nur eine Zeile in der Datei src/conf-cc anpassen. Öffnet diese dazu mit einem Editor:

vim src/conf-cc

Dort hängt ihr an das Ende der ersten Zeile folgendes an:

--include /usr/include/errno.h

Nun sollte das Kompilieren des Quelltextes keine Probleme mehr ergeben:

sudo ./package/compile

Zuletzt muss noch die Installation angestoßen werden.

sudo ./package/install

Sollte die Installationsroutine melden, dass sie das Start-Up des svscanboot-Programms in die /etc/rc.local eingetragen hat, dann müsst ihr folgende Änderungen in dieser Datei noch übernehmen:

# By default this script does nothing.
#exit 0
bash -cf '/command/svscanboot &'
exit 0

Jetzt müsst ihr der rc.local Datei noch das x-Flag setzen:

sudo chmod +x /etc/rc.local

Neue Services einrichten

Bevor neue Services eingerichtet bzw. konfiguriert werden können, muss einmalig ein passender Ordner dazu angelegt werden. Ich habe mich für /etc/service entschieden:

sudo mkdir /etc/service
sudo chmod 1755 /etc/service

Ich werde im Folgenden die Erstellung eines neuen Services allgemein halten. Im Endeffekt müssen nur die Parameter zum Ausführen des entsprechenden Programms geändert werden.

Man erstellt zunächst einige neue Ordner und Dateien

sudo mkdir -p /etc/service/SERVICENAME/log/main
sudo touch /etc/service/SERVICENAME/run
sudo touch /etc/service/SERVICENAME/log/run

Den beiden Dateien müssen dann noch die korrekten Rechte verpasst werden:

sudo chmod 700 /etc/service/SERVICENAME/run
sudo chmod 700 /etc/service/SERVICENAME/log/run

Die run-Dateien bestimmen jeweils was ausgeführt wird. Die einfachere von beiden ist die run-Datei im „log“ Verzeichnis. Deren Inhalt ist bei fast allen anzulegenden Services gleich. Die folgenden Zeilen müssen in die /etc/service/SERVICENAME/log/run Datei:

#!/bin/bash
exec multilog t ./main

Diese Datei weist multilog an, im Verzeichnis „log/main“ die Logs des Services zu verwalten. Die Option „t“ schreibt vor jede Logzeile einen Timestamp.

Als nächstes müssen wir das auszuführende Programm in der zweiten run-Datei ( /etc/service/SERVICENAME/run ) festlegen. Der Inhalt dieser run-Datei ist etwas umfangreicher, kann jedoch in fast allen Fällen wiederverwendet werden:

#!/bin/bash
HOME="/home/otheruser"
USER="otheruser"
cd $HOME
exec 2>&1
exec setuidgid otheruser Programm

In diesem Fall gehe ich davon aus, dass man das Programm später nicht als Root sondern als low-rights-User ausführen möchte. Dazu passt man die zwei Umgebungsvariablen entsprechend an. Die fünfte Zeile leitet alle Stderr-Ausgaben auf die Stdout-Ausgabe um, damit auch die Errors später im log/main-Verzeichnis auftauchen.

In der letzten Zeile wird das Programm mit den Rechten (setuidgid) des low-rights-Users ausgeführt. Man sollte dabei darauf achten, dass sich das Programm selbst nicht in den Hintergrund verabschiedet. In einem solchen Fall denkt nämlich der Supervisor, dass das Programm beendet wurde, und startet es neu.

Hat man die beiden run-Dateien erfolgreich bearbeitet fehlt ein letzter Schritt, um das Programm als Service laufen zu lassen. Man muss einen finalen Symlink durchführen:

sudo ln -s /etc/service/SERVICENAME /service/SERVICENAME

Danach sollte der Supervisor den Service starten. Ob das Programm mitspielt und erfolgreich gestartet ist, zeigt ein Aufruf von svstat:

sudo svstat /service/SERVICENAME

Führt den letzten Befehl einige Male aus, und wenn die Lebensdauer des Prozesses 10 Sekunden übersteigt, sollte alles in Ordnung sein. Dies lässt sich ggf. mit einem Blick in die /etc/service/SERVICENAME/log/main/current Logdatei bestätigen.

Services steuern

Zum Steuern der Services nutzen wir im Allgemeinen das Programm „svc“. Dieses bietet die folgenden Optionen:

• -u: Up. If the service is not running, start it. If the service stops, restart it.
• -d: Down. If the service is running, send it a TERM signal and then a CONT signal. After it stops, do not restart it.
• -o: Once. If the service is not running, start it. Do not restart it if it stops.
• -p: Pause. Send the service a STOP signal.
• -c: Continue. Send the service a CONT signal.
• -h: Hangup. Send the service a HUP signal.
• -a: Alarm. Send the service an ALRM signal.
• -i: Interrupt. Send the service an INT signal.
• -t: Terminate. Send the service a TERM signal.
• -k: Kill. Send the service a KILL signal.
• -x: Exit. supervise will exit as soon as the service is down. If you use this option on a stable system, you’re doing something wrong; supervise is designed to run forever.

Wenn ihr demnach einen Service stoppen wollt, dann führt ihr folgende Zeile aus:

sudo svc -d /service/SERVICENAME

Möchtet ihr den Service wieder starten, dann entsprechend folgendes:

sudo svc -u /service/SERVICENAME

Die Optionen können auch kombiniert werden. Der folgende Befehl startet einen Service neu:

sudo svc -du /service/SERVICENAME

Einen Service löschen

Wenn man einen Daemon nicht mehr benötigt, muss man die Löschung der Dateien folgendermaßen durchführen:

cd /service/SERVICENAME
sudo rm /service/SERVICENAME
sudo svc -dx . log
sudo rm -rf /etc/service/SERVICENAME

Wir wechseln über den Symlink in das Verzeichnis /etc/service/SERVICENAME. Danach löschen wir den Symlink, über den wir dort hin gekommen sind. Danach beenden wir den Service, sowie den dazugehörigen Supervisor-Prozess. Zuletzt löschen wir die angelegten Konfigurationsdateien, welche wir nun nicht mehr benötigen.

Fazit

Die Daemontools von Bernstein können sehr hilfreich sein, um Programme einfacher zu kontrollieren bzw. als Service laufen zu lassen. Die Einrichtung der Tools ist relativ einfach, genauso wie das konfigurieren von neuen Services.

~Sebastian

Was ist Icecast2 ?

Grob gesagt ist Icecast eine Software mit der man Streams (meist Musik) im Internet bereitstellen kann. Zum Beispiel können so Podcasts an größere Zuhörermengen verteilt werden, oder Hobby-DJs lassen ihre Zuhörer das Set live genießen.

Die Installation von Icecast2

Es gibt – wie fast immer – zwei Wege der Installation. Einerseits kann man Icecast2 direkt aus den Paketquellen der meisten Distributionen (Linux) installieren. Das klappt oft mit dem folgenden Befehl:

sudo apt-get install icecast2

Andererseits kann man sich den Quelltext herunterladen und diesen selbst kompilieren. Letzteres habe ich getan, sodass ich mein Vorgehen folgend beschreiben werde.

Als erstes wechseln wir in den RAM und erstellen einen temporären Ordner:

cd /tmp && mkdir icecast && cd icecast

Danach laden wir den Quelltext herunter und entpacken diesen:

wget http://downloads.xiph.org/releases/icecast/icecast-2.4-beta3.tar.gz .
tar xfv icecast-2.4-beta3.tar.gz
rm icecast-2.4-beta3.tar.gz
cd icecast-2.3.99.3

Die Versionsnummern können sich in der Zukunft ändern. Gegebenenfalls müssen diese angepasst werden. 

Nach dem entpacken prüfen wir, ob alle Abhängigkeiten vorhanden sind und die Konfiguration der Installationsdateien aus:

./configure

Ist der Prozess erfolgreich beendet, kann man den Quelltext kompilieren und das Programm installieren:

make
sudo make install

Unsere Konfiguration wird später auf einigen Verzeichnissen bzw. Dateien aufbauen, welche wir nun anlegen:

sudo mkdir /usr/local/share/icecast/conf
sudo mkdir /usr/local/share/icecast/logs
sudo touch /usr/local/share/icecast/logs/access.log
sudo touch /usr/local/share/icecast/logs/error.log
sudo chown -R nobody:nogroup /usr/local/share/icecast/logs

Damit wäre dieser Schritt soweit abgeschlossen. Als nächstes folgt die Konfiguration.

Die Konfiguration von Icecast2

Die Konfigurationsdatei müssen wir manuell anlegen, und dazu haben wir vorhin schon den Ordner „conf“ erzeugt. Öffnet daran die Datei „config“ mit einem Editor eurer Wahl :)

sudo vim /usr/local/share/icecast/conf/config

Die Konfiguration basiert auf XML, und muss mit „<icecast>“ beginnen bzw. mit „</icecast>“ enden. Dazwischen packen wir die verschiedenen Konfigurationsblöcke, welche ich nach und nach erläutern werde. Eine genaue Erklärung der Einstellungsmöglichkeiten findet man in der Doku von Icecast2.

<limits>
    <clients>100</clients>
    <sources>2</sources>
    <threadpool>5/</threadpool>
    <queue-size>102400</queue-size>
    <client-timeout>30</client-timeout>
    <header-timeout>15</header-timeout>
    <source-timeout>10</source-timeout>
</limits>

Diese Einstellungen bestimmen die Softwarelimits des Icecasts. Laut der Doku reichen diese für kleine bis mittelgroße Streams und können ohne Erklärung einfach übernommen werden.

<authentication>
    <source-password>Source-PW</source-password>
    <relay-password>Relay-PW</relay-password>
    <admin-user>Adminuser</admin-user>
    <admin-password>Admin-Pw</admin-password>
</authentication>

In diesem Block setzt man die Logindaten. Einerseits für die Administration über den Webserver, andererseits zum Streamen. Diese Felder sollten unbedingt mit einem sicheren Passwort gefüllt werden.

<hostname>Icecast hosted by gehaxelt</hostname>
<listen-socket>
        <port>8000</port>
        <bind-address>IP</bind-address>
</listen-socket>

Hier könnt ihr den Hostnamen des Icecast Servers setzen. Zudem müsst ihr die IP-Adresse setzen und ggf. den Port anpassen, falls dieser euch nicht gefällt.

<fileserve>1</fileserve>
<paths>
    <basedir>/usr/local/share/icecast</basedir>
    <logdir>/logs</logdir>
    <pidfile>/icecast.pid</pidfile>
    <webroot>/web</webroot>
    <adminroot>/admin</adminroot>
    <alias source="/" dest="/status.xsl"/>
</paths>

Die erste Einstellung weist Icecast an, die Daten über den Webserver aufzubereiten (um diesen später ggf. zu administrieren). Ansonsten sollte man die Pfade so übernehmen können. Hinweis: Wir werden später Icecast in ein chroot stecken, sodass die weiteren Pfade relativ zum Base-Pfad sein müssen.

<logging>
    <accesslog>access.log</accesslog>
    <errorlog>error.log</errorlog>
    <loglevel>2</loglevel>
</logging>

Wir wollen natürlich – wie die NSA – alles protokollieren. Folgende Loglevel gibt es dabei:

• 1 – Error
• 2 – Warn
• 3 – Info
• 4 – Debug

Das Loglevel 2 ist meiner Meinung nach ausreichend.

<security>
    <chroot>1</chroot>
    <changeowner>
        <user>nobody</user>
        <group>nogroup</group>
    </changeowner>
</security>

Mit dem letzten Block versetzen wir Icecast nach dem Starten in ein chroot, und wechseln die Benutzerrechte auf nobody:nogroup.

Icecast2 Server starten bzw. stoppen

Um den Server zu stoppen, führt ihr einfach icecast mit Rootenrechten aus, und übergebt das entsprechende Config-File.

sudo icecast -c /usr/local/share/icecast/conf/config -b

Mit der Option „-b“ verabschiedet sich Icecast in den Hintergrund und läuft als Daemon weiter. Ihr solltet dann beim Aufrufen von [IP]:8000 auf die Willkommensseite von Icecast kommen. Ihr benötigt die Rootrechte, damit sich Icecast nach der Initialisierung ins chroot verschieben kann.

Um den Server wieder zu stoppen genügt ein killall:

sudo killall icecast

Fazit

Die Einrichtung von Icecast2 ist wirklich kein großes Problem, da die Konfiguration sehr übersichtlich ist, und ein vorkompiliertes Paket in den Paketquellen vorhanden ist. Das Streamen von Musik bzw. Podcasts über den eigenen Server ist nun kein Problem mehr.

~Sebastian

Betreibt man verschiedene Systeme in einem Netzwerk sollte im Fall der Fälle der Zeitstempel aller Logeinträge gleich sein. Denn nichts stört die Analyse von verschiedenen Logdateien auf verschiedenen Systemen mehr als wenn man zwischen verschiedenen Zeiten hin-und-her rechnen muss. Das Problem lässt sich einfach lösen, in dem man den NTP-Daemon auf allen System installiert.

Die Installation & Konfiguration

Wenn das Programm „ntpd“ nicht bereits von der Distribution mitgeliefert wird, dann lässt sich das Paket „ntp“ einfach über den Paketmanager installieren:

sudo apt-get install ntp

Ist das getan, sollte eine einfache Konfiguration unter /etc/ntp.conf vorhanden sein.

Die Konfiguration

Ich werde folgend die Standardeinträge der Konfigurationsdatei ein wenig kommentieren.

driftfile /var/lib/ntp/ntp.drift

In der Driftdatei trägt der NTPD die Zeitverschiebung bei einer Aktualisierung ein. Dabei bedeutet ein negativer Wert, dass die Systemzeit vorgegangen war, und ein positiver Wert, dass die Zeit zurücklag.

server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org 

Mit den „server“ Einträgen legt man fest, von welchen Zeitservern sich der Client die aktuelle Zeit holen soll. Es gibt eine Hierarchie unter den Zeitservern. Ein Stratum-0 Server hängt direkt an einer Atomuhr und gibt von dort die Zeit an. Ein Stratum-1 ist ein Server, der sich bereits von einem Stratum-0 Server die Zeit geholt hat. So setzt sich die Kette fort.

Zu dem bietet sich es an, verschiedene Zeitserver auf der ganzen Welt in seine Konfiguration aufzunehmen. Eine Übersicht über alle eingetragenen NTP-Server findet ihr auf http://www.pool.ntp.org/de/ .

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

Mit dieser Einstellung erlauben wir das Abrufen der Zeit von unserem NTPD, jedoch nicht andere Aktivitäten, wie z.B. die Administration des Servers von außen. Diese Regeln gelten jeweils für IPv4 bzw. IPv6. Außerdem erlauben wir den vollständigen Zugriff vom localhost aus, damit wir mit dem Server später einfach kommunizieren können.

Damit wären wir mit der einfachen Konfiguration durch.

Der Start des NTPD

Beim Start des NTP-Daemons muss man beachten, dass man es in ein chroot packt. Das Programm verwendet den Port 123, welcher nur durch einen privilegierten Benutzer geöffnet werden kann. Damit der Service nach seinem Start und der Portöffnung seine erhöhten Rechte wieder verliert, sollte man diesen mit folgenden Parametern aufrufen:

ntpd -g -u ntp:ntp

Das in den Paketen mitgelieferte Startscript beachtet diese Kleinigkeit bereits. Ein Blick zur Vergewisserung kann trotzdem nicht schaden.

Fazit

Mit dem NTPD lässt sich sehr einfach die Zeit auf einem System aktualisieren und synchron halten. Das aktuelle Datum kann dann entsprechend in Logfiles verwendet werden.

Die Idee

Da es keine weiteren Voraussetzungen gibt, setzen wir uns zunächst unser Ziel: Wir möchten später per Liste@domain.de eine Email an mehrere Empfänger weiterleiten, und dabei die Rücksendeadresse auf den Wert liste@domain.de setzen. Der letzte Schritt bietet sich an, damit die Personen die auf eine Email antworten nicht an den eigentlichen Absender schreiben, sondern direkt an die Liste zurück schreiben.

Die Umsetzung

Als erstes müssen wir eine neue .qmail Datei anlegen, welche Maildrop anweist den entsprechenden Mailfilter zu nutzen:

echo "|maildrop /home/$USER/.mailliste" > .qmail-liste

Im nächsten Schritt müssen wir noch die Mailfilter-Datei anlegen. Die Rechte müssen entsprechend gesetzt werden, da sonst Maildrop nicht funktioniert.

touch ~/.mailliste && chmod 600 ~/.mailliste

Den Mailfilter müssen wir dann mit unseren Daten füttern. Dazu öffnen wir die Datei mit dem favorisierten Editor:

logfile "/home/[BENUTZER]/.mailliste.log"

if (/^To:.*liste\@pdomain\.de/:h)
{
  xfilter "/usr/bin/reformail -i 'Reply-To: Mailliste <liste@domain.de>'"
  cc "!empfänger1@other-domain.de"
  cc "!empfänger2@other-domain.de"
  cc "!empfänger3@other-domain.de"
  cc "![...]"
  to "!letzter@other-domain.de"
}

Das Logfile legen wir genauso wie den Filter an:

touch ~/.mailliste.log && chmod 600 ~/.mailliste.log

Was macht der Mailfilter

Zunächst wird das Logfile festgelegt, in dem der Mailfilter seine Aktivitäten niederschreibt. Danach prüft der Mailfilter, ob die Empfängeradresse der Listen-Email entspricht. Ist dies der Fall, wird die Antwortadresse auf die Listen-Email gesetzt. Im letzten Schritt leitet der Mailfilter die Email an alle Personen in der Liste weiter.

Wenn man weitere Empfänger hinzufügen möchte, dann muss man nur einen entsprechenden „cc“-Eintrag hinzufügen. Dabei sollte man beachten, dass bei einer Emailadresse ein Ausrufezeichen davor stehen muss.

Fazit

Man kann mit einfachen Mitteln eine kleine Mailingliste auf dem Uberspace einrichten.

~ Sebastian

Voraussetzungen

Für das Script benötigt man keine Voraussetzungen, welche ein Linuxsystem nicht schon erfüllen würde.

• curl
• sed

Ansonsten benötigt ihr nur eure Logindaten, und die ID des zu ändernden DNS Eintrages Die ID findet ihr ganz einfach heraus, wenn ihr euch den Quelltext des gewünschten Eintrages anschaut:

INWX DNS ID herausfinden

Einrichtung

Die Einrichtung des Bashscripts ist sehr einfach, da ich den Quelltext über GitHub zur Verfügung stelle.

Wir erstellen also zunächst ein neues Verzeichnis im Home-Ordner und laden den Source herunter:

mkdir ~/dyndns && cd ~/dyndns
git clone https://github.com/gehaxelt/Bash-INWX-DynDNS.git .

Danach tragt ihr eure Daten in die „dnsupdate.sh“ ein.

Das Script prüft, ob die zuletzt geprüfte IP-Adresse in der „old.ip“ Datei der aktuellen IP entspricht. Ist dies nicht der Fall, so wird über die INWX-API ein Request abgesetzt, der den entsprechenden Eintrag erneuert.

Damit dieser Vorgang automatisiert alle 5 Minuten ausgeführt wird, müssen wir einen Cronjob erstellen.

crontab -e

Fügt dort die folgende Zeile ein:

*/5 * * * * cd /home/$USER/dyndns && bash dnsupdate.s

Nach dem Abspeichern ist schon alles eingerichtet und funktionsfähig.

Optional

Solltet ihr mit diesem Script einen PC bzw. einen Raspberry Pi ans Internet anschließen, müsst ihr ggf. noch Port-Weiterleitungen im Router einstellen. Wenn ihr den SSH-Server nach außen öffnet, dann solltet ihr am Besten auf PubKey Authentication umsteigen und den Login per Passwort deaktivieren.

Wenn ihr herausfinden möchtet, welche bzw. wie viele IPs  bei einem Loginversuch gescheitert sind, könnt ihr die folgende zwei Befehle ausprobieren:

cat /var/log/auth.log | grep "Connection closed" | grep -oP "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" | sort -u
cat /var/log/auth.log | grep "Connection closed" | grep -oP "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" | sort -u | wc -l

Fazit

Einen eigenen DynDNS zu betreiben ist mit dem richtigen Registrar und der richtigen API nicht sehr schwierig ;)

~ Sebastian

Da die Quelltexte der Tor Software z.T. offen sind, können wir diese einfach herunterladen und selbst kompilieren. Im Großen und Ganzen werden das 4 Compilevorgänge welche wir ausführen werden:

• Openssl
• Libevent
• Tor
• Tor-arm

Da wir keine Rootrechte haben, werden wir uns eine „/“-ähnliche Struktur im Homeverzeichnis anlegen. 

Openssl kompilieren & installieren

Die erste Voraussetzung für Tor ist openssl. Falls das auf dem System noch nicht vorhanden ist, müssen wir es selbst kompilieren. Dazu wechseln wir in den RAM und erstellen einen separaten Ordner:

cd /tmp/ && mkdir openssl && cd openssl

Im nächsten Schritt laden wir uns das Archiv herunter und entpacken es:

wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz && tar xfv openssl-1.0.1e.tar.gz && cd openssl-1.0.1e

Dem Konfigurationstool „config“ übergeben wir unser Homeverzeichnis als Prefix, damit die Dateien für die Installation entsprechend vorbereitet werden.

./Config --prefix=/home/$USER/
make
make install

Nachdem dieser Prozess abgeschlossen ist, können wir mit der nächsten Prozedur anfangen.

Libevent kompilieren & installieren

Für die Bibliothek „libevent“ führen wir ähnliche Schritte aus. Als erstes erstellen wir wieder einen neuen Ordner.

cd /tmp/ && mkdir libevent && cd libevent

Danach wieder den Quellcoder herunterladen, entpacken, konfigurieren und installieren… ihr wisst schon.

wget https://github.com/downloads/libevent/libevent/libevent-2.0.21-stable.tar.gz 
tar xfv libevent-2.0.21-stable.tar.gz
cd libevent-2.0.21-stable
./configure --prefix=/home/$USER/
make && make install

Endlich: Tor kompilieren & installieren

Jetzt können wir den Vorgang endlich für das eigentliche Programm ausführen. Die Prozedur sollte euch mittlerweile schon bekannt sein ;)

cd /tmp && mkdir tor && cd tor
wget https://www.torproject.org/dist/tor-0.2.3.25.tar.gz
tar xfv tor-0.2.3.25.tar.gz
cd tor-0.2.3.25
./configure --prefix=/home/$USER/
make && make install

Jetzt solltet ihr die Tor-Binaries im ~/bin Verzeichnis finden. Bevor ihr Tor ausführt, solltet ihr diesen korrekt konfigurieren. 

Tor als Relay-Node konfigurieren

Im Tor-System gibt es drei verschiedene Servertypen. Die Entry-, Relay- & Exitnodes. Die ersten Beiden sollte man ohne weitere Kopfschmerzen bzw. Probleme betreiben können. Über die Entry-Nodes verbinden sich die Tor-Nutzer mit dem Tor-Netzwerk. Die Relay-Nodes dienen als Zwischenstellen zwischen dem Entry und dem Exit Node. Der Exit-Node ist dann die Schnittstelle zwischen Tor-Netzwerk und Internet. Die Personen, die diese Art von Server betreiben bekommen oft Post von unglücklichen Administratoren bzw. Multimediaunternehmen ;)

Wie auch immer, wir erstellen nur einen Relay-Node, welcher das Tor-Netzwerk erweitert. Tor liefert eine Beispielkonfiguration, welche wir als Grundlage verwenden und als „torrc“ kopieren.

cp ~/etc/tor/torrc.sample ~/etc/tor/torrc

Öffnet diese danach mit eurem favorisierten Texteditor. Die folgenden Einstellungen sollten ähnlich gesetzt werden. (Suchfunktion empfehlenswert):

• ExitPolicy reject *:* # no exits allowed
  
• Nickname MyUniqueNode #Tor nodes nickname
• ORPort 9001 #Tor port
• RelayBandwidthRate 5000 KB # Throttle traffic to 100KB/s (800Kbps)
• RelayBandwidthBurst 5000 KB # But allow bursts up to 200KB/s (1600Kbps)
• Log notice file /home/[BENUTZER]/var/log/tor/notices.log #Logfile
• Log debug file /home/[BENUTZER]/var/log/tor/debug.log #Logfile
• ControlPort 9051 #Controlport
• HashedControlPassword 16:PASSWORT #(siehe weiter unten)

Den Wert für den Eintrag „HashedControlPassword“ müssen wir zunächst generieren. Die benötigten Hashwert erhaltet ihr über folgenden Aufruf:

~/bin/tor --hash-password PASSWORT

Speichert eure Konfiguration und prüft zwei Mal, ob der Wert ExitPolicy korrekt gesetzt ist ;)

Damit wir Tor später unsere Binaries im ~/bin Verzeichnis ohne weitere Umstände ausführen können, fügen wir den Pfad einfach zur PATH Variable hinzu:

export PATH=$PATH:/home/$USER/bin

Ihr solltet nun Tor über die Eingabe von „tor“ direkt ausführen können. Tor sollte ohne weitere Fehlermeldungen starten, und anfangen seine Arbeit als Relay-Node aufzunehmen. Voraussetzung ist, dass die oben angegebenen Ports von Außen erreichbar sind.

Tor-Arm installieren

Es bietet sich immer an, eine textbasierte UI zu haben, um Informationen über den Torserver zu erhalten. Dazu bietet sich das kleine Tool „tor-arm“ an. Es basiert auf Python. Ich gehe davon aus, dass Python bereits auf dem System zur Verfügung gestellt wird. Andernfalls muss Python nach dem zuvor gezeigten Schema installiert werden.

Um Tor-arm einzurichten, müssen wir ein wenig an den Dateien rum basteln. Zunächst laden wir diese aber erstmal herunter und entpacken das neue Archiv.

mkdir /tmp/torarm && cd /tmp/torarm
wget http://www.atagar.com/arm/resources/static/arm-1.4.5.0.tar.bz2
tar xfv arm-1.4.5.0.tar.bz2 
cd arm

Danach müssen wir  einen Ordner für arm erstellen und die Dateien kopieren:

mkdir -p ~/etc/arm/
cp src/* ~/etc/arm/

Also nächstes kopieren wir das zum Starten benötigte Shellscript:

cp arm ~/bin/

Dieses Script müssen wir noch ein wenig bearbeiten. Öffnet die Datei unter ~/bin/arm und ändert die ersten Zeilen ab:

if [ "$0" = /home/$USER/bin/arm ]; then
  arm_base=/home/$USER/etc/arm/

Speichert die Datei ab. Jetzt solltet ihr „arm“ aufrufen können und es sollte euch nach dem Control-Passwort fragen. Habt ihr dieses eingegeben, dann sollte euch eine schöne UI über euren Tor-Node informieren.

Fazit

Der Artikel wurde am Ende doch etwas länger als erwartet. Ich hoffe aber trotzdem damit einige zu motivieren einen kopfschmerzfreien Tor-Relay Node aufzusetzen, um das Tor-Netzwerk zu unterstützen. Wer die ganzen Quelltexte nicht selbst kompilieren möchte, der kann auf fertige Pakete zugreifen: tor, tor-arm.

~Sebastian

Die Idee

Ich gehe mal davon aus, dass man bereits einen Teamspeak3 Server auf seinem (V)Server laufen hat. Da es scheinbar nicht möglich ist, den Teamspeak3 Client headless laufen zu lassen, brauchen wir  als eine grafische Oberfläche. Dieses Problem lösen wir später ganz einfach mittels einem VNC-Server, auf den wir uns verbinden. Wir starten über den VNC den Teamspeak3 Client mit dem konfigurierten Soundboard Plugin, welches uns dann die Musik streamt.

Die Umsetzung – Server

Als erstes aktualisieren wir die Paketlisten und installieren uns die grafische Oberfläche, sowie VNC4Server (mit Fluxbox).

sudo apt-get update
sudo apt-get install vnc4server fluxbox twm unzip wget xterm

Sind diese Pakete installiert, legen wir uns einen neuen Benutzer an:

sudo useradd -s /bin/bash -m ts3music
sudo passwd ts3music

Ist das geschehen, dann nehmen wir des Benutzers Identität an.

sudo su ts3music && cd

Als nächstes setzen wir das VNC Passwort. ACHTUNG: Aus unerklärlichen Gründen wird das Passwort nach 8 Zeichen abgetrennt. Diese ersten 8 Zeichen sollten also möglichst komplex sein.

vncpassword

Im nächsten Schritt passen wir das VNC-Startupscript ein wenig an. Die Konfigurationsdatei befindet sich unter „~/.vnc/xstartup“. Die Datei sollte nach der Bearbeitung so ähnlich aussehen:

#!/bin/sh

# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
fluxbox &

Damit ist die Konfiguration abgeschlossen, und wir können den VNC-Server starten:

vncserver

Die Serverseite ist soweit fertig.

Die Umsetzung – Client

Nachdem der VNC-Server auf dem Server läuft, müssen wir von unseren lokalen Rechner noch darauf verbinden. Dazu müsst ihr euch das Paket „vncviewer“ installieren.

sudo apt-get install vncviewer

Ruft als nächstes das Programm folgendermaßen auf:

vncviewer [SERVER]:1

Dabei steht :1 für die erste Session des VNC-Servers. Ihr werdet zur Eingabe des Passworts aufgefordert. Ist dieses korrekt, solltet ihr ein Fenster mit der grafischen Oberfläche des Servers sehen.

Teamspeak + Soundboard installieren

Als nächstes fehlt uns nur noch der Teamspeak-Client und das dazugehörige Plugin. Die folgenden Aktionen könnt ihr über den VNC auf dem Server ausführen.

mkdir ~/TeamspeakMusic && cd ~/TeamspeakMusic/
wget http://ftp.4players.de/pub/hosted/ts3/releases/3.0.10.1/TeamSpeak3-Client-linux_amd64-3.0.10.1.run -O teamspeak.run
chmod +x teamspeak.run
./teamspeak.run

Ihr werdet aufgefordert die Lizenzbestimmungen zu akzeptieren, und danach entpackt sich der Teamspeak3 Client in sein eigenen Verzeichnis.

In diesem Verzeichnis solltet ihr dann den Ordner „plugins“ finden. Dort wechseln wir zunächst rein.

cd plugins

Jetzt fehlt uns nur noch das Soundboard-Plugin, welches wir einfach herunterladen und entpacken:

wget http://www.kampfrausch.de/ts3/soundboard-0.9.9.3b-linux-amd64.ts3_plugin -O soundboard.zip && unzip soundboard.zip

Im letzten Schritt des Installationsvorgangs müssen wir die entsprechenden Dateien noch aus dem neuen „plugins“ Verzeichnis ins korrekte „plugins“ Verzeichnis verschieben. Da dies ein wenig verwirrend sein kllingt, hier eine deutlichere Darstellung:

mv ~/TeamspeakMusic/plugins/plugins/* ~/TeamspeakMusic/plugins/

Die Plugindatei muss noch ausführbar markiert werden:

chmod +x libsoundboard_plugin.so

Musik streamen

Damit wir das Soundboard Plugin nutzen können, müssen wir uns mit dem VNC-Server verbinden:

vncviewer [SERVER]:1

Nach der Eingabe des Passworts, solltet ihr einen Remotedesktop des Servers haben. Ihr wechselt in einer Konsole ins ~/TeamspeakMusic Verzeichnis und führt dort „ts3client_runscript.sh“ aus.

cd ~/TeamspeakMusic && ./ts3client_runscript.sh

Es sollte nun eine Instanz des Teamspeak-Cliensts gestartet sein. Verbindet euch im ersten Schritt mit dem gewünschten Teamspeak3 Server, auf dem später die Musik laufen soll.

Damit die Musik dauerhaft laufen kann, müssen wir noch „Dauersenden“ einstellen. Dazu geht ihr auf Einstellungen->Optionen->Aufnahme und wählt den Menüpunkt „Dauersenden“.

Die Einstellungen des Soundboard Plugins findet man über Einstellungen->Plugins->Soundboard (Doppelklick). Unter dem Button „Show“ verbergen sich die einzelnen Knöpfe, auf welche man per Drag & Drop Lieder ziehen, und diese abspielen kann.

Teamspeak Client Soundboard Plugin

Auf den ersten Blick fand ich keine Möglichkeit einen Ordner mit Musikdateien anzugeben, welche Soundboard in einer Schleife abspielt, sodass ich mich für eine Weiterleitung eines Streams entschieden habe.

Dafür sucht man sich die Stream-URL, welche man einfach aus den Playlist-Dateien (.pls) entnehmen kann, und schreibt folgendes in die Chatzeile:

/soundboard stream URL

Daraufhin sollte der Musikbot anfangen den Stream an die anderen Leute im Channel zu streamen. Als Beispiel biete ich mal den Q-Dance-Radio Stream an, dessen URL folgendermaßen lautet:

http://stream01.platform02.true.nl:8000/qdance-hard

Die Lautstärke sollte man gegeben falls noch anpassen – Die Zuhörer können je nach Setup den Pegel des Musikbots einstellen.

Fazit

Musik entspannt beim Zocken ungemein (meine Meinung ;) ) und wenn man diese zugleich mit seinen Mitspielern teilen kann, ist es umso schöner. Mir gefällt jedoch die 8-Zeichen Passwortbeschränkung des VNC-Servers nicht. Trotzdem hoffe ich, dass ich einigen Menschen helfen konnte.

~Sebastian

Voraussetzungen

Es gibt nicht viele Voraussetzungen, die man erfüllen muss. Genauer gesagt, sind es genau zwei:

• Ein gerootetes Handy, auf dem man root-Rechte hat
• Die App „Linux Deploy“
  [appbox googleplay ru.meefik.linuxdeploy ]

Erfüllt man die erste Voraussetzung, und hat die genannte App installiert, kann des Linuxs Einrichtung beginnen.

Die Installation

Nachdem die App gestartet wurde, geht man auf das Download-Symbol unten rechts. Daraufhin öffnet sich der Konfigurationsdialog. Ich habe der Einfachheit halber ein Debian gewählt, und das .img-File auf 2GB begrenzt. Die Dateigröße sollte man überlegt wählen, da der Versuch, diese später zu vergrößern scheiterte. Den Benutzernamen habe ich auf „linux“ gesetzt.

Konfiguration – Teil 1

Ansonsten empfehle ich, nur den SSH-Server als Service installieren zu lassen. VNC bzw. die graphische Oberfläche würden nur viel Speicherplatz und Ressourcen verbrauchen.

Konfiguration – Teil 2

Sind diese Einstellungen nach dem eigenen Belieben getroffen, kann man ganz oben auf „Installieren“ drücken. Man benötigt eine möglichst stabile WLAN-Verbindung, und etwas Zeit, bis das System eingerichtet ist.

Start & Einrichtung

Um das Linux-System zu starten, drückt man einfach einmal auf den „start“-Button. Man sollte eine ähnliche Ausgabe erhalten:

Linux Deploy – Startvorgang

Im nächsten Schritt bietet es sich an, das Handy per USB-Kabel an den PC anzuschließen, und sich per adb shell darauf zu verbinden:

adb shell

Wir sind nun in der ADB Shell und können dann auf den SSH-Server verbinden:

ssh linux@127.0.0.1

Den Umweg über ADB muss man nicht unbedingt machen, da man die Linux-VM auch von „außen“ erreichen kann. Die jeweilige IP steht in der Linux Deploy App im oberen Teil des Bildschirms.

Das Passwort ist standardmäßig auf „changeme“ gesetzt. Dieser Anweisung wollen wir folge leisten, und ändern als erstes das Passwort.

passwd linux

Ihr werdet aufgefordert das aktuelle Passwort, sowie zweimal das neue Passwort einzugeben. Ich empfehle hier ausdrücklich ein starkes Passwort zu wählen, da der SSH-Services von außen erreichbar ist.

Bevor man effektive mit dem System arbeitet, kann es von Vorteil sein, sich die aktuellsten Paketlisten herunterzuladen:

sudo apt-get update

Die neusten Pakete sollten bereits vorhanden sein, sodass ein „upgrade“ keine Auswirkungen zeigen sollte.

SSH Verbindung aufs Handy

Es steht einem nun ein ganz normales Debian-System zur Verfügung.

Fazit

Danach sollte einem nichts mehr im Wege stehen, das Linuxsystem für seine Zwecke zu nutzen. Ich habe zum Beispiel IoQuake3 jetzt auf dem Handy eingerichtet :)

~Sebastian