Sonntag, 10. März 2019
Damit pip das Paket pkgcairo installieren kann, müssen auf dem Debian-System folgende Pakete installiert sein:
# apt-get install libcairo2 libcairo2-dev libjpeg-dev libgif-dev python-cairo
Leider halfen diese Pakete auf meinem System auch nicht viel, denn:
... running build_ext pycairo: new API error: pycairo >= 1.11.1 required, 1.8.8 found.
Sonntag, 10. März 2019
Damit pip das Paket pycurl installieren kann, müssen auf dem Debian-System folgende Pakete installiert sein:
# apt-get install libcurl4-openssl-dev libssl-dev
Quelle: “Could not run curl-config: [Errno 2] No such file or directory” when installing pycurl
Sonst liest man folgende Fehlermeldungen:
...
Collecting pycurl
Downloading https://files.pythonhosted.org/packages/e8/e4/0dbb8735407189f00b33d84122b9be52c790c7c3b25286826f4e1bdb7bde/pycurl-7.43.0.2.tar.gz (214kB)
100% |████████████████████████████████| 215kB 15.2MB/s
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/pip-install-dv_5N3/pycurl/setup.py", line 913, in <module>
ext = get_extension(sys.argv, split_extension_source=split_extension_source)
File "/tmp/pip-install-dv_5N3/pycurl/setup.py", line 582, in get_extension
ext_config = ExtensionConfiguration(argv)
File "/tmp/pip-install-dv_5N3/pycurl/setup.py", line 99, in __init__
self.configure()
File "/tmp/pip-install-dv_5N3/pycurl/setup.py", line 227, in configure_unix
raise ConfigurationError(msg)
__main__.ConfigurationError: Could not run curl-config: [Errno 2] No such file or directory
Sonntag, 10. März 2019
Damit pip das Paket pygobject installieren kann, müssen auf dem Debian-System folgende Pakete installiert sein:
# apt-get install libglib2.0-dev libgirepository1.0-dev
Sonst liest man folgende Fehlermeldungen:
...
running build_ext
Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glib-2.0' found
Command '('pkg-config', '--print-errors', '--exists', 'glib-2.0 >= 2.38.0')' returned non-zero exit status 1
Try installing it with: 'sudo apt install libglib2.0-dev'
----------------------------------------
Failed building wheel for pygobject
Running setup.py clean for pygobject
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
Mittwoch, 31. August 2016
Da es sich dabei um teilweise Copyright-geschützte Werke handelt, stehen sie über die normalen Debian-Repositories nicht zur Verfügung. Nachfolgend ist erklärt, wie man diese trotzdem installiert.
Hier fügt man die non-free-Pakete hinzu:
... deb http://debian.ethz.ch/debian/ testing main non-free ... deb http://debian.ethz.ch/debian/ stable main non-free ...
Danach aktualisiert man das Paketverzeichnis:
# apt-get update
Jetzt findet Debian das Paket snmp-mibs-downloader:
# apt-get install snmp-mibs-downloader
Sobald das Paket installiert ist, muss man das Bash-Script ausführen, welches unter /usr/bin/download-mibs liegt:
# download-mibs
Die (von mir nicht berührten) Konfigurationsdateien des Tools liegen unter /etc/snmp-mibs-downloader.
Das Script lädt allerlei MIBs herunter, deponiert diese zeitweile in /tmp und kopiert sie dann in das Verzeichnis /var/lib/mibs.
Interessanterweise finden sich gemäss einer E-Mail-Konversation auch unter /usr/share/snmp/mibs/ weitere MIBs. Ich denke aber, dass snmpwalk diese ignoriert.
Damit snmpwalk diese MIBs nun auch wirklich interpretiert, muss noch die Konfigurationsdatei angepasst, das heisst konkret die Zeile mibs : auskommentiert werden:
# As the snmp packages come without MIB files due to license reasons, loading # of MIBs is disabled by default. If you added the MIBs you can reenable # loading them by commenting out the following line. #mibs :
Quelle: SNMP Clients — Command line client applications
Um zu sehen, ob man richtig liegt, führt man am Besten den folgenden Testbefehl aus (vorausgesetzt, auf dem Server lauscht auch ein snmpd):
$ snmpwalk -c s1kr1t -v 1 localhost hrStorageTable HOST-RESOURCES-MIB::hrStorageIndex.1 = INTEGER: 1 ...
Auf einem System, welche diese MIBs nicht installiert hat, erhält man stattdessen folgende Fehlermeldung:
$ $ snmpwalk -c s1kr1t -v 1 localhost hrStorageTable hrStorageTable: Unknown Object Identifier (Sub-id not found: (top) -> hrStorageTable)
Probiert man es mit der OID, klappt es — logischerweise:
$ snmpwalk -c s1kr1t -v 1 localhost .1.3.6.1.2.1.25.2.3 iso.3.6.1.2.1.25.2.3.1.1.1 = INTEGER: 1 ...
Samstag, 27. August 2016
Seit einigen Woche betreibe ich mein heimisches Dashboard auf einem Raspberry Pi 3 und bin von der Performance begeistert! Sogar Chrome kriegt man nun als Installationspaket mitgeliefert.
Leider zeigte Chrome nach der Standardinstallation chinesische Schriftzeichen (bei den Währungsinfos) nicht an. Folgende Pakete rüsten chinesische Schriftzeichen nach:
# apt-get install fonts-arphic-bkai00mp fonts-arphic-bsmi00lp fonts-arphic-gbsn00lp
Quelle: Chinese Debian Mini Howto — 2. Installing Chinese Fonts
Tags: China, Chinesische Schriftzeichen, Chrome, Debian, Font, Fonts, Raspberry Pi, Schrift, Schriften, TrueType, TTF, Ubuntu
Labels: Linux
Samstag, 27. August 2016
Ein kürzlich erfolgtes Update des SNMPd-Pakets auf meinem Debian-Server hatte zur Folge, dass meine monit-Installation den Service fälschlicherweise als offline meldete.
Dies, weil monit nach der PID-Datei des SNMP-Daemons Ausschau hält, um dessen Prozess-ID auszulesen und auf Existenz zu prüfen. Bei Debian liegt diese Datei unter /var/run/snmpd.pid.
Folgendermassen re-aktivierte ich die PID-Datei:
Vor der Anpassung …
... ExecStart=/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f ...
… und nach der Anpassung:
... ExecStart=/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f -p /var/run/snmpd.pid ...
Anschliessend folgte noch ein Neustart des Daemons:
# systemctl stop snmpd Warning: snmpd.service changed on disk. Run 'systemctl daemon-reload' to reload units. # systemctl daemon-reload # systemctl stop snmpd # systemctl start snmpd
Und prompt meldete mir monit, dass der Service wieder online sei.
Mario Aeby, geboren am 25. September 1980 in Bern, Schweiz
Ein Weblog über IT, Apple Macintosh, mein (mittlerweile) abgeschlossenes Geschichtsstudium, meine Arbeit als Berater, IT-Auditor und Web-Developer, die Schweiz, den Kanton Bern, die Gemeinde Neuenegg, das Älter werden und zu Guter letzt auch über lokale, regionale und globale Politik.
| RSS |  Abonnieren |
| SubToMe |