Nach der Installation merkte ich, dass meine CPU immer zwischen 80-90% ausgelastet war, obwohl die VM eine Load von 0 hatte und nichts machte.

Es hat mich einige Zeit gekostet den Fehler zu finden. Grund hierfür war der Kernel von CentOS, dieser wurde nämlich mit einem internem “Takt” von 1000Hz kompiliert. Andere Distributionen verwenden hier noch 100Hz. Dies hatte zur Folge, dass VirtualBox sehr viel zu tun hatte und die CPU im Host-System nahezu ausgelastet war.

Das Problem kann aber recht einfach gelöst werden, indem der Kernel mit der Option divider=10 gebootet wird. Einfach an die Kernel Zeile in der grub.conf hängen und alles läuft.

Ich habe mir einige Zeit lang alle möglichen Receiver angeschaut, jedes Gerät kann so ziemlich das gleiche, sehen aber immer irgendwie optisch nicht ansprechend aus. Immerhin soll so ein Gerät sich auch richtig in die Einrichtung integrieren.

Nur Harman Kardon hatte auch optisch ansprechende Receiver, deswegen entschied ich mich für den AVR 255. Nachdem alles verkabelt wurde, war ich einfach nur begeistert. Selbst mit meinen alten Boxen (Canton) hörte man einen deutlichen Unterschied. Mit den 3 HDMI Eingängen konnte ich auch endlich alle Geräte zentral am Receiver anschließen und nicht immer beim Fernseher den Eingangskanal wechseln.

Da ich nur 5 Boxen hatte, musste ich den Receiver auch für Dolby 5.1 konfigurieren. Allerdings fand ich durch Zufall heraus, dass die 2 unbenutzten Boxenanschlüsse (eigentlich für 7.1 Anlegen gedacht) auch zur Beschallung eines anderen Raumses verwendet werden können. Da ich im Arbeitszimmer noch 2 Boxen an der Wand habe, welche momentan nicht benutzt wurden, habe ich die kurzerhand an den 2 freien Ausgängen angeschlossen. Durch den Mehrraumanschluss habe ich jetzt die Möglichkeit über den Receiver z.B. im Arbeitszimmer Radio zu hören und im Wohnzimmer fernzusehen. Natürlich kann man auch nur eine Quelle verwenden, um beide Räume zu beschallen.

Ebenfalls interessant ist die Art und Weise wie die Boxen eingerichtet werden. Mitgeliefert wird ein Mikrofon, welches sogar auf ein Foto Stativ angebracht werden kann. Dieses Mikrofon muss dort positioniert werden, wo man gewöhnlich sitzt. Der Receiver schickt nun ca. 5 Minuten aus jeder Box Tonsignale um die Boxen perfekt einzustellen.

Das einzige was noch fehlt, sind die passenden Harman Kardon Boxen (HKTS), welche sogar schon bestellt sind

Die Konfiguration unterscheidet sich ziemlich von der unter FreeBSD, so dass erst mal die Handbücher gewälzt werden mussten.

Als erstes sollte der NFS Service gestartet werden…

svcadm -v enable -r network/nfs/server

Danach ist die NFS Freigabe nötig, bei FreeBSD stehen die in /etc/exports, unter Solaris allerdings in /etc/dfs/dfstab. Eine Freigabe kann man allerdings auch auf der Konsole machen:

share -F nfs -o rw /export

Diese Methode überlebt allerdings keinen Reboot, so dass für eine permanente Freigabe die Zeile in der Datei /etc/dfs/dfstab eingetragen werden sollte.

Wenn auch der Benutzer root auf den NFS Clients verwendet werden soll, dann muss dies explizit freigegeben werden:

share -F nfs -o rw,root=host1:host2 /export

Die Option root=access_list legt fest von welchem Host der Benutzer root für die Freigabe Zugriff hat.

Um die Freigabe auf dem anderen System zu mounten, reicht der Befehl:

mount -F nfs server:/export /mount_point

Um das Volumen dauerhaft auf dem Client einzubinden, muss dies in der Datei /etc/vfstab definiert werden:

