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.

Normalerweise nutze ich die APU's mit pfsense oder opnsense als Firewall, aber diesmal soll ein etwas multifunktionaleres OS drauf, daher wie üblich: Debian.

Die Anleitungen lesen sich simpel. einfach Installer auf USB-Stick schreiben, USB-Stick rein, Serial-Kabel rein, anschalten, installieren, läuft.
Wie immer sind die Anleitungen gelogen. Es ist nie einfach. Es ist immer unnötig fucking kompliziert.

Erstes Problem: Der Installer lädt nicht. Es hängt nach ISOLINUX. Klar, der Installer kann kein Serial. Also: Netinstall-CD patchen, neu bauen, nochmals versuchen. Etwas Hilfe leistet dieser Github-Gist:
- Netinstall-Image herunterladen
- lokal mounten: mount -o loop debian-10.7.0-amd64-netinst.iso /mnt/temp/
- Arbeitsverzeichnis erstellen: mkdir iso-rework
- Kopieren: cp -r /mnt/temp/. iso-rework/
- Dateien bearbeiten: cd iso-rework/isolinux && chmod +w *.cfg
- in isolinux.cfg die Zeile SERIAL 0 115200 0 einfügen
- in txt.cfg die letzte Zeile ersetzen mit append gfxpayload=text console=ttyS0,115200 initrd=/install.amd/initrd.gz --- quiet
- wieder ins übergeordnete Verzeichnis zurückwechseln: ../..
- ISO neu bauen: xorriso -as mkisofs -rational-rock -joliet -joliet-long -full-iso9660-filenames -isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -partition_offset 16 -appid "Debian10.7" -eltorito-boot isolinux/isolinux.bin -eltorito-catalog isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o debian-10.7-amd64-netinst-serial-console-ttyS1-115200-8n1.iso iso-rework
- und nun den USB-Stick neu bespielen: dd if=debian-10.7-amd64-netinst-serial-console-ttyS1-115200-8n1.iso of=/dev/sdX bs=4M && sync

JETZT kann man das Ding einstecken und "einfach" booten.
Nächstes Problem: Konsolenoutput ist unleserlich. Lösung Teil 1: USB-Serial-Kabel nicht in einen USB-Hub sondern direkt in den PC stecken. Lösung Teil 2: Putty verwenden. Aber das lässt sich grafisch nicht konfigurieren (denn das wäre ja einfach), also muss man es von der Kommandozeile richtig aufrufen: putty /dev/ttyUSB0 -serial -sercfg 115200,8,n,1

Über Putty kann man nun schön beobachten, wie BIOS und Isolinux geladen werden und die Installationsauswahl angezeigt wird. Natürlich nicht "Graphical Installer" sondern "Install" (für Textinstallation) wählen. Das klappt bei mir jedoch nicht über serial... Ich brauche eine USB-Tastatur...

Nochmals von vorn. Und: Es lädt den Textinstaller. Doch kommen wir nun zum major fuckup des Tages, der mich extrem viel Zeit kostete, um mit Boot-Optionen zu experimentieren, es mit Debian 9 zu versuchen und sogar ein anderes APU zu probieren, um auszuschliessen, dass nicht ein Hardware-Defekt vorliegt:
Nun stecke ich in der Sprachauswahl des Installers und da geht wieder nichts mehr. Ich kann keine Sprache auswählen. Ich kann Tab, Space, Enter drücken, nichts passiert. Ich kann Eingaben über Putty versuchen, nichts passiert. Tatsächlich scheint dies ein bekanntes Problem von ein paar Laptops zu sein.
Irgendwann fand ich die brachiale Lösung: Nach Auswahl des Installers sofort die USB-Tastatur ausstecken, bevor der Kernel zu weit geladen hat. Dann über Putty weiterarbeiten.

Wieder einmal: Eine supereinfache Tätigkeit, zur völligen Perversion verkompliziert. Einfach, weil nichts "einfach" sein darf. One does not simply. Nicht wahr, Boromir?

oh-oh! Nachdem ICQ schon vor einigen Monaten das Protokoll mal wieder geändert hatte und dadurch mein XMPP-to-ICQ-Transport nicht mehr funktionierte, habe ich heute Morgen aufgeräumt und ICQ komplett entsorgt. Die verwendete Transport-Software pyicqt wird seit 11 Jahren nicht mehr weiterentwickelt, da besteht keine Hoffnung auf Wiederbelebung.

