Meine Wahl fiel hier auf Archlinux. Auch in der Auswahl stand Gentoo aber ich persönlich sehe es nicht ein, dass ich jedes Paket selber kompilieren soll, wenn es doch ein Buildserver für mich tun kann. Das Arch nicht nur ein kleiner Ausflug wird war schon zu Beginn klar, schließlich muss man bei Arch alles per Hand konfigurieren. Wie erwartet gab es für mich als Archneuling einige Probleme:

Partitionierung:
Da Arch das Programm cfdisk nutzt, mit dem ich persönlich nicht gut klar komme, brauchte es bei mir 3 Versuche bis ich Arch die richtige Partition zugewiesen habe und es davon booten konnte.

Einrichten der Grafik:
Ein wesendlich größeres Problem war für mich die Einrichtung der Grafischen Oberfläche. Egal ob ich den freien oder den proprietären Nvidia-Treiber probierte, beide konnten den X-Server nicht starten. Erst das starten von kdm brachte mir überhaupt einmal die Grafik auf den Bildschirm.

KDE 4 Login Manager:
Obwohl ich sonst eigentlich ein Anhänger von Gnome bin, dachte ich mir dass ich nicht zwei Linuxsysteme mit Gnome brauche und mal was anderes nehmen sollte. Die Installation war relativ Problemlos aber als ich den Loginmanager mit dem Befehl kdm startete, konnte ich weder die Maus bewegen noch reagierte meine Tastatur. Glücklicherweise habe ich vorher SSH eingericht, sonst hätte ich den Resetknopf bzw. den magic SysRq key betätigen müssen.

Nach Sichtung der Logs war klar das kdm die in der xorg.conf referenzierten Treiber für die Eingabegeräte nicht finden konnte. Also einfach via pacman die Pakete xf86-input-keyboard und xf86-input-mouse installliert und bei dem nächsten Start von kdm konnte man schreiben und die Maus bewegen.

Fazit:
Arch Linux ist ein klasse System aber man sollte bereits gute Linuxkenntnisse haben, bevor man sich an die Installation macht. Bei der Installation von Arch habe ich viel über Linux gelernt und sehr viel Spaß gehabt. Auch wenn Ubuntu mit Gnome mein Hauptsystem bleiben wird, kann ich jedem nur empfehlen, sich Arch einmal anzuschauen.

Die Lösung war beeindruckend einfach, ich musste einfach folgende Zeile in die /etc/fstab eintragen:
none /proc/bus/usb usbfs devgid=XXX,devmode=664 0 0

Wobei XXX mit der ID der Gruppe vboxusers zu ersetzen ist.
Die ID lässt sich folgendermaßen rausfinden:

Zuerst öffnet man die Benutzerverwaltung:
Menü -> System -> Systemverwaltung -> Benutzer und Gruppen

Danach auf entsperren clicken und unter "Gruppen Verwalten" die Eigenschaften der Gruppe "vboxusers" betrachten. Beim nächsten Systemstart sollten in Virtualbox alle angeschlossenen USB-Geräte verfügbar sein.

Dabei handelt es sich um eine Bibliothek, die es QT-Programmen erlaubt das GTK-Thema des Benutzers zu verwenden. Somit ist endlich eine fast natlose Integration in Gnome möglich.

Für die ganz faulen habe ich die Bibliothek für Ubuntu 8.10 compiliert.

Vorher:

Nachher:

Downloads:
32 Bit Ubuntu 8.10
64 Bit Ubuntu 8.10
Skript zum Selbstcompilieren

thx an Linuxtechie

1. Installation:
Als erstes Öffnet man Synaptic und sucht nach Bacula, ich habe Bacula mit folgenden Paketen installiert:
bacula, bacula-client, bacula-common, bacula-console, bacula-director-common, bacula-director-sqlite3, bacula-fd, bacula-sd, bacula-sd-sqlite3, bacula-server
Wichtig ist Bacula mit den sqlite Komponenten auszuwählen wenn man sich nicht mit MySQL rumschlagen will. Sqlite ist eine abgespeckte Datenbank, völlig ausreichend für Bacula.

2.Konfiguration:
Der Storage Daemon Schreibt die Backupdaten auf die Festplatte/Bandrobotter etc.

Die Konfigurationsdateien von Bacula liegen unter
/etc/bacula
Unter diesem Verzeichnis liegen folgende Dateien:
$ ls -l
insgesamt 32
-rw-r----- 1 root bacula 8678 2008-10-04 00:22 bacula-dir.conf
-rw-r----- 1 root root 1024 2008-10-04 00:22 bacula-fd.conf
-rw-r----- 1 bacula bacula 6505 2008-10-04 00:22 bacula-sd.conf
-rw-r----- 1 root bacula 178 2008-10-04 00:22 bconsole.conf
drwxr-xr-x 2 root root 4096 2008-10-04 00:22 scripts

- bacula-dir.conf Konfig für den Chef, der alles überwacht.
- bacula-fd.conf Konfig für den Daemon, der von den Clients Dateien zieht.
- bacula-sd.conf Konfig für den Daemon, der die Daten auf die Festplatte schreibt.
- bconsole.conf Konfig für die Bacula-Konsole über die man Bacula steuert.
- Der Ordner scripts ist für die Grundkonfiguration nicht von Bedeutung.

