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.

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.

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.

Genau das war vor kurzem bei mir der Fall, wo ich einen DNS Server in meiner FreeNAS Installation brauchte. Ich hab auch schon an TinyDNS von D.J. Bernstein gedacht, allerdings braucht dieser /usr/sbin/daemon, was bei mir nicht verfügbar ist.

Also viel meine Wahl auf MaraDNS. Hierbei handelt es sich um einen extrem kleinen DNS Server, welcher seine Zonen aus CSV Dateien holt. Ziemlich einfach zu installieren bzw. konfigurieren.

Unter FreeBSD reicht ein pkg_add -r maradns und die Software ist installiert. Die Konfiguration in der Datei mararc ist auch recht simpel…

csv2 = {}
csv2["example.com."] = "db.example.com"
csv2["0.168.192.in-addr.arpa."] = "db.192.168.0"
 
ipv4_bind_addresses = "0.0.0.0"
chroot_dir = "/usr/local/etc/maradns"
maradns_uid = 53
maradns_gid = 53
maxprocs = 96
no_fingerprint = 0
default_rrany_set = 3
max_chain = 8
max_ar_chain = 1
max_total = 20
verbose_level = 1
 
ipv4_alias = {}
ipv4_alias["icann"]  = "198.41.0.4, 192.228.79.201, 192.33.4.12, 128.8.10.90,"
ipv4_alias["icann"] += "192.203.230.10, 192.5.5.241, 192.112.36.4,"
ipv4_alias["icann"] += "128.63.2.53, 192.36.148.17, 192.58.128.30,"
ipv4_alias["icann"] += "193.0.14.129, 198.32.64.12, 202.12.27.33"
ipv4_alias["opennic"]  = "157.238.46.24, 209.104.33.250, 209.104.63.249,"
ipv4_alias["opennic"] += "130.94.168.216, 209.21.75.53, 64.114.34.119,"
ipv4_alias["opennic"] += "207.6.128.246, 167.216.255.199, 62.208.181.95,"
ipv4_alias["opennic"] += "216.87.153.98, 216.178.136.116"
 
ipv4_alias["localhost"] = "127.0.0.0/8"
recursive_acl = "localhost,192.168.0.0/8"

In der Konfiguration werden 2 Zonen eingerichtet, eine für example.com und eine Reverse Zone für 192.168.0. Ausserdem wird mit recursive_acl das Netz 192.168.0.0/8 für Abfragen freigeschalten.

Die Zonen an sich sind auch extrem einfach aufgebaut. Die Zone für example.com in der Datei db.exmaple.com

server1.example.com. A 192.168.0.1
server1.exmaple.com. MX 10 server1.example.com.
server2.example.com. CNAME server1.example.com.
 
client1 A 192.168.0.10
client2 A 192.168.0.11

Die Datei db.192.168.0 für die Rückwärtsauflösung sieht dann z.B. wie folgt aus…

1.0.168.192 PTR server1.example.com.
10.0.168.192 PTR client1.example.com.
11.0.168.192 PTR client2.example.com.

Auch der Umstieg von Bind wird leicht gemacht. Mit dem Tool getzone, welches mitgeliefert wird, können direkt die Zonen von einem anderen Server geholt, und in das MaraDNS Format ausgegeben werden. Das erspart lästige Tipparbeit

getzone example.com 192.168.0.100

Hier hole ich die Zone example.com von dem Nameserver mit der IP 192.168.0.100.

Es handelt sich hierbei um ein Shell Script, welches seit FreeBSD 6.4 mitgeliefert wird. Mit diesem Script kann das ganze System (ausgenommen Ports natürlich) einfach geupdatet werden.

FreeBSD wird dabei nicht aus den Quellen neu gebaut, es werden Binaries verwendet, und hier wird auch nur die x86 Architektur bedient. Weitere Vorraussetzung ist, dass das System ein Release ist, also z.B. 7.1-RELEASE. Systeme, welche vorher mit make world geupdatet wurden kann freebsd-update nicht analysieren.

Um z.B. aktuelle Sicherheitsupdates zu installieren reicht:

freebsd-update fetch
freebsd-update install

Darauf hin untersucht freebsd-update das System und sucht für dieses Release neue Updates. Diese werden dann installiert, sofern nötig muss der Rechner rebootet werden.

