Die Suppe sichern

Die Suppe ist mit Sicherheit in toller Dienst, aber leider ist die Erreichbarkeit und Stabilität des Dienstes eher “wackelig”. Die Zukunft der Suppe ist auch nicht so wirklich bekannt und ein wirkliches Businessmodell dahinter kennt auch keiner. Daher rechne ich leider ständig mit dem endgültigen Aus der Suppe. Da ich aber meine Inhalte nicht verlieren möchte, da es manchmal auch Spaß mach in der Suppe weiter nach unten zu scrollen und zu schauen, was man so vor einer Woche, einem Monat, oder gar einem Jahr lustig, witzig oder einfach nur schön fand, will ich diesen nicht verlieren.

Daher sichere ich nun regelmäßig meine Suppe (alle von mit geposteten oder rebloggten Einträge). Dazu verwende ich das Script “soup-backup.sh” von neingeist. In dem ReadMe zu dem Script steht zwar in der ersten Zeile, dass das Script nicht mehr funktioniert, der der RSS-Export der Suppe kaputt sei, aber dem ist nicht so. Der tut und damit auch das Script.

Die Installation ist denkbar einfach. Das Script auf dem Rechner, von dem aus die Backups gemacht werden sollen, ablegen und mit

./soupbackup.sh http://www.soup.io/export/$komischerhash.rss

aufrufen. Den Export-Link, den man dem Script als Parameter übergeben muss, findet man übrigens gut versteckt in den Einstellungen der Suppe unter dem Punkt Privacy / Privatsphäre und dann der kleine, graue Button Export (RSS) / Exportieren (RSS) (siehe Bild)

Link auf den RSS-Feed der eigenen Suppe

Link auf den RSS-Feed der eigenen Suppe

Das Script dann am Besten via Cron regelmäßig aufrufen und schon hat man eine tolle Sicherung seiner Suppe. Und das Script sicher nur die neuen Inhalte, die seit dem letzten Sicherungslauf dazu kamen, geht also schonend mit Bandbreite und Speicherplatz um.

Jetzt habe ich viel von meiner Suppe geredet, aber sie nirgends verlinkt. Daher hier der Link: http://telegnom.soup.io

Und nun viel Spaß beim Sichern eurer Suppen!

ctime einer Datei manipulieren

Nicht oft, aber manchmal kann es nötig sein die ctime (change time) einer Datei zu verändern. Das ist leider mit den Boardmitteln der gängigen Distributionen nicht möglich, Abhilfe schaft hier das Programm stroke. Damit ist es, im Gegensatz zu touch, möglich neben der atime und der mtime auch die ctime zu verändern. Auf der Seite des Tools kann man sich die Quellen runter laden. Das Bauen ging schnell und einfach, jedenfalls unter meinem Ubuntu 10.04 LTS.

Datenverlust beim Formatieren

Ubuntu warnte mich heute, dass ich den Datenträger erst entfernen soll, wenn das Formatieren des selbigen abgeschlossen sei, um möglichem Datenverlust vorzubeugen. Wie gesagt, ich formartierte den Datenträger! Dabei will ich dass die Daten auf ihm verloren gehen! Die Meldung sollte Canonical vielleicht doch noch mal überarbeiten ;)

DICOM-(Röntgen)Bilder in pngs umwandeln

Innenansichten eines Knies

Innenansichten eines Knies

DICOM ist ein offener Quasistandard zum Austausch von “medizinischen” Bildern, also CT, Röntgen, etc. Wenn man von einem Arzt eine CD mit seinen Bildern bekommt, ist da nur ein “Viewer” für Windows drauf, was einem unter Linux nicht so viel hilft. Es gibt aber medcon, ein Tool das verschiedene “medizinische Bildformate” umwandeln kann. Unter Ubuntu 10.10 ist medcon in den Quellen und man kann es einfach mit apt-get install medcon installieren. Danach kann man die Bilder mit medcon -c png -f $originaldatei -o $ausgabedatei in PNGs umwandeln, die man dann wieder problemlos anschauen kann ;)

Softwareraid (5) mit Debian Squeeze

Wie man einen Raid 5 (über 4 Platten) unter Debian Squeeze zusammen zimmert ist nachfolgend beschrieben. Ich gehe davon aus, dass die Platten /dev/sdb,c,d,e verwendet werden.

  1. mdadm Installiern
    apt-get install mdadm
  2. Platten “deformatieren”
    fdisk /dev/sdb,c,d,e

    mit “d” alle Partitionen löschen. Fdisk mit “w” beenden, um die Änderungen auf die Platte zu schreiben.

  3. Raid bauen
    mdadm --create --level=5 --raid-disks=4 --bitmap=internal /dev/sd["bcde"]1
  4. Dateisystem erzeugen
    mkfs.ext4 /dev/md0