Zeit, ein Kapitel endgültig abzuschliessen. Und wieder einmal das Mantra zu wiederholen: Nutzt freie Protokolle!

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

Das Twitter-Plugin für mein Blog kündigt neue Einträge auf Twitter an, von wo sie dann wiederum auf Facebook veröffentlicht werden können. Leider mit einem Nachteil: Es wird immer das Schema verwendet (also http oder https), womit auch der Eintrag erstellt wurde. Es ist somit nicht möglich, für die Veröffentlichung http oder https zu erzwingen. In meinem Fall wäre es schön, wenn immer eine URL beginnend mit http:// verwendet werden würde, da ich zwar die Einträge über das verschlüsselte https:// schreibe, dafür aber ein selbstsigniertes Zertifikat benutze, das bei anderen Leuten eine Fehlermeldung im Browser erzeugt. Dies möchte ich nicht ändern, da kostenpflichtige Zertifikate einfach zu teuer sind, kostenlose Zertifikate wie z.B. von StartSSL meinen Ansprüchen nicht genügen und ich bei Mozilla's Let's Encrypt nicht wirklich Lust habe, Skripte zu installieren, die mir zuletzt noch die Webserver-Konfiguration zerschiessen.

Lösung: Ein schneller Hack des Plugins, um die veröffentlichte URL auf http:// festzunageln. Nachteil: Wenn ich das Plugin aktualisiere, muss ich daran denken, den Hack erneut vorzunehmen.

In der Datei serendipity_event_twitter.php muss in der Funktion generate_article_url die Zeile
$server = $urlparts['scheme'] . '://' . $urlparts['host'];
ersetzt werden durch:
$server = 'http://' . $urlparts['host'];

Dieser Eintrag dient mal wieder der Dokumentation und als Erinnerung an mich selbst, sowie als Erklärung für alle die sich wundern, warum der Artikel über Kuala Lumpur sich ohne Fehlermeldung aufrufen lässt

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?

Mit den Standardoptionen macht ein Systemstart mit per NFS verbundenen Laufwerken nur so lange Spass, wie der Server erreichbar ist. Ist der Server bzw das Netzwerk nicht erreichbar, so führen die Standardoptionen dazu, dass Debian während dem Systemstart minutenlang versucht zu mounten - und in der Zwischenzeit nicht weiterbooten will. Die Mountversuche lassen sich auch nicht mit CTRL-C oder anderen Tastenkombinationen abbrechen. Da kann man nur warten und sich ärgern... oder die /etc/fstab gleich von Anfang an mit den richtigen Optionen ausstatten.

Jetzt schauen meine Einträge für NFS-mounts so aus:

nas:/storage /mnt/storage nfs4 bg,retry=0,timeo=2,_netdev 0 0

Was passiert hier? Die Freigabe /storage vom Server nas wird nach /mnt/storage per NFS4 eingebunden. Schlägt der erste Mountversuch fehl (retry=0), geht der Mountprozess in den Hintergrund (bg) und versucht es dort weiter. Als Fehlschlag wird der Mountversuch gewertet, wenn die Antwort vom Server nicht innert 0.2s eintrifft (timeo=2). retry=0 zu setzen ist ganz wichtig, da der Wert bei Verwendung von bg standardmässig auf 10000 Minuten gesetzt ist. Da wartet man im dümmsten Fall fast eine Woche lang.
_netdev sorgt dafür, dass ein Mountversuch erst stattfindet, nachdem das Netzwerk gestartet wurde.

Sehr nützlich ist das auch für Notebooks.

Falls das Serverlog daraufhin Fehlermeldungen der Art "rpc-srv/tcp: nfsd: sent only 180288 when sending 524352 bytes - shutting down socket" enhält, sollte der Wert für timeo etwas erhöht werden.

Lesematerial dazu:

man 5 mount

Diesmal handelt es sich um eine Disk aus einem dubiosen NAS. Anscheinend pappt das /dev/sda1 und /dev/sda2 zu einem RAID-1 zusammen. Dies wird wohl so gemacht, um das System elegant aktualisieren zu können. Jedenfalls, musste da mal Hand an die Systemdaten angelegt werden.

Nun, Standardübung, nehmen wir mdadm:

mdadm --assemble /dev/md/0 /dev/sdb1 /dev/sdb2
mdadm: no recogniseable superblock on /dev/sdb1
mdadm: /dev/sdb1 has no superblock - assembly aborted

Wie? Kein Superblock? jaaa aber... parted ist da anderer Meinung:

