planetknauer.net

Debian 12 ist vor kurzem veröffentlich worden, Zeit für Updates. Wie üblich ging das weitestgehend problemlos über die Bühne, nur ein paar Dinge brauchten etwas händisches Nachtreten:

Firmware Pakete

Die unfreien Firmware-Pakete wurden von non-free nach non-free-firmware ausgelagert. Entsprechend muss die /etc/apt/sources.list ergänzt werden, sonst werden die Firmware-Pakete nicht aktualisiert.

vim

Alle paar Releases wieder gibt es eine kaputte Version von vim, die man wieder zurechtkonfigurieren muss, damit z.B. einfügen per Mittelklick auch in meiner Umgebung (d.h. viel SSH und xterm) noch geht. Hier die aktuelle Config:

let g:skip_defaults_vim = 1
filetype plugin indent on
set tabstop=4
set shiftwidth=4
set paste
set noai
set vb
syntax enable

Die erste Zeile setzt erst mal alles auf Standardeinstellungen zurück, damit man anfangen kann zu arbeiten...

Zoneminder

Die Maschine wurde von Debian 10 und Zoneminder ab externem Repo erst zu Debian 11 mit Zoneminder ab backports aktualisiert und dann auf Debian 12 (ohne Extras) angehoben. Wichtig war nur nach jedem Update einmal zmupdate.pl -f auszuführen.

Nextcloud

Das Nextcloud-Update war etwas fummelig. Debian 11 kommt mit PHP 7.4, welches ab Nextcloud 26 nicht mehr unterstützt wird. Debian 12 kommt mit PHP 8.2, welches von Nextcloud 25 noch nicht unterstützt wird. Also war hier folgendes vorgehen angesagt:
- Nextcloud auf das letzte 25er Release aktualisieren
- Debian aktualisieren
- Auf Nextcloud 26 (wichtig, nicht latest, denn das ist bereits 27 oder noch neuer) von Hand aktualisieren
- Nextcloud über den eingebauten Updater auf die neuste Version bringen.

Neulich hat Debian (endlich...) ein Upgrade von Firefox ESR 52 auf Firefox ESR 60 durchgeführt. Das hat wie so viele Updates gute und schlechte Seiten. Positiv ist, dass ein aktueller und flotter Browser installiert wird. Negativ ist, dass nun fast alle meine Addons nicht mehr verfügbar sind.

Während das Update auf dem Laptop problemlos funktionierte, hat es mir auf dem Desktop das Browserprofil so zerschossen, dass sich Firefox partout nicht mehr dazu bewegen liess, eine Website aufzurufen (nicht mal von 127.0.0.1). Eine gute Gelegenheit, frisch anzufangen und die Einstellungen nochmals zu prüfen - und die Modifikationen hier zu notieren, damit ich sie beim nächsten Mal wieder finde und jemand dies für irgendjemanden von Nutzen ist.

Firefox modifiziere ich aus drei Gründen: Für bessere Benutzbarkeit, Performance und Sicherheit/Privatsphäre. Hierzu installiere ich ein paar (hoffentlich vertrauenswürdige) Plugins und passe einige Einstellungen in der about:config an.

Als Addons unverzichtbar sind NoScript und uBlock Origin (eigentlich wäre mir Request Policy lieber, aber das wurde ja von Firefox durch das Update getötet). Mir geht es weniger darum, lästige Werbung auszublenden. Ich habe nichts gegen Werbung, wenn sie direkt vom Website-Betreiber gehostet wird (kein Tracking) und nicht aufdringlich ist (ergo: statische Bilder). Aber Werbenetzwerke wurden auch schon von Bösewichten dazu missbraucht, Schadsoftware auf an sich vertrauenswürdigen Webseiten zu verbreiten (siehe z.B. hier... Link geht bewusst zum Verursacher). Es ist somit reine Selbstverteidigung.
Nach wie vor auf der Suche bin ich nach einem Addon zur Verwaltung von Cookies, da auch Cookie Controller nicht mehr funktioniert.

Die Benutzbarkeit optimiere ich durch folgende Einträge in der about:config:

accessibility.typeaheadfind.flashBar;0
browser.bookmarks.showMobileBookmarks;true
browser.feeds.handlers.application;/usr/bin/akregator
browser.tabs.closeWindowWithLastTab;false
browser.tabs.loadBookmarksInTabs;true
browser.urlbar.formatting.enabled;false
browser.urlbar.suggest.openpage;false
browser.urlbar.trimURLs;false
dom.disable_window_open_feature.toolbar;true
network.proxy.autoconfig_url;http://xxx/wpad.dat # nur auf Desktop
network.proxy.type;2 # nur auf Desktop
pdfjs.disabled;true