Und schon ist der Zauber fertig ;)

mpd – Lautstärke regeln mit alsa

Bei meiner neuen MPD-Installation wollte sich die Lautstärke nicht remote regeln lassen. Im alsamixer hatte ich gesehen das der “Ausgabekanal” Master heißt. In der /etc/mpd.conf steht jedoch bei mixer_control Default als Voreinstellung. Als das passend geändert und schon lässt sich auch die Lautstärke regeln :) Hier noch er entsprechende Ausschnitt meiner mpd.conf

audio_output {
	type		"alsa"
	name		"My ALSA Device"
	device		"hw:0,0"	
	format		"44100:16:2"
	mixer_device	"default"	
	mixer_control	"Master"
	mixer_index	"0"
}

etherpad – q’n'd

Ganz kurze Etherpad Version 1.1 Installationsanleitung für Debian lenny und Ubuntu 10.04

  1. Quellen in /etc/apt/sources.list eintragen
    echo "deb http://apt.etherpad.org all ." >> /etc/apt/sources.list
    echo "deb http://ftp.de.debian.org/debian sid main non-free" >> /etc/apt/sources.list
  2. apt-get update
  3. apt-get install etherpad
  4. diff auf /etc/init.d/etherpad anwenden
    50c50
    < DAEMON_BASE="/usr/local/etherpad"
    ---
    > DAEMON_BASE="/usr/share/etherpad"
  5. /etc/init.d/etherpad start
  6. Zusätzliche Quellen aus der /etc/apt/sources.list wieder entfernen

kurzes Update
Unter Squeeze muss man natürlich nur deb http://apt.etherpad.org all in die /etc/apt/sources.list eintragen. Die anderen Sachen sind ja aus den Squeeze Quellen geklaut :)

etherpad installieren – die komplette Geschichte

Etherpad zu installieren ist keine besondere Freude, wenn man sich so die Kommentare anschaut, die man im Web findet. Trotzdem habe ich mich an die Installation gemacht, da ich Etherpad für eine tolle Sache halte. Klar es gibt auch Dienste bei denen man sich einfach ein Pad klicken kann, aber eigentlich halte ich meine Daten lieber auf meinem Server als irgendwo bei einem Anbieter. Es reicht ja schon, dass ich meinem Server-Anbieter vertrauen muss :(

Wenn man Debian lenny nutzt, so wie ich, muss man zunächst (nur für die Installation!) die Debian sid Quellen in die /etc/apt/sources.list eintragen, sowie das etherpad-repo.

1
2
echo "deb http://apt.etherpad.org all ." >> /etc/apt/sources.list
echo "deb http://ftp.de.debian.org/debian sid main non-free" >> /etc/apt/sources.list

Danach muss  man ein

apt-get update

machen, damit die Quellen neu eingelesen werden. Danach kann man Etherpad mit

apt-get install etherpad

installieren. Nach der Installation sollte man die Sid-Quellen wieder aus der sources.list entfernen, da man sonst mit einem apt-get dist-upgrade das gesamte System auf Sid aktualisiert. Je nach dem welche Pakete bereits installiert sind, lädt apt-get nun bis zu 350MB an Paketen runter (java, mysql, java-mysql-connector, scala, openoffice und etherpad selbst). Im Lauf der Installation frag apt-get nach den Daten für den Datenbankbenutzer und das mysql-rootpasswort um die nötigen Datenbank einrichten zu können. Die Installation dauerte auf meinem V-Server von HostEurope etwa 10 Minuten. Die Installation lief bei mir erfolgreich und ohne Fehler durch. In leichter Euphorie, dass die Installation doch besser funktionierte als beschrieben, tippte ich /etc/init.d/etherpad start und es passiert… nichts! Ich suchte ein wenig in meinem System herum und fand das Script /usr/share/etherpad/etherpad/bin/run-local.sh Ich führte es aus und ertrank in einer Flut von Fehlermeldungen. Erst nachdem ich in den Ordner /usr/share/etherpad/etherpad gewechselt war, konnte ich das Script nun mit bin/run-local.sh starten. Etherpad lief und ich konnte es erreichen und ein neues Pad anlegen, bearbeiten. Nur dummerweise lief der Etherpad-Prozess jetzt als Child-Prozess meines Terminals, d.h. beim schließen der ssh-Verbindung würde auch mein Etherpad gestoppt werden. Aus der Shell ließ sich Etherpad nun also starten, aber nicht als Daemon. Ich schaute mir nun also das Script /etc/init.d/etherpad mal etwas genauer an. Nach längerem suchen entdeckte ich einen Fehler in der Zeile 50. Dort steht:

DAEMON_BASE="/usr/local/etherpad"

Die Dateien von Etherpad lagen in /usr/share/etherpad aber das Startscript zeigt nach /usr/local/etherpade. Das musste der Fehler sein, der mich davon abhielt Etherpad zu starten. Also die Zeile entsprechend geändert und nochmal versucht Etherpad zu starten. Diesmal dauerte es schon etwas länger bis ich meinem Promt zurück bekam, aber ein

/etc/init.d/etherpad status

sagte mit das Etherpad nicht gestartet sei. Ich versucht es nochmal mit dem Script direkt zu starten. Es funktionierte immer noch ohne Probleme. Also google fragen, dachte ich mir und wurde auch schnell fündig. Auf http://localhost.bdjl.de/?p=1489&cpage=1 fand ich zwar nur das Problem, dass ich schon kannte, und gelöst hatte, und in den Kommentaren dann auch mein aktuelles Problem. Dadurch dass ich Etherpad einmal aus der Konsole als root gestartet hatte, gehörten die Log-Files alle root und sie konnten nicht geöffnet werden. Da es nicht loggen konnte, verweigerte Etherpad den Dienst. Nach dem ich die Log-Datei mit

chown -R etherpad:etherpad /var/log/etherpad

wieder auf den Benutzer etherpad, unter dem Etherpad als Daemon läuft, umgebogen hatte ließ sich auch der Daemon ordentlich starten :)

