Das kann doch eigentlich nicht so schwierig sein! Sollte man meinen, aber irgendwie war ich beim Googlen nach der richtigen Anleitung glücklos. Deshalb – quasi auch als Notiz an mich selbst – meine Einrichtung.

Anfang des Monats stand der Umzug meines Servers an - und wie so üblich startet man mit hohen Ansprüchen („diesmal mache ich alles besser“) :-) Insbesondere mehrere PHP-Altlasten waren mir ein Dorn im Auge; vorher hatte ich sträflich einfach PHP als Modul in Apache eingebunden, was zur Folge gehabt hätte, dass eine kompromittierte PHP-Seite sämtliche gehosteten Domänen gefährdet hätte. Für das neue Setup hatte ich zunächst mpm-peruser geplant gehabe, bin dann aber doch auf PHP mit fastcgi umgeschwenkt.

Vor einem Jahr hatte ich beschrieben, wie ich ein verschlüsseltes Backup auf einen Rechner im Netz mit Duplicity mache. Duplicity erledigt die eigentliche Backup-Aufgabe und die Verschlüsselung mit gpg. Anschließend werden diese Daten per sftp auf das entfernte System geschoben. Was man hierbei beachten kann, möchte ich hier quasi als Follow-Up-Artikel dokumentieren.

Für ein Projekt administriere ich einen Server, auf dem verschiedene Webanwendungen laufen. Sicherheitspolicy ist, daß ein Zugriff darauf nur über https und Client-Zertifikaten möglich sein darf - so weit, so einfach.

Dies ist die Geschichte einer Nachtschicht (ja, der Noob aus dem Titel bin ich). Übeltäter war ein recht frisch installierter Sabayon-Rechner, der plötzlich nicht mehr booten wollte. Der Rechner kam noch bis zu den vier Buchstaben GRUB, dann rührte sich nichts mehr. Nach einer Kernel Panic beim Versuch, den Rechner mit Hilfe eines von einer CD gestarteten GRUBs (grml ftw!) zu booten, war schon am Fluchen über vermeintlich defekte Hardware. Letztendlich war (m)ein Fsckup bei der Installation von GRUB2 auf der mit GPT organisierten Platten das Problem.

Zum Jahresanfang ein klein wenig Admin-Fu... gelegentlich kommt man in die Verlegenheit, auf einem entfernten Rechner Daten ablegen zu wollen, die vom jeweiligen Admin nicht lesbar sein sollen (beispielsweise weil man diesem nicht hinreichend vertraut). Anstoß für meine Überlegungen war die Notwendigkeit, ein Backup übers Netz zu machen, wobei die Daten auf dem entfernten Rechner nicht lesbar (sprich: verschlüsselt abgelegt) sein sollten.

Einrichten ssh

Als Basis für den sicheren Zugriff auf den entfernten Rechner habe ich ssh gewählt. Mit Authentisierung über Public-Private-Keypaare läßt sich der Zugriff auch schön automatisieren - entweder indem man den Private Key auf dem zu sichernden System unverschlüsselt hinterlegt oder durch Speichern des zugehörigen Passphrases in einer Keyagent-Instanz, die dann natürlich nach einem Systemstart manuell neu einzugeben ist.

Folgende (sicher nicht untypische) Aufgabenstellung purzelte bei mir die Tage über den Schreibtisch: Auf dem Team-Webserver soll webdav eingerichtet werden, um mit Projektpartnern Dateien austauschen zu können. Die Teammitglieder (welche alle auch einen Shellaccount haben) sollen vollständigen Zugriff haben und sich auch mit ihrem normalen Username und Passwort anmelden können. Die Projektpartner sollen nur auf einzelne Verzeichnisse zugreifen können; natürlich haben sie auch keinen Unix-Account.

Ich habe mir erfolgreich meinen Laptop verkonfiguriert. Anfangs war da nur eine Windows-Installation (*cough*) 'drauf, dann kam ein provisorisches Linux hinzu. Inzwischen arbeite ich fast ausschließlich unter Linux, deshalb habe ich die Windows-Partition deutlich verkleinert. Zwei Probleme gab es zu lösen: Der freie Platz mußte LVM zugeschlagen werden, und die darin befindlichen (mit LUKS verschlüsselten) Partitionen mußten vergrößert werden.