Für die Performance wird der Disk-Cache in eine RAM-Disk verschoben, das schont auch die SSD. Da mein /tmp eh schon in einer RAM-Disk liegt, bietet sich das an. Das ist zwar eine leichte Schwächung der Systemsicherheit, da /tmp per se allen Nutzern einsehbar ist. Da ich aber keinen shared Unix-Mainframe sondern eine Workstation nur für mich selbst habe, bleibt die Auswirkung in überschaubahrem Rahmen:

browser.cache.disk.parent_directory;/tmp

Als winziger Bonus wird auch die Privatsphäre minimal gesteigert, da der Disk-Cache somit nach einem Neustart des Computers definitiv gelöscht ist. Somit lassen sich Cache-Timing-Trackings reduzieren - eine eh schon eher esoterische Schnüffelmethode. Alternativ kann der Disk-Cache natürlich auch ganz deaktiviert werden.

Zu guter letzt wird noch die Privatsphäre gegenüber Mozilla und Google gesteigert. Dazu werden jede Menge unnötige Cloud-Dienste von Mozilla deaktiviert. Ebenfalls wird Google Safebrowsing ausgeschaltet. Dies weniger wegen Privatsphärebedenken, denn unter Berücksichtigung der Funktionsweise dieser Datenbank ist diese trotz Google-Herkunft tatsächlich relativ wenig bedenklich. Aber ich stelle den Nutzen in Frage. Ein aktuell gehaltenes Linux und ein Bisschen Vorsicht beim wild herumklicken bringt mehr Sicherheit als (potentiell veraltete und unvollständige) URL-Listen. Ausserdem spart dies Bandbreite und Festplattenplatz, da die Safebrowsing-Datenbank doch mehrere Gigabyte gross ist.

beacon.enabled;false
browser.pagethumbnails.capturing_disabled;true # neu zu erstellen
browser.safebrowsing.blockedURIs.enabled;false
browser.safebrowsing.downloads.enabled;false
browser.safebrowsing.downloads.remote.block_dangerous;false
browser.safebrowsing.downloads.remote.block_dangerous_host;false
browser.safebrowsing.downloads.remote.block_potentially_unwanted;false
browser.safebrowsing.downloads.remote.block_uncommon;false
browser.safebrowsing.downloads.remote.enabled;false
browser.safebrowsing.malware.enabled;false
browser.safebrowsing.phishing.enabled;false
browser.search.suggest.enabled;false
captivedetect.canonicalURL;http://xxx/success.txt # nur auf Laptop
datareporting.healthreport.service.enabled;false
extensions.blocklist.enabled;false
extensions.getAddons.cache.enabled;false
extensions.screenshots.disabled;true
extensions.screenshots.upload-disabled;true
geo.enabled;false
network.captive-portal-service.enabled;false # nur auf Desktop
startup.homepage_welcome_url;
toolkit.telemetry.unified;false
toolkit.telemetry.coverage.opt-out;true # neu zu erstellen

Eine gute Beschreibung vieler dieser Punkte sowie einige weitere Einstellmöglichkeiten finden sich in dieser grossartigen Anleitung.

Als weiteren Punkt in der Privatsphäre passe ich meine Cookie-Speicherdauer an und aktiviere den Do-Not-Track-Header:

network.cookie.lifetimePolicy;2
network.cookie.cookieBehavior;1
privacy.donottrackheader.enabled;true

Diese drei Anpassungen sind auch komfortabel per Maus über die Einstellungen erreichbar. Cookies werden akzeptiert, jedoch nicht von von dritten. Beim Schliessen des Browsers werden alle Cookies gelöscht. Dies ist ein guter Kompromiss zwischen Verfolgbarkeit einschränken und Webseiten benutzbar erhalten, ohne übermässig lange Ausnahmelisten führen zu müssen.

Zur Verbesserung der Sicherheit wird der Zugriff auf die Zwischenablage gestutzt:

dom.event.clipboardevents.enabled;false
dom.allow_cut_copy;false

Seit ich beim einzig brauchbaren Provider der Schweiz bin (das ist der, der es gelegentlich auch in die deutschen News schafft, da er als vermutlich einziger Provider der Welt offen und explizit für Netzneutralität eintritt), habe ich endlich auch Internetzugang mit dem Protokoll der Zukunft, IPv6. Der Provider ist sogar so freundlich, dass ich auf Anfrage kostenlos ein statisches IPv6-Prefix erhalten kann, d.h. meine Computer immer unter der gleichen Adresse erreichbar sind.