server:/export   -   /mount_point   nfs   -   yes    rw,soft

Also eigentlich gar nicht so schwer…man muss nur wissen, wo man alles nachlesen kann

Alle Sun Administration Handücher können übrigens unter http://docs.sun.com/app/docs/coll/47.16?l=de gefunden werden.

Im Bugtracker der MacPorts hat sich sehr lange wenig getan, das Problem wurde zwar scheinbar erkannt, es gab aber keine Lösung. Ohne einen Patch, lässt er sich immer noch nicht kompilieren. Damit er auch wirklich baut, muss das Portfile vom mplayer-devel Port mit folgendem Patch gepatcht werden.

Ist das geschehen, kann man endlich den Mplayer verwenden. Bin mal gespannt, wann es auch über den normalen Weg funktioniert.

Mein Hauptbenutzer im System, der eigentlich Admin Rechte hat, hat diese komplett verloren, obwohl er noch als Admin in der Benutzerverwaltung angezeigt wurde.

Dies hatte zur Folge, dass kein Installer mehr funktionierte, welcher nach dem Admin Passwort fragt. Ausserdem konnte ich alle Systemeinstellungen nicht freischalten, welche Admin Rechte benötigen.

Nach einigen Recherchen bin ich darauf gestossen, dass dieses Verhalten an dem Ordner ~/Library/Preferences/ByHost liegt. Dort werden einige Einstellungen von OS X gespeichert. Entfernt man den Ordner, dann wird dieser bei der nächsten Anmeldung wieder angelegt und die Admin Rechte sind wieder da. Allerdings muss man danach u. A. wieder die MobileMe Einstellungen vornehmen.

Die Konfiguration es relativ einfach, es muss nur eine Konfigurationsdatei angelegt werden und einige Bibliotheken bzw. Batch Dateien kopiert werden. Nach dem das ganze RCP Produkt exportiert wurde, müssen folgende Dateien aus der Wrapper Distribution kopiert werden.

• wrapper.dll und wrapper.jar, einfach in das Unterverzeichnis lib (muss neu angelegt werden) kopieren.

• wrapper.exe und die 2 Install- bzw. Uninstal Batch Skripte in den Hauptordner legen.

• wrapper.conf habe ich in den configuration Ordner gelegt.

Nachdem alle Dateien in dem entsprechendem Ort liegen, muss die Datei wrapper.conf angepasst werden:

wrapper.java.command=java
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
 
# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=lib/wrapper.jar
wrapper.java.classpath.2=plugins/org.eclipse.equinox.launcher_1.0.101.R34x_v20081125.jar
# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=lib
 
wrapper.java.additional.1=
wrapper.app.parameter.1=org.eclipse.equinox.launcher.Main
wrapper.console.format=PM
wrapper.console.loglevel=INFO
wrapper.logfile=wrapper.log
wrapper.logfile.format=LPTM
wrapper.logfile.loglevel=INFO
wrapper.logfile.maxsize=0
wrapper.logfile.maxfiles=0
wrapper.syslog.loglevel=NONE
 
wrapper.console.title=Meine Eclipse Anwendungen
 
wrapper.ntservice.name=EclipseAnwendung
wrapper.ntservice.displayname=EclipseAnwendung
wrapper.ntservice.description=Test Eclipse Anwendung
wrapper.ntservice.dependency.1=
wrapper.ntservice.starttype=AUTO_START
wrapper.ntservice.interactive=true

In der Konfiguration wird angegeben, dass die DLL und JAR Dateien in dem Unterordner lib befinden. Da es sich hierbei im eine Eclipse Anwendung handelt muss im Classpath org.eclipse.equinox.launcher eingetragen sein. Der wrapper.app.parameter.1 muss für Eclipse 3.4 auf org.eclipse.equinox.launcher.Main gesetzt werden. Sobald die Anwendung auf den Desktop zugreifen muss, um z.B. Fenster darzustellen, muss die Option wrapper.ntservice.interactive auf true gesetzt werden.

