Software

FTP-Uploads per Shell-Script

Schreibe einen Kommentar

Ab und an komme auch ich nicht drumrum mit Zielen zu arbeiten, welche keine SSH/SFTP-Verbindung zulassen, sondern nur per FTP(S) erreichbar sind. Grade beim Automatisieren über Shell-Scripte ist das reichlich unschön. Ein praktischer Client ist in diesem Fall das Urgestein ncftp. Mit dessen Tools lässt sich z.B. schnell ein ein entferntes Verzeichnis löschen und durch die lokale Kopie ersetzen:

echo 'rm foo/bar/*
rm foo/baz/*
rmdir foo/bar
rmdir foo/baz
' | ncftp -u $USER -p $PASS $HOST

ncftpput -R -u $USER -p $PASS $HOST /foo/* ~/dev/foo/*
Software

Windows Shutdown per Linux

Schreibe einen Kommentar

Ab und an möchte man entfernte Rechner mal runterfahren. Mit Linux-Zielen ist das per ssh üblicherweise kein Problem, möchte man jedoch von einem Linux-PC den Shutdown-Befehl an einen Windows-Rechner geben muss man schon einmal suchen. Abhilfe schafft wie üblich Samba, welches den „net“-Befehl mitbringt. Ein Shutdown sieht dann wie folgt aus:

net rpc SHUTDOWN -C "Grund für den Shutdown" -f -I 127.0.0.1 -U username%password
Software

CUPS/foomatic/gutenprint: „Unable to get list of printer drivers: Success“

Schreibe einen Kommentar

Eigenlich bin ich ja Verfechter papierloser Abläufe, leider sind viele Behörden damit nicht einverstanden oder schreiben sinnloserweise selbstgestrickte Vorgaben statt offener Standards vor. Zum Glück stehen hier noch ein paar Drucker aus den 80ern und 90ern rum, die nicht nach 10 Seiten das Zeitliche segnen. Also: Drucker raus, Papier rein. Error. Bei der Installation des Druckers auf meinen PCs – genauer der Suche nach möglichen Treibern – meldete CUPS teilweise folgende, sehr aussagekräftige, Fehlermeldung:

Unable to get list of printer drivers: Success

Auffällig dabei: Ein Perl-Script bezüglich Foomatic belagert zuvor einen CPU-Kern. Auch konnte ich bei einem System beobachten, dass der Fehler erst nach Installation zusätzlicher Treiber (foomatic-db & Co) auftrat, mit „leerer“ Treiber-Liste jedoch nicht. Der Fehler ist konstant, also sowohl in der Desktop-GUI als auch im CUPS-Webinterface reproduzierbar.

tl;dr: Don’t do gutenprint…

Schauen wir mal genauer auf den 100%-Prozess: Dieser wird vom Nutzer „daemon“ gestartet und hat kein nice-Level. Der genaue Aufruf lautet

/usr/bin/perl /usr/lib/cups/driver/foomatic list

Das Script selbst lässt sich auch auf der Konsole manuell starten. „list“ gibt hierbei nicht wirklich etwas – auch nach mehreren Minuten keine Ausgabe. „help“ am Ende zeigt die möglichen Optionen:

foomatic -A
foomatic -P
foomatic -p [-d ] [-w]
foomatic list
foomatic cat [-w]
foomatic -h

-A : show all Printer ID’s and compatible drivers
-P : show all Printer ID’s whose names and model
matched by the RE. For example:
-P HP will match all names with HP in them
-p : Printer ID
-d : Driver name
If the driver is not specified then the default driver
for the is used.
list : List all possible PPDs in the format needed by the
cups-driverd
cat : Generate PPD file appropriate to the .
Available CUPS PPD URIs are listed by
„foomatic list“.
-w : Generate PPD which is compatible with the CUPS PostScript
driver for Windows (GUI strings are limited to 39
characters).
-h : show help information

Leider scheint es – jedenfalls laut Hilfe – keinen verbose- oder debug-Modus zu geben. Strace to the rescue. Zu sehen nicht viel – die Treiber-Dateien werden nacheinander geladen, die letzten Zeilen lauten:

stat(„/usr/share/foomatic/db/source/driver/xes.xml“, {st_mode=S_IFREG|0644, st_size=522, …}) = 0
stat(„/usr/share/foomatic/db/source/driver/xes.xml“, {st_mode=S_IFREG|0644, st_size=522, …}) = 0
stat(„/usr/share/foomatic/db/source/driver/xes.xml“, {st_mode=S_IFREG|0644, st_size=522, …}) = 0
open(„/usr/share/foomatic/db/source/driver/xes.xml“, O_RDONLY) = 3
lseek(3, 0, SEEK_CUR) = 0
read(3, „\n

Dummerweise ist „xes.xml“ auch die alphabetisch letzte Datei, also eher kein Fehler darin zu vermuten. Narf. Nunja – räumen wir mal auf. Unter /usr/share/foomatic/db/source müssen die Dateien unter PPD, driver, opt und printer weichen. Success. Kind of. Der Foomatic-Prozess endet ohne Fehler, also muss einer der Treiber der Übeltäter sein. Als erstes wandert opt wieder zurück, hier ist nicht viel drin. Noch alles OK. Auch das zurückkopieren von PPD zeigt keine Änderung. Printer klingt interessanter, daher spiele ich hier jede Datei einzel zurück:

for i in * ;do mv $i ../printer && echo $i && (/usr/bin/perl /usr/lib/cups/driver/foomatic list || exit) ; done

Dauert zu lange – ich entscheide mich nur die XML-Dateien der für mich interessanten Hersteller zu nutzen. Läuft noch. Es folgt Drivers. Weniger dateien, trotzdem manuell. Erster Kandidat: necp6 – ein Treiber für meinen Nadeldrucker. Passt – foomatic list liefert nun eine Liste aller NEC-Nadeldrucker. Fehlt noch mein Laser. Da Gutenprint schnell sein soll kopiere ich deren XMLs – nichts geht mehr. Hört sich nach Verursacher an – kopieren wir alles außer Gutenprint: Passt. Auch in CUPS lässt sich nun der Drucker anlegen. Fehler Gefunden würde ich sagen…

Software

Backup Exec: Speicherplatzbedarf bändigen

Schreibe einen Kommentar

Symantec Backup Exec kennt seine Backups – leider für einige Fälle zu gut. Standardmäßig wird für jede Sicherung eine Liste der gesicherten Daten, also z.B. die Liste aller Dateien, im Katalog auf der Festplatte des Backupservers abgelegt. Wird das Zielmedium später überschrieben werden auch die Daten gelöscht – wer jedoch Langzeitsicherungen erstellt oder Sicherungsdatenträger aussortiert wird auf Dauer mit einem nicht unerheblichen Platzverbrauch konfrontiert. Mehrere hundert Gigabyte sind so schnell zusammen, welche üblicherweise unter %ProgramFiles%\Symantec\Backup Exec\Catalogs\*SERVERNAME* landen. Doch sind diese Daten wirklich noch notwendig? Ist es nicht auch akzeptabel bei Rücksicherungen, welche älter als einige Monate sind, einige Minuten länger zu warten und bei Bedarf den Katalog neu vom Zieldatenträger zu laden? Um hier Ordnung zu schaffen gibt es gleich drei Lösungen

1. Katalog verschieben

Wer noch an anderer Stelle genügend Platz hat und die Kataloge weiterhin im Direktzugriff haben möchte kann den Katalogordner an ein anderes Ziel verschieben. Die nötigen Infos sind unter TECH74582 zu finden – zwar für deutlich ältere Versionen, die Option sollte sich jedoch auch weiterhin in den Menüs verstecken.

2. Kataloglebensdauer einstellen

In den Optionen gibt es die Möglichkeit Dateilisten nach einer gewissen Zeitspanne zu verwerfen. Der zugehörige Artikel findet sich unter TECH7297 – die Option ist wie auch zuvor in den Menüs weiterhin zu finden. Leider greift die Option nur für neu angelegte Kataloge, ältere müssen ggf. manuell entfernt werden.

3. Manuelles löschen

Auch manuell lässt sich der Ordner aufräumen. Hierzu müssen erst alle Dienste des Backup Exec-Systems gestoppt werden. Im Anschluss löscht man alle *.fh und *.xml-Dateien im Katalogverzeichnis, welche älter als das gewünschte Datum sind. Andere Dateien sollen laut Symantec-Forum nicht gelöscht werden – zwar denke ich nicht, dass diese Aussage für Einträge mit gleichen UUIDs korrekt ist, da die übrigbleibenden Dateien jedoch nur wenige KB groß sind habe ich dies nicht weiter geprüft. Da nun Datenbank und Ordner inkonsistent sind ist ein Reinigungslauf notwendig, hierzu startet man im BE-Verzeichnis den Befehl „CatRebuildIndex.exe -r“ als Administrator. Dies kann einige Zeit in Anspruch nehmen.

Alles keine schönen Lösungen, aber irgendwann ist auch der größte Platz mal voll und Migrieren macht mit Windows keinen Spaß.

Software

Gluon: Build vox x86-Images schlägt fehl

Schreibe einen Kommentar

Seltsames Fehlerbild: Mit dem neuen Gluon-Release sind einige Hardwareplattformen hinzu gekommen, alle lassen sich Fehlerfrei bauen, nur die x86-basierten Images machen Probleme. Der Fehler ist im Debugmodus (make … V=s) schnell lokalisiert: Es wird versucht ein ext4-System zu konfigurieren, hierbei wird automatisch geprüft, ob das betroffene System irgendwo gemountet ist. In meinem Fall läuft der Build in einer chroot, da dort die mtab fehlt schlägt diese Prüfung und damit auch der Build fehl. 

/home/openwrt/gluon-trunk/upstream/build/x86-generic/openwrt/staging_dir/host/bin/tune2fs  -O extents,uninit_bg,dir_index /home/openwrt/gluon-trunk/upstream/build/x86-generic/profiles/GENERIC/kernel/root.ext4
tune2fs 1.42.8 (20-Jun-2013)
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /home/openwrt/gluon-trunk/upstream/build/x86-generic/profiles/GENERIC/kernel/root.ext4 is mounted.
Makefile:269: recipe for target 'install' failed

Da in der chroot /proc verfügbar ist lässt sich das Problem mit einem einfachen Symlink lösen:

ln -sf /proc/mounts /etc/mtab

…und schon läuft der Build wie erwartet.

Software

Fujitsu Scanner-Fehler mit Sane & aktuellen Kernel

Ein Kommentar

Dokumentenscanner von Fujitsu sind schnell und teuer – es sei denn die Windows-Unterstützung fällt weg. Ältere Modelle wie der fi-4120 laufen nur bis Windows XP zuverlässig, mit Windows 7/8/10 schaut man in die Röhre, vor allem wenn 64 Bit im Spiel sind. Kein Wunder, dass die ehemals fast 700€ teuren Geräte jetzt für gebraucht für wenig Geld zu finden sind. Unter Linux ist das ganze eigentlich recht entspannt: Die Geräte werden durch Sane unterstützt und sind entsprechend problemlos nutzbar. Ich selbst habe einen solchen schon länger an einem Raspi im Betrieb um Briefe & Co. zu digitalisieren.

Leider scheint das „Problemlos“ momentan eine Auszeit zu nehmen: Bei anderen Anwendern aus der hiesigen Linux User Group macht der Scanner in letzter Zeit Probleme: Nach dem Einschalten sieht alles OK aus, versucht man jedoch zu scannen erhält man einen „Error during device I/O“. Am OS sollte es nicht hängen – sowohl mein Raspi als auch der betroffene Rechner laufen mit Arch. Auch die „üblichen“ Tipps, namentlich „keine USB-Hubs“, trafen nicht zu.

Also: Debuggen. Während bei meinem Netbook und dem Raspi keine Fehler auftreten kann ich ihn mit Laptop und einem PC nachvollziehen. Erstere arbeiten mit ARM bzw. einer 32 Bit CPU und unterstützen nur USB 2.0, letztere sind 64 Bit mit USB 3.0. Zur Übersichtlichkeit habe ich erst mal alle Treiber außer Fujitsu aus /etc/sane/dll.conf entfernt. Den Debug-Modus für Sane und den Treiber aktiviert man mit folgenden Zeilen:

export SANE_DEBUG_DLL=255
export SANE_DEBUG_FUJITSU=35

Nach dem Einschalten taucht der Scanner wie üblich in lsusb auf. Auch sane-find-scanner kann die USB-ID erkennen. scanimage -L zeigt dem Scanner im ersten Durchlauf ebenfalls, führt man den selben Befehl jedoch erneut aus tauchen USB-Fehler auf. IO-Error, Invalid Argument, etc. Ausgerüstet mit den passenden Logs findet sich in den Quellen des Sane-Projektes ein passender Commit vom 16.12.2014, welcher einen Workarround für aktuelle Kernel-Images bereitstellt. Hier ist offenbar eine Regression, welche die Ansteuerung der Fujitsu-Scanner betrifft. Worth a try, also schnell mal das ältere sane-Paket deinstalliert und stattdessen sane-git aus AUR installiert. Siehe da: Läuft. Soweit ich erkenne betrifft der Fehler nur einige USB-Controller, was ggf. erklärt warum ich auf meinem Raspi keine Fehler finden konnte.

tl;dr: GIT ist manchmal doch funktionsfähiger als stable

BitNotice

BitNotice #92 – Dell Laptop KFZ-Adapter

Schreibe einen Kommentar
BitNotice #92 - Dell Laptop KFZ-Adapter

(37 MB) 00:06:21

2015-06-16 16:39 🛈

Lange hat mein Eigenbau-Netzteil nicht gehalten: Das Netzteil aus #145 musste aus Platzgründen in den Schrank – Temperaturtechnisch beim aktuellen Wetter keine gute Idee. Ergebnis: Der Vorrat an magischem Rauch war verbraucht und ich brauch ein neues Netzteil. Richten soll es erst mal der günstigste Modell des üblichen Auktionshauses, doch taugt es?

BitBastelei #145 – Dell Laptopnetzteil DRM

BitBastelei

BitBastelei #153 – Hausbus: Planung & Prototyp

Schreibe einen Kommentar
BitBastelei #153 - Hausbus: Planung & Prototyp

(32 MB) 00:20:58

2015-06-14 10:00 🛈

Auch wenn die Temperaturen nicht grade zum Basteln einladen: Etwas Fortschritt gibt es beim Hausbus. Wegen des geringen Preises und der einfachen Anpassbarkeit geht es erst mal auf Arduino-Basis. Da das Protokoll nicht sonderlich komplex ist lässt sich später immer noch auf ARM o.Ä. umstellen. Da die Shields für die angedachten Pro-Minis etwas überdimensioniert sind muss ein eigenes Mini-Shield her. IC-Technisch werde ich mich an iSysBus und den diversen Ardunio-Shields orientieren. Ein Breadboard-Test konnte bereits Steuerbefehle empfangen und senden. Passende PCBs sind inzwischen bestellt, die Schaltpläne und Boarddaten gibt es wenn der erste Prototyp grundsätzlich läuft.

BitBastelei

BitBastelei #152 – Nokia-Fehlersuche

Schreibe einen Kommentar
BitBastelei #152 - Nokia-Fehlersuche

(220 MB) 00:00:00

2015-06-07 10:00 🛈

Ja, auch die angeblich unkaputtbaren Nokia-Handys können Fehler haben – sagt man zumindest. Dieses Modell soll unter einer sehr kurzen Laufzeit leiden – und das trotz neuem Akku. mMal schauen, ob wir die Ursache finden.

BitBastelei

BitBastelei #151 – Sat-Multischalter 12V-Umbau

Schreibe einen Kommentar
BitBastelei #151 - Sat-Multischalter 12V-Umbau

(117 MB) 00:09:36

2015-05-31 10:00 🛈

Ein weiteres Gerät wandert an die 12V-Solaranlage: Der Sat-Multischalter wird zukünftig nicht mehr per 230V versorgt.

Nerd Inside