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.

Bluescreen beim Drucken nach Windows-Update 03/2021

Wieder mal ein ein Qualitätsupdate aud Hause Microsoft. Nach dem Update zum Patchday im März 2021 kommt es bei vielen Anwendern zu Systemabstürzen, beim Versuch Dokumente zu drucken. Auch der Start von LibreOffice führte an einigen Stellen zu Bluescreens. Microsoft hat den Fehler inzwischen als solchen anerkannt und wohl die Verteilung des Updates ausgesetzt. Als Lösung wird vorgeschlagen, das Update zu deinstallieren. Für Windows 10 (v2004):

wusa /uninstall /kb:KB5000802

Oder für Windows 10 (v20H2):

wusa /uninstall /kb:KB5000808

Diese Befehle setzt man in einer Eingabeaufforderung mit erhöhten Rechten („als Administrator ausführen“) ab. Alternativ kann man das natürlich auch in der Systemsteuerung deinstallieren. Das ist aber viel umständlicher.

Update:
Man sollte auch in jedem Fall die Installation von Updates generell in der Systemsteuerung aussetzen. Sonst bekommt man das räudige Update direkt wieder installiert. Das ist natürlich nur eine mittelgute Lösung, weil dann auch andere wichtige Updates nicht installiert werden. Gut, dass ich da nicht mit arbeiten muss.