Patricks Blog

Heute berichtete Ulli am Clubabend über Blogs. Das hier ist ein Demo-Post.

Auf dem CCWN-Server war die 2te Platte irgendwann diese Woche kaputt gegangen… Den größten Aufwand hat das Komplettbackup des Servers verursacht, läppische 5 Stunden.

Den eigentlichen Austausch der Platte hat Hetzner dann binnen einer halben Stunde erledigt, wobei ein Großteil der Zeit auf mein Greylisting zurückzuführen ist… Da muss man doch echt mal ein Lob aussprechen, sowas nenne ich erstklassigen Support!

Auf schokokeks.org bin ich auf ein echt praktisches Tool gestoßen: free web vulnerability scanner (freewvs) durchsucht Homedirectories nach verwundbaren Webapplikationen. Das Tool ist OpenSource und unter der GPLv3 erhältlich.

Ein aktuelles Problem sind offenbar die Aktualisierungen für die Webapplikationen. Vielleicht wäre es an dieser Stelle auch sinnvoll eine Updatemöglichkeit über das Internet vorzusehen. Mal schauen ob ich nach der Prüfungsphase an der BA dazu komme sinnvolle Dinge zu tun und evtl. nen Patch liefere.

OpenVZ bietet von sich aus keine Methode um die Virtuellen Maschinen (VE) sinnvoll zu sichern. Allerdings sind die VEs vom Hauptsystem aus gesehen nichts anderes als “normale” Ordner. Sofern man die VE stoppt, kann man auf diesen Dateien auch ohne Probleme ein Backup starten.

Nun will man aber bekannterweise für ein Backup den Server nur kurz oder am Besten überhaupt nicht herunterfahren. Die optimale Lösung mit nicht herunterfahren war mir zu stressig, für das nur kurz herunterfahren war aber schnell die Lösung gefunden: rsync mit dem Parameter –link-dest. So muss ich nur einmal ein volles Backup ziehen und rsync erzeugt bei allen darauffolgenden Backups Hardlinks im Dateisystem und reduziert so ganz nebenbei auch noch den Platzbedarf für die Backups. Trotzdem sieht jeder Backupordner wie ein vollständiges Backup aus.

Um das ganze jede Nacht zu automatisch laufen lassen zu können, habe ich noch eine kleine Schleife um das eigentliche Backup gebaut, die die aktuell laufenden VEs automatisch findet und sichert. Aktuell nicht aktive VEs werden auch nicht gesichert, an ihnen werden ja auch keine Änderungen durchgeführt. Sollte also eine VE dazu kommen, so wird in der darauf folgenden Nacht automatisch ein Full-Backup der VE geschrieben und solange die VE aktiv ist diese auch automatisch inkrementell gesichert.

[CODE]
#!/bin/bash

DATUM=`date +%F`;
VZ_HOME=/vz/private
BKP_BASE=/backup/virtual
LAST_RUN=`cat $BKP_BASE/lastRun.date`

for veid in `ls $VZ_HOME`;
do
if [ `vzctl status $veid | awk '{print $5}'` == "running" ]; then
if [ ! -d $BKP_BASE/$veid ]; then
mkdir -p $BKP_BASE/$veid;
fi;
echo “Backing up VE $veid”;
BKP_PATH=”$BKP_BASE/$veid/$DATUM”;
vzctl stop $veid;
rsync -a –delete –link-dest=$BKP_BASE/$veid $LAST_RUN $VZ_HOME/$veid/ $BKP_BASE/$veid/$DATUM;
vzctl start $veid;
fi;
done;
echo $DATUM > $BKP_BASE/lastRun.date
[/CODE]

Was noch fehlt ist ein Script, dass die angelegten Daily Backups ausdünnt und so Monthly und Yearly Backups anlegt. Die Ordner der Daily Backups können einfach gelöscht werden, da verlinkte Dateien erst vom Dateisystem verschwinden, wenn der letzte Link gelöscht wurde…

Da will man nur nen Ordner von ner anderen Platte in eine virtuelle Maschine mounten und scheitert mit mount –bind kläglich… Und dann ist die die Lösung einfach, dass man anstatt direkt in /vz/private/xxx zu mounten eben in /vz/root/xx mounten muss :wallbash

WebSVN hatte ich mir schon vor einer ganzen Weile einmal für die Arbeit angeschaut. Es bietet einen schnellen Browser für Subversion Repositories und muss, im Gegensatz zu Trac, nur einmal aufgesetzt und gewartet werden…

Auch Syntaxhighlighting, Blames, und Versionsunterschiede kann WebSVN gut und schnell darstellen. Allerdings ist das “normale” Layout leider sehr schlicht und die Unterstützung unter Solaris nur sehr bescheiden weswegen ich WebSVN letztendlich aus den Augen verlor und wir für die meisten Projekte Trac einsetzen…

Nun hat aptgetupdate.de einen Artikel über ein WebSVN-Theme geschrieben, welches zumindest die Hässlichkeit von WebSVN aus dem Wege schafft… Das hat mich an meine Versuche vor 2 Jahren erinnert… Auf dem CCWN-Server läuft ausserdem auch kein Solaris sondern “nur” ein Debian, so konnte ich schwups via apt-get install websvn installieren: Das optische Resultat ist ersteinmal das hier:

Nachdem ich aber die Hürden der Templateinstallation (elendige halb-absolute Pfade im Dokument) überwunden hatte, erstrahlt das WebSVN nun im neuen Glanze des Calm-Themes von ContactSheet.de :

Es hat mich schon immer gestört, dass man oft hinter Firewalls sitzt die alles abdichten und man nach aussen keinen Shell-Zugriff hat. Schwups, der Mailserver ist tot… Warten bis heute abend bevor ihn jemand neu starten kann…

Damit ist jetzt erstmal Schluß. Vor ein paar Monaten bin ich im Web über ajaxterm gestolpert und habe es mal zum Spass auf einer Testmaschine installiert. Hat mich mächtig beeindruckt was per Ajax da so alles möglich ist. Und unter debian ist das ganze auch noch schnell per apt-get install ajaxterm installiert. Aaaaaber: Ajaxterm hört erstmal nur auf 127.0.0.1, sicher ist sicher und das Terminal ist nunmal nicht sicher.

Also muss erst einmal sichergestellt werden, dass wir eine sichere Verbindung zum Terminal aufbauen können. Da es sich hier um http handelt bietet sich https als SSL-Verschlüsselte alternative geradezu an. Schwups ein a2enmod ssl und ein paar openssl Befehle und der Apache kann https. Das Zertifikat habe ich gleich mal bei CAcert.org zertifizieren lassen, hier gibt es wenigstens noch (geringe) Chancen dass das Root-Zertifikat endlich mal per default in den Browsern landet.

Jetzt kann also der Apache https… Aber das Terminal hat doch seinen eigenen “Webserver”… Also müssen wir Apache beibringen Proxy zu spielen (umgeht auch gleich das Problem mit 127.0.0.1:8022):
1 a2enmod http_proxy und 5 Zeilen in der Config später leitet /myterminal/ auf das lokale Ajaxterm um.

Was haben wir bis jetzt: Wir können uns SSL Verschlüsselt (https) an einem Terminal anmelden Ist eigentlich fast sicher… Wobei, evtl. könnte ja das Python-Skript noch einen Fehler haben, der es ermöglich ohne Auth an eine Shell zu kommen… Also noch schwups nen htpasswd-Schutz davor legen und wir sind auch wirklich “sicher”. Spielereien mit OpenVPN und Konsorten würden die Sache mit der Firewall wieder erschweren, also bleiben wir beim aktuellen Schutzlevel mit htpasswd und SSL.

For all English speakers coming from Marcs Blog there is a good installation guide concerning security in the ajaxterm wiki.

Hätte ich mir das ajaxterm wiki früher angeschaut, dann hätte ich auch nicht jeden noch so kleinen Schritt in der Doku nachschlagen müssen, vor allem mod_proxy ist da nicht so toll…

Im LinuxMagazin bin ich heute morgen auf einen Artikel über SyncML gestolpert und war gleich von der dort beschriebenen Lösung Funambol begeistert. Der Server synchronisiert so in etwa mit jedem möglichen SyncML-fähigen Gerät plus zusätzlich mit einigen anderen Clients. So bietet das Projekt Clients für M$ Outlook, Windows Mobile (endlich!) und Thunderbird / Sunbird.

Sobald die Zeit da ist, werde ich dem CCWN mal eine Testinstallation gönnen und mich daran machen, den Google Calendar auch irgendwie mit in den Server zu syncen …

Die Altstadtfesthomepage ist ein klein wenig aus dem Fokus des Blogs geraten. Tatsache ist, dass das Altstadtfest jetzt vorbei ist, die Homepage rechtzeitig fertig war (von so Dingen wie dem Bearbeiten-Formular für die Vereine selbst einmal abgesehen) und auch den Besucheransturm während dem Altstadtfest gut überstanden hat.

Verwendet wurden nun: Symfony als Backend, Joomla! als Frontend, diverse Plugins für Joomla! und die Joomlabridge für Symfony in einer erweiterten Version. Die Joomlabridge ist nur suboptimal, da sie leider keinerlei Möglichkeiten zur Benutzerauthetifizierung hat, aber als quick-and-dirty-Lösung war sie gerade richtig und hat uns viel Arbeit erspart.

Vielen Dank an Michael Brenner und Tristan Zur an dieser Stelle, die 2 haben das Projekt einen großen Schritt vorran gebracht und es überhaupt erst ermöglicht, dass wir zum Altstadtfest fertig waren.

Für Eclipse gibt es jetzt ein Framework, um perfekte AJAX Applikationen zu bauen… Einfach so tun als wollte man ein Eclipse Plugin bauen, und anstatt dem normalen RCP RAP verwenden… Schwups hat man eine absolut coole AJAX-Applikation!

Wenn jetzt Tristan noch unseren Server auf test.ccwn.org zum Laufen bekommt können wir tolle Software scheiben.. Leider scheint RAP noch nicht so weit zu sein, dass man es “einfach mal so” installieren kann

In Verbindung mit smack einer Jabber Library lässt sich dann sicher n cooler AJAX-Jabber-Client bauen