Partitionsmagie mit Debian

Heute kommen wir (hoffentlich) zu der Lösung, wie man auf einer Festplatte mit einem verschlüsselten LVM die Partitionen ändern, vorzugsweise ohne Neuinstallation.

Hintergrund bei dem Vorhaben ist Problem, dass der Speicherbedarf der /boot-Partition mit den Jahren nicht kleiner wird und wenn man selbige beim Installieren des Systems zu knapp bemessen hat, hat man irgendwann den Salat: Es gibt beim Update Mecker, weil die Partition volläuft. Ja, man kann alte Kernel löschen (und sollte das sogar), aber ich hebe zum aktuelleb Kernel gern noch den direkten Vorgänger auf. Und wenn nicht genug Platz für 3 inklusive derer initialen Ramdisks ist: doof.

Datensicherung

Bevor man an Speichersystemen rumfummelt: Datensicherung machen. Es gibt kein Mitleid für Leute, die das nicht beherzigen. Wie man die Datensicherung macht: Egal, Hauptsache, sie funktioniert. Ein USB-Stick oder eine Speicherkarte ist übrigens kein Datensicherungsmedium, sondern ein Datentransportmedium. Macht keine Datensicherungen auf solchen Teilen.

Die ersten Herausforderungen

Nach der Sicherung gibt’s die ersten Herausforderungen:

Das System liegt auf einem LVM, welches aus einem LUKS-verschlüsselten Device liegt. Man muss also zunächst Platz schaffen. Da ich mehr als ausreichend Swap-Speicher habe, reduziere ich selbigen um 4 GB:

swapoff /dev/mapper/vg01/swap
lvresize -L -4G /dev/mapper/vg01/swap
mkswap /dev/mapper/vg01/swap
swapon -a

Das eigentliche Problem ergibt sich anschließend:

  • Den nötigen Speicherplatz freimachen mittels pvresize
  • Das verschlüsselte Volume verkleinern
  • Die Volumegroup nach hinten schieben, um für das /boot-Filesystem Platz zu schaffen
  • Das /boot-Filesystem vergrößern

