Unter Linux verwendet man folgenden Befehl:
$ grep --color='auto' -P -n "[^\x00-\x7F]" dump.txt
Quelle: How do I grep for all non-ASCII characters?
macOS‘ grep unterstütz dies leider nicht.
Sonntag, 8. März 2020
Unter Linux verwendet man folgenden Befehl:
$ grep --color='auto' -P -n "[^\x00-\x7F]" dump.txt
Quelle: How do I grep for all non-ASCII characters?
macOS‘ grep unterstütz dies leider nicht.
Samstag, 7. März 2020
Kürzlich fiel eine in einem ELK-System verwendete Magnetfestplatte aus. Ich ersetzte diese mit einer SSD, die hier seit einiger Zeit unbenutzt herumlag. Ergattert hatte ich diese bei einer Geschäftsauflösung in Kalifornien, wo sie ungefähr fünf Jahre in einem Schrank am Verstauben war.
Bevor ich die Festplatte formatierte, nahm mich der alte Inhalt darauf wunder. Die Platte wurde in einem Windows-System betrieben und war mit dem Microsoft NTFS Dateisystem formatiert.
Eine solche Festplatte mountet man folgendermassen unter Linux:
# apt-get install ntfs-3g # mkdir /mnt/ntfs # mount -t ntfs-3g /dev/sda1 /mnt/ntfs
Fazit: Nicht viel spannendes, vor allem dutzende ISO-Dateien von völlig veralteten Windows-Installationsmedien und Linux-Distributionen.
Mittwoch, 11. September 2019
Im Grunde ganz simpel, wenn man den richtigen Befehl kennt:
echo "Test" | mail -a "From: Displayname <sender@server.tld>" -s "Subject" recipient@server.tld
Beim Verfassen dieses Blog-Posts fragte ich mich zudem spontan, mit welchem Debian-Paket das Executable /usr/bin/mail installiert wird. Bei dem Executable handelt es sich auf meinen Servern um einen Symlink auf /etc/alternatives/mail. Dieser Symlink ist wiederum ein Symlink auf /usr/bin/bsd-mailx. Somit stammt das Executable vom Debian-Paket bsd-mailx:
$ dpkg --list | grep mailx ii bsd-mailx 8.1.2-0.20180807cvs-1 amd64 simple mail user agent
Nur über Umwege zum Erfolg führte folgende Suchfunktion: Nachdem ich apt-files gemäss der Anleitung How To Find The Package That Provides A File (Installed Or Not) On Ubuntu, Debian Or Linux Mint installiert und die Datenbank einmalig gefüllt hatte, waren das die Resultate des Tools:
$ apt-file search /usr/bin/mail | grep mail$ python-twisted-core: /usr/bin/mailmail
Nicht was ich gesucht habe.
$ apt-file search /etc/alternatives/mail
Komisch. Ich habe diesen Symlink auf jeden Fall nicht eingerichtet; das muss doch von einem Debian-Paket gekommen sein?
$ apt-file search /usr/bin/bsd-mailx bsd-mailx: /usr/bin/bsd-mailx
Jetzt aber!
Tags: apt-files, bsd-mailx, Display Name, Email, From, Linux, Mail
Labels: Linux
Montag, 23. Oktober 2017
Unsere Wohnung ist (fast) eine DVD/CD-ROM-freie Zone. All unsere Endgeräte verfügen mittlerweile über kein optisches Laufwerk mehr.
Doch was nun, wenn man eine CD erhält, deren Daten man auf die Endgeräte laden möchte?
Man nimmt den herumliegenden Lenovo T400 zur Hilfe, welcher noch über ein CD-ROM-Laufwerk verfügt. Leider fehlt der guten Maschine die Festplatte, weil der auf AliExpress.com gekaufte Festplatten-Käfig sowie die Plasticschienen derzeit gerade aus China unterwegs in die Schweiz sind.
Damit man auf der Kiste also ein Linux zum Laufen kriegt, bootet man von einem USB-Stick, auf welchen die Netinst-Version von Debian 9.0 kopiert wurde. (tftp Netzwerk-Boot wäre noch ein Todo für die langen Winternächte).
Nach ein paar Kapriolen, um das Boot-Laufwerk auf USB umzubiegen, startet der Laptop mit der graphischen Installationsoberfläche. Dort wählt man unter Advanced Options den Rescue Modus ein (ohne graphische Benutzeroberfläche).
Nach viel zu vielen Dialogfenster hat man endlich eine Shell zur Hand. Sobald man die CD eingelegt hat, gibt man folgende Befehl ein:
# mkdir /mnt/cdrom # mount /dev/cdrom /mnt/cdrom
Unter /mnt/cdrom sieht man mit ls -l den Inhalt der CD.
Hat man den zweiten USB-Stick, auf welchen die Daten der CD kopiert werden sollen, bereits bei der Anzeige des Debian-Menus eingestöpselt, könnte man dem Rescue-System in einem Dialog-Fenster sagen, diesen Stick ebenfalls bereits zu mounten.
Hat man dies nicht gemacht, sucht man sich zuerst einen weiteren freien USB-Port am Gerät und steckt den USB-Stick ein.
Anschliessend sucht man sich mit fdisk -l den Devicenamen sowie den Namen der Partition hervor. Gleichzeitig sieht man auch, ob der Stick mit FAT16/32 formatiert ist — ich konnte in meinem Versuch nur solche Sticks mounten.
In unserem Fall trägt die Partition des USB-Sticks den Pfad /dev/sdb1, deshalb mountet man den Stick so:
# mkdir /mnt/usb2 # mount /dev/sdb1 /mnt/usb2
Anschliessend wechselt man auf das CD-Laufwerk und verwendet — leider, da rsync in dieser Umgebung fehlt — folgenden Befehl, um die Daten auf den USB-Stick zu kopieren:
# cd /mnt/cdrom # cp -R . /mnt/usb2
Doch OBACHT — nur weil der Kopierbefehl abgeschlossen ist, heisst das leider noch nicht, dass alle Daten bereits auf den USB-Stick geschrieben wurden:
USB write: delay between when Ubuntu says its done and it actually being done
Bevor man den USB-Stick ausstöpselt, muss man mit folgendem Befehl sicherstellen, dass auch wirklich restlos alle Daten auf den Stick geschrieben wurden:
# sync
Danach werkelt sync, was locker noch einmal ein oder zwei Minuten dauern kann.
Anschliessend kann man den Stick mit folgendem Befehl für die Entfernung bereitmachen:
# umount /mnt/usb2
Sobald dieser Befehl ausgeführt wurde, kann man den Stick aus dem USB-Port entfernen und auf einem Endgerät einstöpseln.
Tags: CD, CD-ROM, Debian, Drive, DVD, DVD-ROM, eject, fdisk, kopieren, Laufwerk, Linux, mount, Rescue, Sync, umount, USB
Labels: Linux
Samstag, 14. Oktober 2017
Heute habe ich einen meiner Lenovo-„Server“ ausgetauscht: T400 raus, T420 rein. Dabei habe ich die SSD vom alten Server in den neuen Server eingebaut — bei Windows ein Ding der Unmöglichkeit, bei Linux: Läuft bei mir (fast).
Leider gab es ein gravierendes Problem, was die Downtime etwas verlängert und an meinem Ehrgeiz gekratzt hat: Die Netzwerk-Interfaces kamen nicht hoch, weshalb das Gerät ohne Intra- und Internet-Verbindung dastand.
Dank Laptop-Tastatur und -Bildschirm fiel immerhin das Debugging leicht.
Die Ausgabe von ifconfig zeigte, dass nur das Loopback-Interface vorhanden war. Was zum Teufel? Den Ethernet-Netzwerkanschluss sah ich mit meinen eigenen Augen vor mir, ein Kabel war eingesteckt und er blinkte auch fröhlich vor sich hin.
# ifconfig lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1 (Local Loopback) RX packets 184819 bytes 33744666 (32.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 184819 bytes 33744666 (32.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Mit dem Befehl ip a dann die Gewissheit, dass die erwarteten Schnittstellen auch tatsächlich da waren:
# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff inet 10.10.10.10/24 brd 10.10.10.255 scope global enp1s0 valid_lft forever preferred_lft forever 3: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
Wie sich herausstellte, hiess auf dem T420 die Netzwerkschnittstelle nicht wie erwartet und üblich eth0, sondern enp1s0.
Der Grund (bitte nicht lachen): Predictable Network Interface Names. Verursacht durch die Datei /etc/udev/rules.d/70-persistent-net.rules, welche bei der Installation auf dem T400 erstellt worden war. Linux fand die darin definierten Interfaces auf dem T420 nicht mehr.
Die Lösung des Problems fand sich in einem Benutzerforum zum Thema How to rename network interface in 15.10?.
An der Originaldatei …
... SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="11:11:11:11:11:11", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" ...
… nahm ich folgende Anpassung vor:
... SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:00:00:00:00:00", NAME="eth0" ...
Wichtig: 11:11:11:11:11:11 ist die MAC-Adresse des Ethernet-Interfaces auf dem T400, 00:00:00:00:00:00 ist die MAC-Adresse des Ethernet-Interfaces auf dem T420. Als ich zuerst nur die MAC-Adresse geändert habe, kam die Netzwerkschnittstelle nicht hoch. Erst die Verschlankung des Eintrags auf die obige Form funktionierte: Nach dem nächsten Reboot war eth0 wieder vorhanden und alle Netzwerkdienste kamen hoch.
Tags: Debian, enp1s0, eth0, Festplatte, Hard Drive, Linux, Migration, udev, udevd
Labels: Linux
Samstag, 14. Oktober 2017
Bei mir im Haushalt habe ich beides stehen:
Einen Raspberry Pi 3, der auf einem 22 Zoll-Bildschirm neben der Wohnungstüre hochkant ein Dashboard mit Zeitzonen, Abfahrten von Trams und Bussen, Temperaturen von Netatmo und Sense Peanut-Sensoren, Wetterprognosen, Twitter-Meldungen, Aktienkurse und Umrechnungskurse anzeigt (vor Jahren inspiriert durch einen Besuch bei Cyon in Basel).
Der Raspberry Pi ist (vermeintlich) günstig, benötigt aber ein Gehäuse und flinke SD-Karten. Immerhin läuft er mit dem Strom eines USB-Ports eines Bildschirms und hat mittlerweile Bluetooth und WLAN direkt eingebaut. Trotzdem ein Gefrickel, was die Installation und Konfiguration angeht. Mit nicht immer zeitnahem Software-Support. Wehe, wenn ein Software-Update fehlschlägt oder eine Fehlkonfiguration ausgerollt wird — viel Spass, die SD-Karte unter macOS zu mounten, die Konfigurationsdateien anzupassen, neu zu booten und das Spiel von vorne zu wiederholen, bis man den wirklich Schuldigen gefunden hat (der DAU an der Tastatur, meistens). Ausserdem ist die Hardware sehr schwachbrünstig (Chrome im Fullscreen lässt ihn fast austicken) und eignet sich nicht für jeden Einsatzzweck.
Andererseits einen Intel NUC, welcher primär Netzwerkaufgaben übernimmt: OpenVPN, DHCP, DNS und UniFi-Controller.
Performance-mässig nichts auszusetzen, aber auf Grund der Dimensionen nicht wartungsfreundlich. Und teuer, weshalb meistens Overkill für Standardaufgaben im heimischen Haushalt.
Mein Tipp: Wer die perfekte Hardware für einen Linux-Server sucht, halte nach älteren, gebrauchten Lenovo-Laptops Ausschau. Auf dem Gebrauchtmarkt kriegt man die Modelle X200, X201 und X220 (12 Zoll-Monitor) sowie T400 und T420 (14 Zoll-Monitor) zwischen 50 und 250 CHF.
Wieso ich auf diese Dinger schwöre?
Tags: Debian, Intel, Laptop, Lenovo, Linux, NUC, Raspberry Pi, T400, T420, X200, X220
Labels: IT, Shopping
Samstag, 5. Dezember 2015
Vor 11 Jahren musste ich mir beim Umstieg meiner IT-Infrastruktur auf Mac OS X auch einen neuen Drucker leisten, welcher Postscript sprach (die Treiberunterstützung für dieses Betriebssystem war damals noch nicht so ausgeprägt wie heute). Ich entschied mich für einen HP LaserJet 1300.
Bis vor einigen Tagen verrichtete dieser im Elternhaus mehr oder wenig zuverlässig seinen Dienst. Doch nun will er nicht mehr drucken und blinkt mit dem LED unten links orange vor sich hin.
Mangels eines LCD-Displays muss der herbeigerufene IT-Supporter auf das Handbuch zurückgreifen, wo er erfährt:
Klappe geöffnet, keine Medien geladen, keine Druckpatrone oder Medienstau
Der Drucker befindet sich in einem Fehlerzustand, der den Eingriff durch den Benutzer erforderlich macht.
Quelle: HP LaserJet 1150 and 1300 Series User Manual
Leider halfen die Empfehlungen des Handbuchs nicht weiter.
Als letzter Ausweg machte ich mich auf die Suche nach einem Linux-basierten Tool, mit welchem man über die USB-Schnittstelle den Status des Geräts auslesen kann. Ich erhoffte mir davon weiterführende Informationen, die mit einem aus drei LEDs bestehenden Bedienfeld nicht an den Benutzer zurückmelden kann.
HP hat zur Administration seiner Drucker unter Linux das hplip-Treiberpaket entwickelt, welches auch unter Debian verfügbar ist:
# apt-get install hplip
Als erstes machte ich den Drucker auf dem USB-Bus ausfindig:
$ lsusb Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 003: ID abcd:0001 Unknown Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 015: ID 03f0:1017 Hewlett-Packard LaserJet 1300 Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Der Drucker ist somit an Bus 3 angeschlossen und das 15. Gerät an dem Bus (?). Die eindeutige USB-ID des Peripheriegeräts lautet 03f0:1017.
Mittels des Tools hp-makeuri fand ich die Device URI heraus, mit welcher man angeblich mit Tools des hplip-Pakets HP-Drucker ansprechen kann:
$ hp-makeuri 001:015 HP Linux Imaging and Printing System (ver. 3.14.6) Device URI Creation Utility ver. 5.0 Copyright (c) 2001-13 Hewlett-Packard Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. CUPS URI: hp:/usb/hp_LaserJet_1300?serial=000000000000 Done.
Unter cups erfasste ich den Drucker mit der neuen hp:/-Schnittstelle ein zweites Mal.
Anschliessend entdeckte ich das Tool hp-info, das „Device Information Utility“ (unter root, lieber Gott vergebe mir):
# hp-info -i -dhp:/usb/hp_LaserJet_1300?serial=000000000000 warning: hp-info should not be run as root/superuser. HP Linux Imaging and Printing System (ver. 3.14.6) Device Information Utility ver. 5.2 Copyright (c) 2001-13 Hewlett-Packard Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. hp:/usb/hp_LaserJet_1300?serial=000000000000 Device Parameters (dynamic data): Parameter Value(s) ---------------------------- ---------------------------------------------------------- agent1-ack False agent1-desc Black toner cartridge agent1-dvc 0 agent1-health 1 agent1-health-desc Not installed agent1-hp-ink False agent1-id 0 agent1-kind 4 agent1-known False agent1-level 100 agent1-level-trigger 0 agent1-sku Q2613A/Q2613X agent1-type 1 agent1-virgin False back-end hp cups-printers ['LaserdruckerHP'] cups-uri hp:/usb/hp_LaserJet_1300?serial=000000000000 dev-file device-state 1 device-uri hp:/usb/hp_LaserJet_1300?serial=000000000000 deviceid MFG:Hewlett-Packard;CMD:PJL,MLC,BIDI-ECP,PCL,POSTSCRIPT,PC LXL;MDL:hp LaserJet 1300;CLS:PRINTER;DES:Hewlett-Packard LaserJet 1300;MEM:72MB;COMMENT:RES=10x1;1; duplexer 1 error-state 102 host in-tray1 1 in-tray2 1 is-hp True media-path 1 panel 0 panel-line1 panel-line2 photo-tray 0 port 1 r 0 revision 254 rg 000 rr 000000 rs 000000000 serial 000000000000 status-code 1805 status-desc No toner supply-door 1 top-door 4 Model Parameters (static data): Parameter Value(s) ---------------------------- ---------------------------------------------------------- align-type 0 clean-type 0 color-cal-type 0 copy-type 0 embedded-server-type 0 fax-type 0 fw-download False icon hp_LaserJet_1200.png io-mfp-mode 6 io-mode 1 io-support 6 job-storage 0 linefeed-cal-type 0 model hp_LaserJet_1300 model-ui HP LaserJet 1300 model1 HP LaserJet 1300 Printer model2 HP LaserJet 1300t Printer monitor-type 0 panel-check-type 1 pcard-type 0 plugin 0 plugin-reason 0 power-settings 0 pq-diag-type 0 r-type 0 r0-agent1-kind 4 r0-agent1-sku Q2613A/Q2613X r0-agent1-type 1 scan-src 0 scan-type 0 status-battery-check 0 status-dynamic-counters 0 status-type 9 support-released True support-subtype 14214 support-type 2 support-ver 0.9.5 tech-class ['LJMono', 'Postscript'] tech-subclass ['Normal'] tech-type 3 usb-pid 4119 usb-vid 1008 wifi-config 0 Done.
Die wichtigsten Infos waren in folgenden Zeilen enthalten:
error-state 102 status-code 1805 status-desc No toner
Am Tag bevor ich diesen Blog-Artikel abfasste hiess es noch:
error-state 101 status-code 1806 status-desc Service request
Wie dem auch sei, eine Lösung für das Problem habe ich immer noch nicht gefunden. Ich habe aber nun entschieden, das Gerät in den Ruhestand zu senden und stattdessen einen HP LaserJet Pro M426fdw zu bestellen.
Tags: Debian, HP LaserJet 1300, hp-info, hplip, IT-Support, Linux, USB
Labels: IT
Sonntag, 16. August 2015
… scheint mit quelloffener Software auf der Kommandozeile nicht — oder nur unter grösserem Aufwand — möglich zu sein: MacPorts hat dieses Paket nicht im Angebot (Nachtrag: Homebrew hingegen schon).
Ich bin deshalb auf meinen Linux-Server ausgewichen:
# apt-get install apt-get install libgxps-utils
Anschliessend konnte ich die XPS-Datei mit folgendem Befehl umwandeln:
$ xpstopdf datei.xps
Tags: apt, Debian, libgxps, Linux, Mac OS X, PDF, XPS, xpstopdf
Labels: Linux
Donnerstag, 5. März 2015
In den letzten Tagen kam es knüppelhart: Zuerst meldeten die PHP-Entwickler eine Sicherheitslücke in der unserialize()-Funktion (CVE-2015-0273), tags darauf mussten die Leute hinter Samba ein schwerwiegendes Problem in ihrer Software anerkennen (CVE-2015-0240).
Wie gehe ich sicher, dass auf meinem Debian-Server zu Hause Pakete installiert sind, in welchen diese Sicherheitsprobleme bereits behoben wurden?Nach einer kurzen Google-Suche fand ich die Antwort:
Im Debian Security Tracker kann ich nachschauen, welche Pakete von welchen „Common Vulnerabilities and Exposure“ betroffen sind. In den beiden erwähnten Fällen lauten die URLs auf die Detailseite folgendermassen:
Die dort angegebenen Versionsnummern kann ich anschliessend auf meinem Server mittels folgendem Befehl überprüfen:
$ dpkg --list | grep php ... ii php5 5.6.5+dfsg-2 all server-side, HTML-embedded scripting language (metapackage) ...
5.6.5+dfsg-2 ist immer noch anfällig auf das Problem, da die Sicherheitslücke offenbar erst mit 5.6.6+dfsg-2 behoben ist. Nebenbei: Mehr zum Kürzel „dfsg“.
Deshalb führe ich folgenden Befehl aus:
# apt-get upgrade php5 ... Calculating upgrade... php5 is already the newest version. ...
Offenbar muss ich mich also noch ein wenig in Geduld üben.
Bei Samba schaut es folgendermassen aus:
$ dpkg --list | grep samba ... ii samba 2:4.1.17+dfsg-1 i386 SMB/CIFS file, print, and login server for Unix ...
4.1.17+dfsg-1 wird auf der Web-Site als „fixed“ geführt. Glück gehabt!
Donnerstag, 7. November 2013
Welcher Linux-Benutzer kann unter Windows schon auf nützliche Kommandozeilen-Tools wie cat, cut, sed, awk, tr und Konsorten verzichten? Das Complete package, except sources der CoreUtils for Windows rüstet unter Windows die gängigsten Linux-Kommandos nach.
Damit Windows nach der Installation die Linux-Befehle aber auch wirklich findet, muss der Pfad zu den ausführbaren Dateien in die Windows-Umgebungsvariable PATH aufgenommen werden. Dies geschieht folgendermassen:
An den String fügt man den Pfad C:\Program Files (x86)\GnuWin32\bin; (Windows 7 mit 64-bit CPU) respektive C:\Program Files\GnuWin32\bin; an.
Sobald man nun die Windows-Kommandozeile öffnet, hat man die ganze Palette an Befehlen zur Hand …
Dieses muss man als eigenständiges Installationspaket von derselben Web-Site herunterladen und installieren:
Tags: awk, Bash, cat, Core Utils, cut, grep, Linux, sed, tr, Windows
Labels: IT