parted /dev/sdb print
Model: WDC WD10 EARX-00N0YB0 (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
3 15.7MB 528MB 513MB primary
1 528MB 2576MB 2048MB ext3 primary raid
2 2576MB 4624MB 2048MB ext3 primary raid
4 4624MB 1000GB 996GB ext4 primary

Was nun? Es handelt sich hierbei um ein Legacy-RAID ohne Superblock. Das setzt man nicht mit assemble sondern mit build zusammen:

mdadm --build /dev/md/0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdb2
mdadm: array /dev/md/0 built and started.

Nach der Resynchronisation erfolgt der erste mount-Versuch:

mount /dev/md/0 temp/
mount: unknown filesystem type 'linux_raid_member'

Na gut, erzwingen wir das Dateisystem:

mount /dev/md/0 temp/ -t ext3

Perfekt, alle Daten da

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]

Dank virt-manager kann man auch mit kvm und xen per Klickibunti übers Netzwerk administrieren. Nur, unter Debian kann es vorkommen, dass alles korrekt eingerichtet ist (libvirtd läuft, User ist in der Gruppe libvirtd, /var/run/libvirt/libvirt-sock ist zugreifbar), trotzdem weigert sich der virt-manager mit der Meldung

"Unable to open a connection to the libvirt management daemon. Verify that: - The 'libvirtd' daemon has been started"

Liest man die Meldung weiter, so stösst man auf die Zeile

error: server closed connection: nc: invalid option -- 'U'

Die Lösung: Debian installiert standardmässig netcat-traditional. Das unterstützt aber die Option U nicht. Dafür wird netcat-openbsd benötigt. Folglich kann man das beheben mittels

aptitude install netcat-openbsd

Zum Glück ist Debian Stable ja sooo bugfrei.

Die Zukunft hat begonnen Ich bin ab jetzt auch über IPv6 verbunden. Derzeit zwar nur per Tunnel, aber hoffentlich bald auch richtig.

Schade, dass nagelneue Boards immer noch dieses eklige BIOS statt dem wesentlich moderneren EFI mitbringen. BIOS und Grub können nämlich nichts mit GPT anfangen, was für grosse Partitionen über 2TB aber notwendig ist. Und BIOS bzw MBR begrenzt die Partitionsgrösse auf anachronistische 2TB. Denn wenn man schon 4*2TB kauft, um ein anständiges NAS zu basteln, will man sich nicht lange mit Daten hin-und-her-Schaufelei von Partition A nach Partition B und zurück befassen. Doch auch dafür gibt es eine Lösung:

Es darf einfach keine Partition über 2TB Grösse existieren, auch nicht als Software-RAID-Verbund. Aber LVM darf sich darüber hinwegsetzen.

Daher mein Setup:
- Am Anfang der Platten eine kleine Partition von 128MB als RAID-1 für /boot
- Danach drei Partitionen à 666GB, welche jeweils als RAID-10 zusammengefasst werden
- Die drei RAID-10 Partitionen werden mittels LVM zu einem gigantischen logischen Volume zusammengefasst. Alternativ kann man natürlich auch ein RAID-5 nehmen, dann tauscht man 2TB mehr Festplattenplatz gegen massiven CPU-Overhead bei allen Zugriffen ein.

Zuerst mal mit einer Live-CD nach Wahl starten und die Disks vorbereiten. Zu beachten ist, dass so grosse Festplatten gerne mit 4k-Sektoren ausgeliefert werden:

cfdisk -h224 -s56 /dev/sda #erstellen von 4 Partitionen vom Typ FD (RAID autodetect) unter Beachtung der 4k-Sektorengrenze
sfdisk -d /dev/sda | sfdisk --force /dev/sdb #sfdisk mag die 4k-Sektorengrenzen nicht, daher erzwingen wir sie
sfdisk -d /dev/sda | sfdisk --force /dev/sdc
sfdisk -d /dev/sda | sfdisk --force /dev/sdd
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=4 /dev/sd?1
mdadm --create --verbose /dev/md1 --level=10 --raid-devices=4 /dev/sd?5
mdadm --create --verbose /dev/md2 --level=10 --raid-devices=4 /dev/sd?6
mdadm --create --verbose /dev/md3 --level=10 --raid-devices=4 /dev/sd?7
pvcreate /dev/md[123]
vgcreate bigdisk /dev/md[123]
vgchange -a y bigdisk