2.1 Konfiguration des Storage Daemons:
Das einzige was hier angepasst werden muss ist Archive Device.
Device {
Name = FileStorage
Media Type = File
Archive Device = /media/Backup
LabelMedia = yes; # lets Bacula label unlabeled media
Random Access = Yes;
AutomaticMount = yes; # when device opened, read it
RemovableMedia = no;
AlwaysOpen = no;
}


2.2 Konfiguration des File-Daemons:
Auf jedem Client muss ein solcher Filedaemon angelegt werden:
FileDaemon { # this is me
Name = mw88-desktop-fd
FDport = 9102 # where we listen for the director
WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run/bacula
Maximum Concurrent Jobs = 20
FDAddress = 127.0.0.1
}

Wichtig ist dass Name, Port und FDAddress in der bacula-fd.conf auf dem Client und in der bacula-dir.conf auf dem Server gleich sind.

2.3 Konfiguration des Bacula-Directors
Der Bacula-Director ist das Herzstück von Bacula, er koordiniert alle Daemons und steuert die Backups.

Für jeden Client muss eine Jobdefinition angelegt werden, über die man später das Backup starten kann.
JobDefs {
Name = "Backupserver sichern"
Type = Backup
Level = Incremental
Client = mw88-desktop-fd
FileSet = "Full Set"
Schedule = "WeeklyCycle"
Storage = File
Messages = Standard
Pool = Default
Priority = 10
}
Name und Client müssen entsprechend angepasst werden, wenn keine automatischen Backups gewollt sind, muss Schedule rausgelöscht bzw mit einem vorangestellten # auskommentiert werden.

Damit man auch zurückspielen kann, muss noch ein Restorejob angelegt werden. Es reicht wenn nur ein solcher Job definiert ist, da man in der bconsole vor außführen des Jobs den Client austauschen kann.Job {
Name = "Restore Files"
Type = Restore
Client=mw88-desktop-fd
FileSet="Full Set"
Storage = File
Pool = Default
Messages = Standard
Where = /media/Backup/Wiederhergestellt
}
Where gibt an wohin die Daten wiederhergestellt werden sollen.

Sollen die Clients jede Nacht gesichert werden, muss jeweils ein Job angelegt werden.
Job {
Name = "Client1"
JobDefs = "DefaultJob"
Write Bootstrap = "/var/lib/bacula/Client1.bsr"
}
Name und Bootstrap müssen hier angepasst werden.

Für jeden Client muss ein FileSet definiert werden, das angibt was gesichert werden soll und welche Verzeichnisse/Dateien nicht mit einbezogen werden sollen.FileSet {
Name = "Full Set"
Include {
Options {
signature = MD5
}
File = /etc
File = /home/mw88
}
Exclude {
File = /home/mw88/.gvfs
File = /home/mw88/.wine/drive_c/windows/temp
}
}

Hier muss für jeden Client ein Gegenstück zu dem Filedaemon, der auf dem Client läuft, definiert werden.
Client {
Name = mw88-desktop-fd
Address = mw88-desktop
FDPort = 9102
Catalog = MyCatalog
Password = "Passwort" # password for FileDaemon
File Retention = 30 days # 30 days
Job Retention = 6 months # six months
AutoPrune = yes # Prune expired Jobs/Files
}
Wenn der Storage-Daemon auf dem gleichen Rechner laufen soll wie der Director, muss unter dem Punkt Storage nichts verändert werden. Alternativ lassen sich hier auch Bandrobotter oder DVD-Brenner als Sicherungsmedium eintragen.

Will man keine Automatischen Backups muss man die Schedule Punkte mit # auskommentieren, ansonsten müssen hier Datum und Uhrzeit angepasst werden.

2.4 Konfiguration der Bconsole
Die Bconsole ist das Interface, über dass Bacula gesteuert wird. Sie kann direkt auf dem Backupserver und auf einem entfernten Rechner ausgeführt werden. Dazu muss auf dem jeweiligen Rechner die Bconsole installiert sein und die bconsole.conf entsprechend angepasst werden.

Abschließend müssen die Dienste noch neugestartet werden./etc/init.d/bacula-director restart
/etc/init.d/bacula-fd restart
/etc/init.d/bacula-sd restart
Sollten sich in der Konfigurationsdatei Fehler eingeschlichen haben, werden die Skripte darauf hinweisen.

Damit ist die Konfiguration abgeschlossen, auf die Bediehnung geh ich im nächsten Post ein.

Ich bin vor kurzem auf eine Möglichkeit gestoßen Spiele auf einen eigenen X-Server auszulagern.

Dazu braucht man erstmal das Skript dass es hier auf der ersten Seite gibt.
Das kopiert man in eine Textdatei und speichert sie als xgame.sh ab. Danach wechselt man im Terminal in das Verzeichnis, in dem man das Skript gespeichert hat und macht es mit chmod +x xgame.sh ausführbar. Anschließend kann man das Skript mit
sudo ./xgame.sh ausführen.

Während der Installation wird man nach einem Hintergrundbild gefragt, welches dann den X-Server zieren wird. Nach der installation kann man einfach mit
x.game start /usr/local/games/quake4/quake4 Quake4 auf dem zweiten X-Server starten ohne dabei ein Programm auf dem ersten beenden zu müssen.

Auch wenn ein Spiel abstürzt passiert dem Desktop nichts, der zweite X-Server kann ohne bedenken per Tastenkombination neugestartet werden.

Mit strg + alt + F7 kommt man auf den Desktop zurück, zu dem zweiten X-Server kommt man wieder mit strg + alt + F12.