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.

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.

Update Nextcloud 20 -> 21

Gerade bin ich beim Update der Nextcloud von 20.x auf die aktuelle 21 auf das Problem gestossen, dass der Out-of-Memory-Killer des Kernels den Updateprozess reproduzierbar abwürgt. Lösung dafür:

apc.enable_cli=1 

in die /etc/php/7.3/cli/conf.d/20-apcu.ini eintragen. Danach den Upgradeprozess nochmals anwerfen.

Upgrade omv 4 nach 5

das Upgrade auf openmediavault 5 (und warum man lieber neu installieren sollte)

Nach mehreren Schweißausbrüchen (u.a. wegen der nicht vollständigen Datensicherung) und der Tatsache, daß ich mich eigentlich schon mit dem Zurücksetzen des ZFS-Snapshots beschäftigt hatte, habe ich das Upgrade jetzt wohl fertig. Allerdings nur unter Zuhilfenahme eines fertig eingerichteten OMV-5 und einiger schmutziger Tricks aus “don’t try this at home”-Kiste. Neben einigen nicht angelegten Konfigurationsdateien waren auch Dienste deaktiviert. Darunter der Konfigurationsdaemon. Was permanent dazu geführt hat, dass Änderungen im WebUI ausser Fehlermeldungen nix eingebracht haben.

Man möge also beherzigen, dass ein Upgrade nicht supported ist. Daher: Daten sichern, neu aufsetzen, Daten zurücksichern. Vielleicht funktioniert das ja zusammen mit der angebotenen Konfigurationssicherung, so daß man nicht alles komplett neu machen muss.

Openmediavault als Memberserver in einer ADS-Domain

Wie man einen OMV in einer ADS-Domäne betreibt

Der Openmediavault (https://www.openmediavault.org) ist ein gelungenes System für einen Selbstbau-NAS. Auf beliebiger PC-Hardware lässt sich ein auch für Laien installierbares und verwaltbares Debian-Linux mit ansprechender und funktioneller webbasierter Administrationsoberfläche bauen. Und es gibt sogar ein ZFS-Plugin, sodaß man auch die Vorzüge dieses Dateisystems nutzen kann.

Leider ist die Anbindung an eine Active-Directory-Domäne nicht über die Weboberfläche zu machen. Dabei ist gerade diese Funktion für die Verwendung im betrieblichen Umfeld nicht ganz uninteressant. Daher lege ich hier mal dar, wie man das schnell und schmerzlos unter Zuhilfenahme der Kommandozeile hinbekommt.

Es gibt wohl Leute, die das nach dieser Anleitung gemacht haben: https://forum.openmediavault.org/index.php?thread/23465-guide-to-omv-4-active-directory-integration/ . Leider habe ich bisher mit dem sssd bisher nur Ärger gehabt. Ich werde also den “traditionellen” Weg mit Winbind vorstellen, der bei mir seit Jahren problemlos läuft.

Fehlende Softwarepakete

zunächst benötigt man noch ein paar Softwarepakete:

apt install libnss-winbind libpam-winbind winbind libpam-krb5 krb5-user smbclient

login.defs

In /etc/login.defs passen wir die Werte für UID_MAX und GID_MAX an:

UID_MAX   6000000
GID_MAX   6000000

Die UIDs und GIDs der Domänenbenutzer werden > der standardsmäßigen 60000 liegen. Um die in OMV sichtbar zu machen, müssen diese Werte hier angepasst werden.

Anpassungen für Samba

Die Einstellungen für Samba müssen im Webinterface unter Dienste->SMB/SIFS vorgenommen werden. Wenn man die in die smb.conf direkt einträgt, werden sie bei der nächsten Konfigurationsänderung überschrieben:

password server = *
realm = <IHRE DOMAIN>
security = ads
allow trusted domains = no
        idmap config * : backend = autorid
        idmap config * : range = 10001-2000000

winbind use default domain = true
winbind offline logon = true
winbind enum users = yes
winbind enum groups = yes
winbind separator = /
winbind nested groups = yes
;winbind normalize names = yes
winbind refresh tickets = yes
template shell = /bin/bash
template homedir = /export/home/%U
client ntlmv2 auth = yes
client use spnego = yes
follow symlinks = yes
wide links = yes
unix extensions = no

Der Domain beitreten

kinit <ADS-Admin>
net join -U<ADS-Admin>
systemctl restart smbd
systemctl restart nmbd
systemctl restart winbind

nsswitch.conf anpassen

in /etc/nsswitch.conf die Einträge für passwd und group anpassen:

passwd:         files winbind
group:          files winbind

ein getent passwd oder getent group sollte jetzt die Domänenbenutzer bzw. -gruppen anzeigen.

OMV neu starten

Damit die Änderungen auch in der GUI verfügbar werden, muss man den OMV-Rechner neu starten. Evtl. gibt’s noch eine andere Option. Die ist mir aber nicht bekannt.