Danach erstellt man ein paar logische Volumen nach Bedarf, startet die Setup-CD (in meinem Fall natürlich Debian Squeeze) und schon läuft die Sache rund. Partman wird sich zwar trotzdem beschweren, lässt aber die Installation zu. Und Grub installiert sich ganz normal im MBR.

mod_gnutls hab ich wieder durch mod_ssl ersetzen müssen. Grund:

[Tue Aug 17 09:21:32 2010] [notice] Apache/2.2.9 (Debian) mod_gnutls/0.5.1 configured -- resuming normal operations
page 7: illegal page type or format
PANIC: Invalid argument
PANIC: fatal region error detected; run recovery

Und die letzte Zeile wiederholt sich dann, bis das Logfile die Festplattenkapazität gesprengt hat. Dauert bei den paar freien GB auf dem vserver so ca 20 Minuten...

Ich hab ein Bisschen am Server umgebaut und in letzter Zeit einiger Änderungen vorgenommen:

1. Courier durch Dovecot ersetzt.
Dovecot ist viel cooler als Courier und kann viel mehr. Statt einem grausamen Flickwerk und Gebastel hab ich mit Dovecot eine Lösung, die mir alles mögliche aus einer Hand bietet. Postfix kann SASL-Authentifizierung direkt über Dovecot-SASL machen statt über diesen grauenhaften Courier-SASL-Umweg, bei dem sich Courier-SASL erst am IMAP-Server anmelden muss, weil Courier-SASL ja nicht mit verschlüsselten Passwörtern umgehen kann. Ausserdem bietet Dovecot eine integrierte Mailfilterung an und über ein Roundcube-Plugin kann man die Filter sogar Klickibunti setzen

2. Postfix-policyd durch Spamhaus ersetzt.
Bislang hab ich zur simplen, ressourcenschonenend Spam-Bekämpfung auf Greylisting gesetzt. Mein Server ist nämlich massiv zu schwachbrüstig, als dass ich überhaupt nur dran denken könnte, Spamassassin einzusetzen. Das funktioniert zwar relativ gut, hält aber letztendlich nur Botspam fern. Stattdessen nutze ich nun zen.spamhaus.org, um mir unerwünschte Mailhosts vom Leib zu halten. Der Erfolg lässt sich in meiner Inbox sehen. Statt 1-3 Spams pro Tag hab ich seit zwei Monaten kein einziges mehr bekommen. Die Konfiguration ist denkbar einfach. Einfach in der /etc/postfix/main.cf die Direktive smtpd_client_restrictions um den Eintrag reject_rbl_client zen.spamhaus.org ergänzen und Postfix neu laden.

3. Apaches mod_ssl durch mod_gnutls ersetzt.
Dies hat zwei Vorteile: Erstens weniger RAM-Verbrauch, da mod_gnutls minimal schlanker ist. Zweitens kann mod_gnutls Server Name Indication. Das heisst, dass ich für jeden Virtual Host ein eigenes SSL-Zertifikat verwenden kann. Das ist wichtig, weil ich nur eine IP habe, auf meinem Server aber mehrere Domänen mit SSL-Unterstützung laufen.

4. Das Blog hat zwei neue Plugins spendiert bekommen.
Schon seit einiger Zeit finden sich Buttons zu diversen Social Bookmark Seiten unter jedem Blog-Eintrag. Lediglich den Facebook-I-Like-Iframe hab ich aus Datenschutzgründen rauskommentiert. Facebook braucht nicht zu wissen, wer mein Blog besucht. Die restlichen Symbole werden von meinem Server ausgeliefert. Die Dienste bekommen folglich nur mit, dass jemand meine Seite besucht hat, wenn der Eintrag dort registriert wird.
Da ich mich bei Flattr angemeldet habe, um diverse meiner favorisierten News-Seiten und Blogs einfach und unbürokratisch finanziell unterstützen zu können, hab ich auch grad einen Flattr-Button bei mir eingebaut. Natürlich erwarte ich keine Einnahmen dadurch, dafür bin ich wirklich zu irrelevant. Mich stört auch, dass die Flattr-Buttons vom Flattr-Server geladen werden. Damit bekommt Flattr leider jedesmal mit, wer auf meine Seite zugreift. Ich muss mal schauen, ob es ein besseres Plugin gibt oder ob ich die Zeit finde, das Plugin mal zu hacken, so dass ein statisches Flattr-Symbol von meinem Server ausgeliefert wird. Denn wieso sollte ich Flattr anders behandeln als Facebook?