Der Wrapper erwartet eigentlich, dass die Konfiguration an einem anderen Ort liegt, als im Ordner coniguration, aber warum sollte man dafür einen neuen Ordner anlegen? Damit da wieder alles passt, müssen noch kurz die 2 Batch Skripte angepasst werden. In beiden Dateien wird der Pfad zur wrapper.conf gesetzt, dies muss wie folgt abgeändert werden:

set _WRAPPER_CONF="%_REALPATH%/configuration/wrapper.conf"

Sobald das alles erlegt ist, reicht ein Doppelklick auf das Install Batch Skript, und der Service wird eingetragen

TomTom ist ebenfalls kurz vor dem Release seiner Software. Es bleibt abzuwarten, welche Karten hier dabei sind, und was es kosten wird. Vorerst warte ich noch TomTom ab, auch wenn Navigon ein sehr guten Eindruck macht.

PostgreSQL bietet aber auch die Möglichkeit im Betrieb ein sogenanntes Write-Ahead-Log (WAL), neben den eigentlichen Datenbestand, auf die Festplatte zu schreiben. Es enthält alle Aufzeichnungen sämtlicher im Datenbanksystem vorgenommenen Schreiboperationen. Falls das System ausfällt, können diese Aufzeichnungen verwendet werden, um die Datenbank wieder herzustellen. Es handelt sich hierbei um das gleiche Prinzip wie ein “Journal” von Linux Dateisystemen.

Eigentlich wird das Write-Ahead-Log in regelmäßigen Abständen mit dem Datenbestand abgeglichen und wieder gelöscht, da es nicht mehr benötigt wird. Es kann aber auch für eine Datensicherung verwendet werden. Die Aufzeichnungen bestehen aus Segmenten, je 16MB groß und im Verzeichnis pg_xlog zu finden.

Um eine Datensicherung mit WAL zu betreiben, braucht man als erstes eine Basissicherung. Hierfür kann ein einfaches Shellscript verwendet werden:

#!/bin/sh
 
set -e
filename=/data/wal_archive/basebackup_`hostname`_$(date +'%Y-%m-%dT%H%M%S.%N%z').tar.gz
psql -U postgres -c "SELECT pg_start_backup('$filename');" > /dev/null
tar --force-local -C /data -c -z -f "$filename" --anchored --exclude=pg_xlog pgsql || [$? -eq 2]
psql -U postgres -c "SELECT pg_stop_backup();" > /dev/null

Mit den PostgreSQL Befehlen pg_start_backup() und pg_stop_backup() kann das komplette Datenbanksystem gesichert werden. Das erzeugte Tarball wird unter /data/wal_archive gespeichert. Die PostgreSQL Installation wird unter /data/pgsql erwartet.

Nachdem die Basissicherung erstellt wurde, kann PostgreSQL für WAL konfiguriert werden. PostgreSQL selber macht hier keine Vorschriften, wie die WAL Segmente archiviert werden sollen, es können beliebige Shell Befehle aufgerufen werden. Man hat z.B. die Möglichkeit die Segmente einfach mit cp zu kopieren, könnte sie aber auch mit rsync auf einen anderen Rechner schieben. Die Konfiguration wird in der Datei postgresql.conf vorgenommen:

archive_mode = on
archive_command = 'test ! -f /data/wal_archive/%f && cp %p /data/wal_archive/%f'

Es ist hier wichtig, dass keine vorhandenen Dateien überschrieben werden, deshalb wird vor dem kopieren getestet, ob die entsprechende Datei schon vorhanden ist. Der Platzhalter %f ist der Dateiname für die Zieldatei, %p ist die zu kopierende Datei mit vollständigem Pfad.

Nachdem PostgreSQL neu gestartet wurde, werden die WAL Dateien, sofern 16MB Daten geschrieben wurden nach /data/wal_archive kopiert. Es ist nicht möglich, kleinere Datei zu schreiben, deswegen besteht das Risiko max. 16MB an Daten zu verlieren, wenn der Server stirbt und die WAL Datei noch nicht geschrieben hat. Es gibt allerdings die Möglichkeit einen Timeout zu setzen, nach welchem auf jeden Fall das Segment geschrieben werden soll.

archive_timeout = 60