Leider hat das auf der technischen Seite einen kleinen Schönheitsfehler, denn das statische Prefix wird anhand der DUID zugewiesen. Diese muss auf Seiten des Providers eingetragen werden. Die DUID ist eine pseudozufällig generierte, einzigartige ID meines IPv6-Clienten, also meiner Firewall. Diese Firewall benutzt als Softwarebasis das freie Firewallprojekt pfSense. Diese hat in der neusten Version allerdings ein sehr nerviges "Feature": Bei jedem Neustart wird die DUID neu generiert. Dies führt dazu, dass ich nach Softwareupdates, Stromausfällen o.ä. jeweils immer dem Support des Providers schreiben muss, er solle bitte die neue DUID eintragen. Somit ist mein IPv6-Zugang für eine Weile gestört, bis der Provider meiner Bitte nachgekommen ist.

Das zu unterbinden, erfordert leider etwas Gebastel...:
Zuerst muss man sich per SSH auf der Firewall einloggen und eine Shell aufrufen (Taste 8 drücken). Dann muss die Datei, welche die DUID enthält, an einen Ort kopiert werden, wo sie einen Neustart der Firewall übersteht:

cd /conf
mkdir dhcp
cp /var/db/dhcp6c_duid .

Danach wird über das Webfrontend ein Job eingerichtet, der diese Datei bei jedem Neustart bevor das Netzwerk gestartet wird wieder nach /var/db kopiert. Dazu muss als erstes über die Paketverwaltung (System -> Package Manager -> Available Packages) das Paket "Shellcmd" installiert werden.
Danach kann unter Services -> Shellcmd ein neuer Befehl definiert werden:

Command: cp -f /conf/dhcp/dhcp6c_duid /var/db/
Shellcmd Type: earlyshellcmd
Comment: Fix braindead IPv6 DUID regeneration

Fazit: die proprietären Sonicwall und Fortinet mögen unbrauchbar sein, aber auch die freie pfSense ist nicht frei von Macken. Eine perfekte Firewall-Lösung existiert auf diesem Planeten schlicht nicht.

Im Original findet sich die Lösung hier.

Meine Verachtung für proprietäre Netzwerk"sicherheits"produkte ist über die letzten Tage wieder deutlich gestiegen. Objekt meines diesmaligen Hasses ist der Müll von Sonicwall, der sich somit von mir aus gleich auf neben Fortinet auf der Elektroschrotthalde einfinden darf.

Und zwar ging es darum, zwei bisher als Single Point of Failure betriebene Dienste mittels bestehender Loadbalancer-Infrastruktur auf Basis von Keepalived zu ausfallsicheren Clustern zu verbinden. Soweit so einfach, die redundanten Server installiert (bzw den Hot Standby auf Funktionstüchtigkeit überprüft), dem Loadbalancer zwei neue Virtual IPs hinzugefügt und die jeweiligen Maschinen zu Clustern verbunden.

Ein kurzer interner Funktionstest zeigt: Tut perfekt.

Als nächstes werden die geclusterten Dienste öffentlich freigegeben, dafür muss erstmal ein weiteres Loch in die Firewall gestanzt werden. Keine Sache für den ersten Cluster (erste virtuelle IP) und eigentlich auch nicht für den zweiten Cluster (zweite virtuelle IP). Als nächstes erfolgte natürlich der Funktionstest von extern, was beim ersten Cluster schlagartig mit Erfolg beschieden war.

Nicht so aber beim zweiten Cluster. Da war einfach keine Verbindung zu erstellen. Nun, woran könnte das liegen? Die Firewall-Regeln sahen alle gut aus, hmmm, kann das am Cluster liegen? Das ist ja doch eine komplexe Konfiguration mit Anpassungen auf Seiten des Loadbalancers und den geclusterten Maschinen. Also nochmals rigoros alles überprüft. Schaut gut aus. Und intern funktioniert's ja. Also doch die Firewall? Nochmals die Regeln überprüft... Mir sagen lassen, dass ich halt die Firewallregel irgendwie(tm) falsch erstellt hätte und sie nochmals prüfen solle. Gut. Nochmals unnötig Zeit auf die Überprüfung der Firewallregeln verschwendet. Die sehen einfach(tm) identisch zum anderen neuen Dienst aus. Die Regeln und das Netzwerk-Objekt gelöscht. Die Regeln und das Netzwerk-Objekt neu erstellt. Mir erneut sagen lassen, dass wohl die Regeln irgendwie(tm) falsch erstellt seien, da Sonicwall sowas ja noch nie gemacht hätte. Weiter am Loadbalancer debuggt und mit tcpdump und telnet herumgespielt. Erwartetes Ergebnis: Der Verbindungsaufbau von extern erreicht nicht einmal den Loadbalancer. Also zurück zur Firewall...