Alles ganz schön viel Kram. Glücklicherweise kann gparted (https://gparted.org/) das fast alles automatisch. Man nehme also ein GRML (https://www.grml.org) oder SystemRescue (https://www.system-rescue.org/) und starte das System von einem damit bestückten Rettungssystem. Um die LVs zu verkleinern, muss man die verschlüsselte Partition entsperren. Danach kann man die LVs und auch die gesamte verschlüsselte Partition verkleinern und anschließend auf der Platte „nach hinten schieben“. Dadurch gewinnt man den nötigen Platz am Ende der /boot-Partition. Dass das Verschieben der Platte eine Zeit dauern, ergibt sich von selbst. Müssen hier doch etwas 450GB umkopiert werden. Hier dauert das auf einer SATA-SSD gut 1 Stunde.

Gparted hat hier hervorragende Dienste geleistet. Auch das Vergrößern der /boot-Partition ging ohne jedes Problem.

Twitter dreht mal wieder frei

Heute morgen hat mir Twitter ohne mich zu informieren und daher auch ohne mir einen Grund mitzuteilen, meinen Account gesperrt. Vermutlich habe ich gegen irgendwelche dubiosen Twitterregeln verstossen, die natürlich wie immer reine Auslegungssache der schlecht programmierten KI oder der schlecht bezahlten Aushilfssherrifs ist. Propaganda vom rechten Rand ist offenbar ok, darauf hinweisen offenbar nicht. Oder vielleicht hat sich auch irgendein Politiker rechts der Mitte darüber beschwert, daß sein substanzloses Bashen von grünen Politikern eher lächerlich ist. Oder daß ihm der moralische Kompass abhanden gekommen ist. Man weiß es nicht.

Ich werde wohl bei Twitter nur noch mitlesen und ansonsten eher in’s Fediverse zu Mastodon wechseln. Da zensiert wenigstens nicht irgendein wildgewordenes Privatunternehmen legitime Äußerungen. Twitter hat ja offenbar eh die beste Zeit hinter sich. Zumindest sagen das auch andere Leute, die schon lange dabei sind.

Bind müllt das Log voll

Irgendwie meint der Bind-DNS-Server zuweilen, daß er das Log mit Einträgen wie

named[12217]: REFUSED unexpected RCODE resolving '2.debian.pool.ntp.org/AAAA/IN': 198.97.190.53#53

vollmüllen muss. Das erzeugt dann auf die Schnelle mal mehrere GB an Logdateien. Unschön. Abhilfe schafft hier ein Eintrag in der Konfigurationsdatei /etc/bind/named.conf.local:

logging {
  category notify { null; };
  category lame-servers { null; };
}; 

Ggf. muß man das natürlich noch an etwaig bestehende Konfigurationsoptionen zum Thema logging anpassen. Aber wer das Logging von Bind eh schon konfiguriert hat, wird wissen, wie das geht.

Unix-Dateiberechtigungen wieder herstellen

Wenn man nicht aufpasst, schießt man sich (im übertragenen Sinn natürlich) eventuell in den Fuß. An der falschen Stelle ein

chmod a+r *

führt dann leider unter Umständen zu einem kaputten /etc-Verzeichnis. Glücklich ist, wer dann eine Datensicherung hat. Allerdings will man unter Umständen ja nicht die „alten“ Daten zurückkopieren, sondern nur die Berechtigungen rekonstruieren. Aus der Datensicherung spielt man das Verzeichnis dann ggf. in ein temporäres Verzeichnis zurück und führt in selbigen

find . -printf 'chmod %m %p\n' > /var/tmp/fix_permissions.sh

aus. Dann wechselt man (in meinem Fall nach /etc) und führt das Script dort aus:

cd /etc
/var/tmp/fix_permissions.sh

Bleibt noch zu erwähnen: Das funktioniert nur mit Standard-Unix-Berechtigungen. Wenn man Posix-ACLs verwendet, muss man ggf. selbige im Anschluss korrigieren. Wie das funktioniert werde ich später mal erklären.

Und bevor ich es vergesse: Sorgt dafür, dass ihr eine funktionierende Datensicherung habt und verschlüsselt die immer gut 😉

Probleme mit dmtxread oder ImageMagick beim Lesen von PDF-Dateien?

Ich habe mir gerade halbwegs einen Wolf gesucht, warum dmtxread unter Debian 10 (Buster) jeden Versuch, eine PDF-Datei einzulesen mit der Begründung abgelehnt hat, es könne die Datei nicht lesen. Alle anderen Programm konnten das. Zunächst war ich ja der Meinung, dass das mit dem Update von Debian 9 auf 10 zu tun gehabt hätte. Hatte es aber nicht.

In Debian 10 ist für ImageMagick, welches libdmtx für bestimmte Konvetierungen benötigt, so eingestellt, dass es schlichtweg keine PDF-Dateien akzeptiert. Der Grund dafür ist wohl, dass es einen Bug in Ghostscript (der widerum für PDF-Formate in ImageMagick benötigt wird) gibt, der ein Sicherheitsproblem darstellen kann. Dieser Bug ist zumindest upstream gefixt, so daß man die Beschränkung der PDF-Dateien in ImageMgick aufheben kann.

Dazu kommentiert man in /etc/ImageMagick/policy.xml den Eintrag

<policy domain="coder" rights="none" pattern="PDF" />

aus:
 <!-- <policy domain="coder" rights="none" pattern="PDF" /> -->

Danach läuft dmtxread ohne Probleme und ImageMagick konvertiert auch PDF-Dateien wieder.

Hewlett-Packard, ich glaube wir werden keine Freunde mehr

Nachdem ich gestern stundenlang Spaß mit HP-Druckern hatte, habe ich heute das zweifelhafte Vergnügen in ein HP Pavillion eine SSD einzubauen. Nachdem ich schon von den Versuchen gelesen habe, dass dieses Modell nicht verlustfrei zu öffnen sein ( https://tuhlteim.de/hp-pavilion-notebook-nicht-zu-oeffnen ), muss ich feststellen: Geht doch, wenngleich „wartungsfreundlich“ offenbar nicht zu Hewlett-Packards Stärken gehört. Mit dem richtigen Werkzeug (hier iFixit Tools) und ganz viel Feingefühl bekommt man das Gerät geöffnet.

Man muss, wie im Handbuch ( http://h10032.www1.hp.com/ctg/Manual/c05122688 ) beschrieben, vorn anfangen. Danach erst die linke Seite vorsichtig aufhebeln, danach die rechte.

Die SSD ist drin.

Zusammenbauen ist dann einfacher, aber dennoch weit entfernt von der Wartungsfreundlichkeit von Businessgeräten. Warum man die Geräte für den kleinen Geldbeutel dermaßen wartungsunfreundlich gestaltet, erschließt sich mir nicht.

Es mag sein, dass ihr beim Öffnen eures Gerätes selbiges zerstört, die Büchse der Pandora öffnet oder einen thermonukleraren Zwischenfall auslöst. Daher: Alles auf eigene Gefahr, wenngleich es für mich funktioniert hat.

HP Drucker unter Windows: Lasst da lieber die Finger von

Ich habe ja immer schon HP Drucker benutzt, weil die unter Linux eine anständige Treiberunterstützung haben. So weit, so gut. Jetzt hätte ich das zweifelhafte Vergnügen, einen HP Smart Tank Plus 555 unter Windows einzurichten. Eigentlich sollte der nur per USB an einen einsamen Rechner geklemmt werden. Stellt sich raus: geht nicht. Die Scanfunktion ließ sich problemlos einrichten, der Treiber insistiert aber, dass es keinen Drucker gäbe. Der Versuch, das Teil auf umständlichste Weise per WLAN zur Zusammenarbeit zu bewegen, scheint schon daran zu scheitern, dass die WLAN-Geräte in einem anderen Netz sind, wie der PC. Router scheint der Drucker nicht zu kennen.

Nachdem man den Drucker in Windows manuell konfiguriert, behauptet Windows, dass es keinen Treiber hätte. Ungeachtet der Tatsache, dass man selbigen vorher ausgewählt hat. Bleibt jetzt noch die Option, einen anderen Treiber von Windows-Update zu probieren. 😡

Windows-Update hat auch keine passenden Treiber. Nun das manuelle Installationsprogramm. Das findet den Drucker auch nicht. Nachdem man die IP-Adresse manuell eingeben hat, tut sich etwas. Es gibt Mecker, weil die Geräte in unterschiedlichen Netzen sind. Dass alle anderen Geräte Dank des mdns-Repeaters auf dem Router da keine Sorgen haben, interessiert HP offenbar nicht.

Was mich auch massiv stört: Warum zum Geier will HP auf meinen Geräten Daten erheben und warum kann ich da nicht widersprechen? Da muss ich doch mal mit einer Datenschutzfachperson Kontakt aufnehmen.

Der Assistent lügt, ohne rot zu werden.

Letztlich stellt sich raus, dass es sich hier wohl um das Zusammentreffen unglücklicherer Zufälle handelt. Es drängt sich aber durchaus der Verdacht auf, dass das den Stümpern bei HP und Microsoft zusammen anzulasten ist. Auf einem anderen Windows-Gerät ließ sich der Drucker völlig streßfrei einrichten, auf diesem Gerät liefen u.a. die Drucker von Xerox völlig ohne Auffälligkeiten. Vielleicht produziert man auch einfach mal Treiber, die sich einfach installieren lassen und nicht mehrere 100 MB unnützes Zeug installieren. Die Chance, dass sich da irgendwo Probleme einschleppen, ist nicht ganz unwahrscheinlich.

Statische Routen via DHCP

Grundsätzlich können Linux und sogar Windows-Rechner statische Routen per DHCP zugewiesen bekommen. Natürlich hat Microsoft sich wieder eine Extrawurst gebraten und anderen Konfiguratiuonsoptionen benutzt als alle anderen, aber wenigstens verwenden sie das gleiche Format:

option rfc3442-classless-static-routes 24, 192, 168, 96, 192, 168, 80, 2, 0, 192, 168, 80, 251;
option ms-classless-static-routes 24, 192, 168, 96, 192, 168, 80, 2, 0, 192, 168, 80, 251;

So werden bei den Subnetzen, die als Ziel angegeben werden die Nullen eingespart. Das Format ist daher:

<Netwerk-Suffix>, <Netz-Byte 1>, <Netz-Byte 2>, <Netz-Byte 3>, <Router-Byte 1> ,<Router-Byte 2>, <Router-Byte 3>

Man kann mit Komma getrennt mehrere Routen angeben. So wird oft, die Standardroute auch auf diese Weise verteilt. Da lautet der Eintrag dann folgerichtig: 0,<Router-Byte 1>,<Router-Byte 2>,<Router-Byte 3>

Leider kommen nicht alle Geräte damit klar. Insbesondere Geräte von Ubiquiti scheinen die Optionen nicht zu akzeptieren. Getestet habe ich das mit Unifi- und EdgeSwitchen. Beide ignorieren die DHCP-Optionen.