Hierdurch würden alle 60 Sekunden ein Segment geschrieben werden, auch wenn keine Schreiboperation durchgeführt würde! Das Segment ist dann trotzdem 16MB groß, und mit NULL Daten gefüllt. Es ist also abzuwägen ob und wie hoch der Timeout sein soll.

Grundsätzlich sichere ich die WAL Segmente großer Datenbank auf einen anderen Server, damit das Hauptsystem nicht durch das Backup bzw. den erhöhten Speicherbedarf belastet wird. Einerseits kann das Segment auf ein mit NFS eingehängtes Volumen gespeichert werden, oder es wird mit scp oder rsync kopiert. Der archive_command Aufruf für rsync könnte wie folgt ausehen:

archive_command = 'rsync --delay-updates --whole-file -ar -e ssh %p postgres@192.168.0.2:/data/wal_archive/%f </dev/null'

Die Segmente werden dann automatisch in das Verzeichnis /data/wal_archive auf dem Server 192.168.0.2 kopiert. Es sollte allerdings ein SSH-Key ohne Passwort auf dem Zielsystem für den Benutzer postgres hinterlegt sein.

Für die eigentliche Sicherung muss nur nach das Verzeichnis /data/wal_archive auf dem Server 192.168.0.2 eingetragen werden. Zugegeben, diese Art von Datensicherung verbraucht viel Speicherplatz, da die Festplattenpreise allerdings sehr niedrig sind und das Datenbanksystem kaum belastet wird, rechtfertigt sich der hohe Speicherbedarf durchaus.

Die Skytools sind von Skype, und können auf der PgFoundry Seite gefunden werden. Als Beispiel nehmen wir eine einfache Datenbank mit nur einer Tabelle…

CREATE sequence test_seq start WITH 1;
CREATE TABLE test (
  id int4 PRIMARY KEY, 
  txt text
);

Jetzt brauchen wir noch ein paar Datensätze…

INSERT INTO test VALUES ((SELECT NEXTVAL('test_seq')), 'bla');
INSERT INTO test VALUES ((SELECT NEXTVAL('test_seq')), 'blub');
INSERT INTO test VALUES ((SELECT NEXTVAL('test_seq')), 'test text');

Nachdem alle Tabelle angelegt ist, sollte die Datenbank auf dem Slave Server erstellt werden. Danach können die Inhalte mit einem Dump initial übernommen werden…

$ pg_dump -U postgres -s test | psql -h <IP-VON-SLAVE> -U postgres test

Damit londiste laufen kann, brauchen wir einen Ticker, dieser muss auf dem Master-Server laufen. Die Konfiguration kann wie folgt aussehen (hier die Datei /etc/ticker.ini):

[pgqadm]
job_name = ticker
db = dbname=test 
maint_delay_min = 1
loop_delay = 0.5
logfile = /tmp/log.%(job_name)s
pidfile = /tmp/pid.%(job_name)s
use_skylog = 0
connection_lifetime = 21
queue_refresh_period = 10

Danach kann der Ticker gestartet werden…

$ pgqadm.py -d /etc/ticker.ini ticker

Als nächstes brauchen wir noch für londiste ebenfalls eine Konfigurationsdatei (hier /etc/londiste.ini):

[londiste]
job_name = test_to_subcriber
provider_db = dbname=test port=5432 host=<IP-VON-MASTER>
subscriber_db = dbname=test port=5432 host=<IP-VON-SLAVE>
pgq_queue_name = londiste.replika
logfile = /tmp/%(job_name)s.log
pidfile = /tmp/%(job_name)s.pid

Die londiste Konfigurationsdatei muss auf beiden Server sein, damit die Replikation funktioniert. Auf dem Slave-System kann londiste nun installiert werden

$ londiste.py /etc/londiste.ini provider install
$ londiste.py /etc/londiste.ini subscriber install
$ londiste.py /etc/londiste.ini provider add test
$ londiste.py /etc/londiste.ini subscriber add test
$ londiste.py -d /etc/londiste.ini replay

Londiste läuft nun im Hintergrund als Daemon und sollte alle neuen Daten sofort auf den Slave replizieren.