Und dann habe ich folgenden Versuch unternommen: Die Cluster-IP wurde von xxx.xxx.xxx.xxx zu xxx.xxx.xxx.xxy geändert. Danach wurde in der Firewall das Netzwerk-Objekt ebenfalls auf diese IP angepasst (also die eigentliche Regel habe ich nicht angefasst). Und zuletzt nochmals einen Test von aussen gefahren: BOOM! Katsching! Zugriff!

Als nächstes habe ich folglich *sämtliche* Firewallregeln darauf überprüft, ob sie Einfluss auf die zuerst genutzte IP haben könnten. Ich bin nicht fündig geworden.

Mit anderen Worten: Die bescheuerte Sonicwall diskriminiert ohne wirklichen Anlass eine gewisse IP-Adresse. Aber hey, was ist von einem Produkt zu erwarten, dessen Name mit NSA beginnt? Vermutlich sah die IP-Adresse einfach zu arabisch aus. Die ist ja schliesslich komplett in arabischen Ziffern notiert....

Jedenfalls verdient Sonicwall für solche Bugs in ihren überteuerten Produkten von mir einen Mittelfinger und ein "Fuck You", das Linus Torvalds Mittelfinger gegen nVidia wie einen Kindergeburtstag aussehen lässt. Es kann nicht angehen, dass meine teure Lebens- und Arbeitszeit verschwendet wird und versucht wird mein Selbstvertrauen kaputtzumachen.

Heute habe ich auf dem Server neue SSL-Zertifikate von Let's Encrypt installiert. Bislang habe ich selbstsignierte Zertifikate genutzt, um sichere Übertragung zu ermöglichen ohne dafür unverschämte Mengen Geld an dubiose Certificate Authorities zum Fenster hinauswerfen zu müssen. Let's Encrypt bietet kostenlose Zertifikate an und wird von den wichtigsten Browserherstellern unterstützt. Somit sollte nichts mehr dagegen sprechen, mein Blog über https aufzurufen.

Vorteil: Die NSA kann nicht mehr wissen, was genau gelesen wird

Als neues Spielzeug habe ich mir eine per Netzwerk schaltbare Steckerleiste besorgt, um abgestürzten Raspberries und ähnlichen Geräten auch aus der Ferne einen Neustart zu ermöglichen. Für die Steuerung gibt es ein Webinterface, eine proprietäre Software für ein proprietäres Betriebssystem und eine Handy-App, wofür das Gerät zum Server des Herstellers verbinden muss. Für eine Automatisierungslösung auf der Linux-Konsole muss daher etwas Kreativität und ein paar Zeilen Shellcode her. "Glücklicherweise" ist das Webinterface mit der ganz heissen Nadel gestrickt und Security als überflüssige Geldverschwendung abgetan worden, daher ist das Skript recht simpel ausgefallen:

#!/bin/bash
HOST="192.168.0.x"
PASSWORD="foo"
OUTLET=$1
STATE=$2
curl -sd "pw=$PASSWORD" http://$HOST/login.html | fgrep -q Status
if [ $? -eq 0 ]; then
curl -sd "ctl$OUTLET=$STATE" http://$HOST/status.html | fgrep -q Status
fi
curl -s http://$HOST/login.html | fgrep -q password

Das Skript legt man z.B. unter /usr/local/bin/gembird.sh ab und gibt ihm Ausführungsrechte (chmod +x). Anschliessend lässt es sich aufrufen via gembird.sh dosennummer neuer_zustand, also z.B. gembird.sh 4 0 um die vierte Dose auszuschalten.

Die Hauptarbeit des Webinterface-reverse-Engineerings hat zum Glück schon ein Kritiker auf Amazon übernommen, da der offizielle Herstellersupport nicht sehr hilfreich war. Merke: nächstes Mal die Frage stellen in der Art "ich möchte in Windows unter Cygwin..."