Update für den JOSM-SVN-Updater

Ich habe meinem kleinen JOSM-SVN-Updater, diesem kleinen Script, das die aktuelle JOSM-Version aus dem SVN baut überarbeitet und um zwei Optionen erweitert. Mit der Option -l lässt sich nun die Version der lokalen Kopie des SVN anzeigen und mit -o die aktuelle Versionsnummer der SVN-Version auf dem josm.openstreetmap.de Server.

Dabei habe ich auch gleich in der Standardeinstellung die 2D-Beschleunigung deaktiviert, da diese wohl auf zahlreichen Systemen mehr Ärger verursacht, als das sie nützt. Haben mir jedenfalls einige User aus #osm-de erzählt.

Firefox synchronisieren

Mit Mozillas Firefox Plugin “Weave” kann man seine Firefox-Installationen auf mehreren Rechner synchronisieren. Dabei kann Weave mehr als die bekannten Plugins wie “XMarks”. Denn Weave synchronisiert nicht nur Lesezeichen und gespeicherte Passwörter, sondern kann auch die Historie und offene Tabs synchronisieren. Das beste daran ist aber, dass man dazu seine Daten noch nicht einmal in fremde Hände geben muss. Wer über einen eigenen Webserver verfügt, kann sich seinen eigenen Weave-Server aufsetzen, und das ohne all zu großen Aufwand. Wie man es macht beschreibe ich im folgenden:

Es gibt zwei Versionen des Weave-Servers. Zum einen gibt es den “original” Mozilla Weave Server, den ich mir allerdings nicht weiter angesehen habe, und zum anderen den Weave Minimal Server, auf dessen Installation ich hier im Folgenden näher eingehen werde. Für eigene Installationen empfiehlt Mozilla auch die Verwendung der in PHP implementierten minimal Version.

Voraussetzung für den Betrieb des Weave Minimal Server

  • Laufender Webserver (Apache oder Lighttpd funktionieren)
  • php > 5.0 (?)
  • sqlite

Weiterhin benötigen man Zugriff auf die Konfiguration des Servers. Bei Apache dürfte auch htaccess reiche, da man einen Rewrite einrichten muss.

Installation

Die Installation ist denkbar einfach. Der Tarball wird in ein Verzeichnis des Webservers entpackt (z.B. /var/www/weave). Die Benutzerrechte der Dateien müssen so angepasst werden, dass der Benutzer unter dem der Webserver läuft die Dateien lesen und ausführen kann. Weiterhin muss der Benutzer das Verzeichnis der Installation beschrieben dürfen, um die SQlite Datenbank anlegen zu können. Nach dem die Dateien entpackt und die Rechte angepasst wurden, muss die Konfiguration des Webservers um die oben bereits erwähnte Rewrite-Regel erweitert werden.

Bemerkungen

Es ist prinzipiell möglich den Server auf http zu betreiben. Ich schließe mich an dieser Stelle allerdings der Meinung Mozillas an, dass dies wenig ratsam ist. Immerhin werden hier Psswörter etc. übertragen. Auch wenn die Passwörter von dem Firerox-Plugin verschlüsselt werden, rate ich jedem an dieser Stelle https einzusetzen.