Soll das ganze System auf ein neues Release geupdatet werden, dann muss dieses explizit angegeben werden.

freebsd-update -r 7.1-RELEASE upgrade
freebsd-update install

Bei Release Updates muss der Rechner rebootet werden, da ein neuer GENERIC Kernel installiert wird. Sobald man allerdings einen selbst gebautet Kernel verwendet, wird das ganze etwas komplizierter. Dieser muss dann natürlich nochmal gegen die neuen Sourcen gebaut werden. freebsd-update weisst aber darauf hin. Nach einem Update auf ein neues Release muss man noch alle Ports gegen das neue Basissystem bauen.

portupgrade -af

Hier hat es wieder der Admin einfach, welcher nur Packages verwendet

Allgemein ist freebsd-update ein wunderbares Tool, um ein System relativ einfach aktuell zu halten. Vor kurzem hat es mir dabei geholfen, ein FreeBSd 6.2 auf 7.1 zu aktualisieren. Dabei kam es zu keinem Problem. Übrigens, mergemaster fällt mit freebsd-update auch weg

Genau hier hilft DenyHosts. Es handelt sich hierbei um einen kleinen Daemon, welcher permanent die Datei /var/auth.log liest und bei mehrmaligen fehlgeschlagenen Login Versuchen die IP per /etc/hosts.allow blockt. Das Prinzip ist nicht neu, es gibt z.B. auch andere Tools, welche die gleiche Funktionalität z.B. per iptables lösen.

Das ist aber noch nicht alles, man kann den Daemon auch so einstellen, dass der die gefundenen IPs der globalen Datenbank von DenyHosts meldet. Im Gegenzug kann auch die Datenbank verwendet werden um die Hosts Datei zu füttern. Seit dem ich das Tool auf meinen Servern installiert habe, haben die Angriffe fast aufgehört bzw. es wurden fast alle sofort geblockt.

Die Konfiguration ist denkbar einfach. Nachdem die Software installiert ist, muss als erstes die Datei denyhosts.conf angepasst werden. Die Konfigurationsdatei ist ziemlich selbsterklärend. Danach kann auch schon der Daemon gestartet werden. Dank der Ports Collection von FreeBSD war das Startscript bereits vorhanden. Der Daemon schreibt seine Einträge dann üblicherweise in die Datei /etc/hosts.deniedssh, welche nur noch in die Datei /etc/hosts.allow eingebunden werden muss mit…

sshd : /etc/hosts.deniedssh : deny  
sshd : ALL : allow

Danach ist das komplette System fertig konfiguriert und das System blockt automatisch SSH Anfragen von IPs, welche in der Datenbank von DenyHosts gelistet sind.

In meinem Setup wollte ich nur einen LDAP Server, welcher alle Schreibzugriffe bearbeitet und somit der eigentliche Master-Server ist. Alle anderen LDAP Server sind nur noch für Lesezugriffe da.

Für den Master müssen nur folgende Zeilen in die slapd.conf eintragen werden:

replica host=HOSTNAME-REPLICA-SERVER:389
        suffix="LDAP-SUFFIX"
        binddn="DN-MANAGER"
        credentials=PASSWORT
        bindmethod=simple

Für jeden Slave Server muss eine replica host Direktive vorhanden sein.

Die Slave Server lassen sich sogar noch einfach konfigurieren…

updatedn        "DN-MANAGER"
updateref     ldap://HOSTNAME-MASTER:389

Durch updateref leitet der Slave alle Update- bzw. Schreib-Request zum Master weiter.

So simpel kann eine Replikation eingerichtet werden

Da ProFTP selber über eine Modul Schnittstelle verfügt ist es kein Problem diese Funktionalität einzubauen. Unter http://www.castaglia.org/proftpd/modules/modsqlsqlite.html gibt es genau für diesen Fall ein passendes Modul

Sobald das Modul mit einkompiliert ist, kann das Backend in der proftpd.conf wie folgt angesprochen werden:

<IfModule mod_sql_sqlite.c>
  SQLConnectInfo /pfad/zu/ftpd.db
</IfModule>

Mehr ist für die Verbindung zur Datenbank nicht nötig. Da ProFTP selber schon eine Schnittstelle für SQL hat, kann die Abfrage der Benutzer mit modsql gemacht werden. Eine Anleitung hierfür ist unter http://www.castaglia.org/proftpd/modules/modsql.html zu finden.