Dank Heartbleed durfte ich erneut alle Zertifikate ersetzen. Hat aber vermutlich niemand gemerkt, da bestimmt alle mein CA-Zertifikat importiert haben. Mir kann man schliesslich vertrauen. Oder?

Da hat sich Google doch einige Mühe gegeben, das Prozedere möglichst umständlich zu gestalten. Für Debian gilt:
als root:

aptitude install libnss3-tools

als user:

wget http://example.com/example-ca.crt
certutil -d sql:$HOME/.pki/nssdb -A -t"C,," -n example.com -i example-ca.crt

Und danach Chromium neu starten.

Mehr Parameter und generelle Instruktionen gibt's hier

In Firefox geht das Klickibunti!

Nachdem ich die ganze Nacht über Alarmmeldungen von verdächtigen Zugriffen von der immer gleichen IP-Adresse erhalten habe, wollte ich dem zuständigen Besitzer Meldung machen. Nun, ein Reverse-DNS-Eintrag für die IP war nicht konfiguriert, aber gemäss whois gehört sie einer grösseren Uni in Deutschland. Also kurzerhand deren abuse@ Adresse angeschrieben, mit Logauszug und Symptomen. Daraufhin kommt die Antwort: Das ist kein Angriff, das ist ein Forschungsprojekt und repliziert das SSL Observatory. Ne, oder? Und dafür muss man hundert Mal auf POP3- und IMAP-Server zugreifen? Ohne den SSL-Handshake zu komplettieren? Das ganze von einer "anonymisierten" IP-Adresse? Vielleicht hätte man da ja auch jemanden fragen können, der sich mit sowas auskennt... grrrrmpf!

Vor dem Network Manager Applet in Debian Wheezy kann derzeit nur gewarnt werden. Der ist so vorsätzlich buggy, man könnte meinen, er wäre von allen grossen, kommerziell orientierten Softwarefirmen gemeinsam geschrieben worden:

• Beim Versuch zu einem WLAN zu verbinden, wird nach dem root-Passwort gefragt - nicht aber nach dem WPA-Schlüssel. Lösung: Unter "Verbindungen bearbeiten" sich durchklicken und den Schlüssel händisch eintragen.
• WLAN kann per GUI deaktiviert werden - aber keinesfall wieder aktiviert. Lösung: In der Kommandozeile als root mittels nmcli nm wifi on geht es wieder. Aber dafür installiere ich ja ein Klickibunti-Tool... damit ich nachher wieder in die Konsole gehen kann.

Neulich hatte ich eine Diskussion über Open Source, Closed Source und Sicherheit. Mein Standpunkt war, dass ich mir sicher nicht proprietäre Software wie Dropbox oder Wuala installieren möchte. Natürlich ist Sicherheit hier mit ein Argument. Allerdings nicht nur die Sicherheit davor, dass kein Schadcode in der Software enthalten ist. Grad bei grösseren OpenSource-Projekten kann auch das nicht zu 100% ausgeschlossen werden. Grad die gewaltigen Codemengen, welche einige Firmen in Form von Treibern beitragen, kann kaum sinnvoll extern reviewed werden, da für ein komplettes Verständnis auch die Hardware-Spezifikation bekannt sein muss.

Es geht mir eher um eine andere Form von Sicherheit: Die Sicherheit, dass ich die Software auch morgen noch einsetzen kann. Denn proprietäre Software hat hier schon immer zu Problemen geführt. Entweder ist der Hersteller überhaupt nicht (mehr) willig, gewisse Plattformen zu unterstützen, oder er ist bei der Unterstützung neuer Plattformen einfach viel zu langsam. Letztendlich kann ich 90% allen Ärgers, den ich unter Linux je hatte, auf das 1% proprietäre Software schieben, den ich im Einsatz habe oder hatte.

Hier nur mal ein paar Beispiele aus meiner Erfahrung:

• VMWare Server (vor vielen Jahren): Nach dem Kernelupdate (Bugfix-Release) lassen sich die Module ums verrecken nicht mehr kompilieren.


• Adobe Flash Player: Erinnert sich noch wer an die Zeiten, als 64bit unter x86 noch neumodischer Schnickschnack war? Da hatte man die Wahl, entweder einen 32bit-Browser ins System reinzuwürgen, den semiproprietären nspluginswrapper zu verwenden, um das 32bit-Flashplugin unter 64bit-Browsern zu nutzen, oder aber eine der nicht funktionierenden freien Flash-Alternativen zu installieren. Oder einfach alternativ jahrelang auf Flash verzichten. Oh, Adobe hat ja neulich auch beschlossen, dass Flash für amd64 in Zukunft gar nicht mehr weiterentwickelt wird.


• Skype: Bis es endlich die offiziellen "64bit"-Pakete gab, konnte man die Software nur unter kompletter Verhunzung der Paketverwaltung ins System würgen. Und dann noch dieses neumodische Audiotreiberzeugs namens ALSA, lass mal noch ein paar Jahre beim obsoleten OSS bleiben... aber hey, das grauenhafte PulsAudio-Zeugs, das ist so schlecht, das unterstützen wir sofort und exklusiv.


• PowerVR Grafiktreiber (für die gute, alte KyroII): nett, dieses Kernel 2.6 Zeugs. Aber einen (instabilen) Treiber gibt's nur für Kernel 2.4. Wer's neuer will, der kann ja den VESA-Treiber nehmen. Doku für die freie Treiberentwicklung? bwahahaha, der war gut!


• nVidia-Grafiktreiber: Trotz Linus' Stinkefinger ja die Vorzeigefirma unter den proprietären Treiberentwicklern: Oh, alte Hardware wird nicht mehr unterstützt. Ausser mit alten Treiberversionen, die keine neuen Kernel unterstützen. Oh, und dieses neumodische KMS-Zeugs mit älterer Hardware... nun, hübsche Konsole, so mit extremer Verzerrung und nicht mehr leserbaren Bootmeldungen...


• AMD-Grafiktreiber: Lass mal den neusten AMD-Treiber auf einem 6 Jahre alten Kernel kompilieren... oh geht nicht, Kernel ist zu neu... Dazu hab ich mich ja schon mehrfach ausgelassen. Ganz davon abgesehen, dass die letzte Treiberversion für meine Hardware der 12.04 ist. Da kann ich nur hoffen, dass bis ich den Umstieg auf Debian 8 ins Auge fasse, der freie radeon-Treiber was taugt. Grad im Bereich Multimonitor.


• Druckertreiber für non-Postscript Drucker: Funktionieren nur mit sehr exotischen Distributionen, haben komische Abhängigkeiten, und natürlich nur für 32bit x86 Systeme.


• Wine und Windows-Spiele: Guter Witz. Ich hab da kaum je was zum laufen gekriegt. Auch wenn Wine der Meinung war, das Spiel hätte Platin-Unterstützung (d.h. perfekt)

Aber auch Hardware ist mühsam, sobald sie nicht über ausreichend freie Dokumentation verfügt:

• Noch einmal AMD und nVidia: Die freien Treiber waren jahrelang gar nicht brauchbar, unterdessen geht wenigstens so langsam mal das grundlegende.


• Windows-Only GDI Drucker: aaaaaaaaaargh!


• Nokia-Telefone: Viel Spass beim Zugriff mit Gnokii. Vielleicht geht es. Wahrscheinlich nicht.


• Pogoplug: Die Pro-Platine (auch im spottbilligen Pogoplug Pink verwendet) verwendet ein proprietäres SoC, in dessen Dokumentation nur ein freier Entwickler unter NDA Einsicht hat. Die Konsequenz: Das Gerät läuft nur mit Arch Linux ARM und uralt-Kernel 2.6.31. Und die wichtigsten Treiber für viele USB-Geräte fehlen darin.

A propos Pogoplug: Der sowie z.B. der Raspberry Pi benutzen die ARM-Architektur. Über die Verwendung von Skype, Flash oder Dropbox nachzudenken, ist absolut müssig.

Das Ziel: Existierende Dateien werden normal angezeigt. Bei nicht existierenden Dateien wird statt Error 404 der Erfolgsstatus 200 und ein Standard-Dokument ausgegeben.

Klingt einfach? Ist es nicht. Das liegt primär daran, dass dafür mod_rewrite braucht, wofür keine gescheite Dokumentation existiert (ist ja schön, wenn die offizielle Doku alle verfügbaren Variablen auflistet, sie aber nirgends erklärt...) und alle bestehenden Howtos irgendwo einen Fehler machen oder diesen zugegebenermassen sehr speziellen Fall überspringen.

So scheitern praktisch alles bestehenden Vorschläge an der fehlerhaften RewriteCond:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

-d und -f prüfen aber den absoluten Dateisystempfad, während REQUEST_FILENAME nur den Teil enthält, welcher in der URL nach dem Hostname steht, d.h. http://www.example.com/requested/filename.html. Somit werden diese Rewrite Conditions sowieso niemals zutreffen. Nun gibt es zwei Lösungen dafür. Entweder den ausschliessenden Weg, dass man alle existierenden Dateien von Hand explizit spezifiziert, z.B.

RewriteCond %{REQUEST_FILENAME} !^/robots.txt$
RewriteCond %{REQUEST_FILENAME} !^/favicon.ico$

Nur hat dies zwei Nachteile, es ist aufwändig und unflexibel. Na gut, die simplere Lösung ist es den vorangehenden Pfadnamen hinzuzufügen, dafür gibt es die glücklicherweise vom Namen her sprechende DOCUMENT_ROOT Variable (eine offizielle Dokumentation, wo diese beschrieben wird, ist aus irgendwelchen Gründen schwierig zu finden...), so dass eine funktionierende, flexible und universelle Regel etwa so aussehen könnte:

RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteRule ^.+$ /index.html [L]

Der rar-Archiver scheint eine praktische Funktion zu besitzen, nämlich das automatische Splitten beim packen. Ich muss diese Funktionalität mutmassen, da ich rar nicht zum packen verwende, da es unfrei ist. Und überhaupt gibt es in der freien Welt so viele Formate, dass ich dieses problemlos links liegen lassen kann. Jedenfalls resultiert das ganze in Dateien mit der Endung foobar.part1.rar, foobar.part2.rar etc. Das scheint wohl ganz praktisch zu sein für ein very poor man's Backup auf CDs.

Nun hatte ich neulich das Vergnügen, so eine Archivserie zu entpacken, bei welcher eines dieser Teilstücke verloren gegangen ist. Beim packen könnte man wohl angeben, dass ein "recovery volume" angelegt werden soll, womit der Verlust eines Teils kompensiert werden kann. Aber wer denkt schon an sowas Rar wird nun zwar anfangen zu entpacken, bricht dann aber bei der ersten Datei ab, welche sich (partiell) im verlorenen Teil befindet. Tja, nun hat man also den ersten Teil seines Backups, aber die Daten von hinter dem fehlenden Stück scheinen nicht zugänglich zu sein. Auch eine Suche mit Google hat hier nicht gross weitergeholfen, der Tenor war stets "kannst du vergessen, geht nicht". Aber das stimmt definitiv nicht! Man braucht sich also nicht zu ärgern, dass das Einlesen von 20 CDs oder das herunterladen von 100GB Daten für die Katz war. Zwar kennt rar den Parameter -kb, welcher defekt extrahierte Dateien behalten soll, aber das funktioniert in diesem Fall nicht. Der Entpackvorgang bricht trotzdem ab (hier für Klickibunti-Windosen).

Hier der Trick: Angenommen, part4.rar fehlt. Also erstellt man erst einen scheinbaren Teil 4. Am einfachsten kopiert man einen anderen Teil:
cp foobar.part3.rar foobar.part4.rar
Nun startet man den nächsten Entpackvorgang, schliesst jedoch die als defekt gemeldete(n) Dateien über den exclude-Parameter aus. Wichtig ist die korrekte Syntax zu beachten, nach dem -x darf kein Leerzeichen folgen und Dateinamen mit Leerzeichen müssen zwischen Hochkommata stehen:
unrar x -x'pfad/zu/defekter datei.xls' -x'pfad/zu/ebenfalls defekter datei.doc' foobar.part1.rar
Schon entpackt es weiter.

Natürlich fehlen letztendlich ein paar Daten unwiderbringlich. Aber sofern es sich um eine Notrekonstruktion aus einem defekten "very poor man's" Backup handelt, ist das doch schon besser als gar nichts mehr zu haben.

Da kommt doch so ein schöner Spam mit Link auf Schadsoftware zu mir, (mit noch etwa 100 weiteren Adressen als Empfängern). Keine 90 Minuten später kommt ein Nachschlag von Melani ("Melde- und Analysestelle Informationssicherung") und warnt explizit davor, den Link anzuklicken. Das nenne ich doch mal schnelle Handlung und verhindert vielleicht die eine oder andere Infektion.

Neulich bin ich mal gefragt worden, wie ich Backups mache. Die Antwort: Mit einem relativ simplen Cron-Skript und rdiff-backup per SSH auf den Fileserver. Das gibt ein schönes inkrementelles Backup, bei dem man beliebig weit zurückgehen kann, allerdings behalte ich nur die Daten der letzten zwei Monate. Rdiff-Backup braucht relativ wenig Rechenleistung, Bandbreite und Speicherplatz und funktioniert auch hervorragend über's Internet. Wird das Cron-Skript häufig genug aufgerufen, emuliert dieses Backup recht gut das Verhalten von Apples Time-Machine. Nachteilig ist lediglich, dass es in meinem Fall ein vom Clienten initiiertes Backup ist. Solange der zu sichernde Rechner die Daten auf den Backup-Server schreibt, ist ein Backup nicht sicher vor Manipulationen. Besser wäre es, wenn der Server vom Clienten lesen würde. Nur bräuchte der Server dann root-Login auf dem Clienten, was auch nicht unbedingt der Sicherheit förderlich ist...

Folgendes muss man auf dem Server einrichten:

• SSH-User für's Backup
• Im $HOME/.ssh/authorized_keys die public-SSH-Keys des root-Users der zu sichernden Systeme eintragen (ja, das Backup-Skript wird in der Regel als root laufen, da man z.B. auch /etc sichern will).
• Im Verzeichnis, welches die Backups enthalten soll, muss für jeden zu sichernden Rechner ein Verzeichnis erstellt werden, das so heisst, wie der Host (zu erfahren durch Eingabe von "hostname" auf dem Client)
• In diesen Verzeichnissen muss jeweils eine Verzeichnisstruktur erstellt werden, welche der $DIRECTORIES-Variable aus untenstehendem Skript entspricht.
• Zuletzt chownt man diese gesamte Struktur an den zuerst erstellen SSH-User.

Und so schaut mein Skript aus:

#!/bin/bash

### Settings ###
DIRECTORIES="/etc /home /usr/local/bin"
EXCLUDES="/home/*/.local/share/Trash"
SSHUSER="rdiff-backup"
SSHHOST="192.168.0.1"
REMOTEDIR="/mnt/backup/$(hostname)/"
RDIFF="/usr/bin/rdiff-backup"
RDIFFOPTIONS="ssh -p 2222 %s rdiff-backup --server"
FILEAGE="2M"

NOW=$(date +"%Y-%m-%d")
GZIP="$(which gzip)"
STATUSFILE="/var/tmp/rdiff-backup-status"
LOCKFILE="/var/lock/rdiff-backup-lock"
DUMPDIR="/home/backup"

if [ -e "$LOCKFILE" ]; then
echo "Lockfile exists, quitting..."
exit 255
fi

touch "$LOCKFILE"

### Packages List ###
dpkg --get-selections | $GZIP > $DUMPDIR/dpkg.$NOW.txt.gz
RETVAL=$(($RETVAL + $?))

### File based Backup ###
for DIR in $DIRECTORIES; do
EXCLUDESLIST=""
for EXCLUDE in $EXCLUDES; do
SIZE=$(expr match "$EXCLUDE" "$DIR")
if [ $SIZE -gt 0 ]; then
EXCLUDESLIST="$EXCLUDESLIST --exclude $EXCLUDE"
fi
done
$RDIFF $EXCLUDESLIST --remote-schema "$RDIFFOPTIONS" $DIR $SSHUSER@$SSHHOST::$REMOTEDIR/$DIR
RDIFFRETVAL=$?
RETVAL=$(($RETVAL + $RDIFFRETVAL))
if [ $RDIFFRETVAL = 0 ]; then
$RDIFF --force --remote-schema "$RDIFFOPTIONS" --remove-older-than $FILEAGE $SSHUSER@$SSHHOST::$REMOTEDIR/$DIR
RETVAL=$(($RETVAL + $?))
fi
done

find $DUMPDIR -ctime +7 -exec rm -f '{}' ';'
RETVAL=$(($RETVAL + $?))

echo $RETVAL > "$STATUSFILE"
rm -f "$LOCKFILE"
exit $RETVAL

Was bedeuten nun all die Variablen unter "Settings"?

• DIRECTORIES: Die zu sichernden Verzeichnisse.
• EXCLUDES: Nicht zu sichernde Verzeichnisse
• SSHUSER: Mit welchem User wird per SSH am Server angemeldet
• SSHHOST: Die Adresse des Backup-Servers. Entweder eine IP oder ein Hostname.
• REMOTEDIR: Das Basisverzeichnis, worin auf dem Server die Backups gespeichert werden.
• RDIFF: Pfad zum lokal rdiff-backup Binary
• RDIFFOPTIONS: Wenn man zusätzliche Optionen angeben will, z.B. einen alternativen SSH-Port. Kann man auch leer lassen
• FILEAGE: Nach wie vielen Tagen/Monaten/Jahren die Inkremente gelöscht werden sollen