Archiv ‘Linux’

Mittwoch, 11. September 2019

Die Absenderadresse inklusive Display Name eines mit Linux mail (bsd-mailx) gesendeten E-Mails festlegen

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

Sackgasse

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: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 14. April 2019

Coops geschwatziger Apache Sling

Entweder haben die Security-Kollegen bei Coop keine Härtungsrichtlinie für Apache erstellt, oder forcieren diese nicht für alle Server. Ich kann mir nicht vorstellen, dass es für ein irgendein derart exponiertes Unternehmen sinnvoll ist, derart viele Information über den verwendeten Web-Server und dessen Module preiszugeben:

image-8351

Ob How to Hide Apache Version Number and Other Sensitive Info auch auf Apache Sling anwendbar ist, weiss ich nicht — aber dieses Reporting sollte sich auch bei dem Server mit einer Konfigurationszeile abschalten lassen.

(Screenshot erstellt im Juni 2018; Antwort auf die Übermittlung eines Teilnahmeformulars für einen Mondovino-Wettbewerb)

Tags: , , , , , , ,
Labels: Linux, Web

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. März 2019

pip: pkgcairo: Fehlende Debian-Pakete

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.

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. März 2019

pip: pycurl: Could not run curl-config: [Errno 2] No such file or directory

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

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. März 2019

pip: pygobject: Failed building wheel for pygobject

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

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. März 2019

Alle mit pip installierten Pakete aktualisieren

Leider gibt es beim Python-Paketmanager pip („Pip installs Packages“) keine Routine à la apt-get update && apt-get upgrade, um alle installierten Pakete zu aktualisieren.

Mit folgendem Befehl kommt man aber verdammt nah an diese Funktionalität dran:

# pip install -U $(pip freeze | awk '{split($0, a, "=="); print a[1]}')

Quelle: update all installed python packages with pip

Das habe ich gestern auf einem System gemacht, musste aber leider feststellen, dass pip selbst auf einem relative „einfachen“ System bei bestimmten Paketen ins Straucheln gerät. Es ist also viel Zeit und Handarbeit nötig, um sicher zu sein, dass alle Pakete aktualisiert wurden.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 16. Oktober 2018

USB-Kabel ist nicht gleich USB-Kabel, oder: Wieso ein Raspberry Pi 3 einen gelben Blitz anzeigt

Von meinem Dashboard, meinem ganzen Stolz über all die Jahre, habe ich hier ja bereits mehrere Male berichtet (Ausgangspunkt).

Seit Juni 2016 verwende ich zum Betrieb des Dashboards einen Raspberry Pi 3 — und wahrscheinlich genau so lange hat das Ding mir auf dem Bildschirm einen gelben Blitz angezeigt:

image-8066

Bis letzte Woche hatte ich keinen blassen Schimmer, was dieses Symbol zu bedeuten hat — nerven tat es auf jeden Fall. Doch dann stolperte ich auf Grund folgender Fehlermeldung im Debian Kernel Log (unter /var/log/kern.log) …

...
Oct  9 05:00:06 DASHBOARD kernel: [    2.116304] Under-voltage detected! (0x00050005)
Oct 10 05:00:08 DASHBOARD kernel: [    2.089827] Under-voltage detected! (0x00050005)
Oct 11 05:00:07 DASHBOARD kernel: [    2.080389] Under-voltage detected! (0x00050005)
Oct 11 05:17:06 DASHBOARD kernel: [    2.080005] Under-voltage detected! (0x00050005)
Oct 11 05:17:04 DASHBOARD kernel: [    2.071669] Under-voltage detected! (0x00050005)
Oct 11 05:17:04 DASHBOARD kernel: [    2.089371] Under-voltage detected! (0x00050005)
...

… über folgenden Artikel:

If a lightning bolt image appears in the top-right corner of the screen, it means Raspberry Pi is not getting enough voltage (4.65V according to this forum post).

Quelle: Lightning Bolt (Under-Voltage Warning) on Raspberry Pi

All die Jahre erschien dieses Symbol, aber ich realisierte nicht, dass mir mein RPi3 etwas Wichtiges damit sagen wollte!

Ich hätte das Problem wie im Artikel beschrieben mit der Quick-and-Dirty-Symptombekämpfungslösung wegmachen können (avoid_warnings=1-Eintrag in /boot/config.txt), doch ich war an der tatsächlichen Lösung des Problems interessiert: Mehr Volt für meinen RPi!

Der Raspberry Pi hängt seit 2014 an einem AOC E2460SHU Monitor, für welchen der Hersteller mit einem roten und einem Power-Schriftzug markierten USB-Anschluss wirbt (Direktlink auf das Bild). Daran konnte es doch nun kaum liegen?!

Zu Beginn der Recherche machte ich den Fehler, dass ich nach Lösungen für zu wenig Ampere (Strom) über den USB-Bus suchte. Dabei stiess ich auf folgendes Kabel („Dual Input USB Power“) und war kurz davor, es zu bestellen — bis ich mir noch einmal die Fehlermeldung zu Gemüte rief. Dort liest man nichts von „under-current“, sondern von „under-voltage“, das heisst zu tiefer Spannung!

Nach wenigen Minuten stiess ich auf unzählige Forumsbeiträge zum Thema; einen Interessanten hier:

Stutzig wurde ich, als in mehreren anderen Forenbeiträgen empfohlen wurde, nicht zuerst die Stromquelle selber als Problem zu vermuten, sondern auch das verwendete USB-Kabel genauer anzuschauen und gegebenenfalls auszuwechseln. Begleitet wurden diese Empfehlungen von Rückmeldungen vieler Benutzer, die rein mit dem Austausch des Kabels die Meldung weggebracht hatten.

Doch wieso ist das so? Folgende zwei Artikel geben Auskunft über das Phänomen:

In vielen Fällen rührt das Problem davon, dass man keine qualitativ hochstehenden USB-Kabel verwendet (ja, ich weiss, vergoldete HDMI-Kabel für 99 CHF …). Das heisst anstelle von explizit „Charging Cable“ genannten Waren nur „Data Cables“. Das Problem der qualitativ minderwertigen Kabel ist, dass sie einen zu kleinen Querschnitt und somit einen zu hohen Widerstand haben. Dies führt dazu, dass die 5V Betriebsspannung am USB-Anschluss (der Stromquelle) bis zum RPi problemlos um 0.25V bis über 0.5V abnehmen kann — und somit wie oben genannt weniger als 4.65V beim Raspberry Pi ankommen (Grafik).

Kann wirklich das USB A-auf-USB Mikro-Kabel das Problem sein?! Offenbar schon, wenn man folgenden Artikel in einem RPi-Forum durchliest: Best Micro USB cables

Ein gutes Kabel erkennt man, wenn es einen Aufdruck mit einem numerisch tiefen AWG-Wert enthält.

Zurück von der Arbeit durchsuchte ich meinen USB Mikro ZIP-Lock-Sack. Rasch musste ich feststellen, dass kaum (mehr) Kabel einen AWG-Wert angeben. Einige wenige Kabel hatten einen Aufdruck, und ich machte mich daran, das bis heute genutzte USB-Kabel des RPi auszutauschen.

  1. Das erste Kabel war fälschlicherweise ein USB A- auf USB Mini-Kabel (statt Micro). Dabei wäre es perfekt gewesen: 28AWG/1P+24AWG/2C plus zusätzlich ein Ferritkern an einem Ende.
  2. Das zweite Kabel mit 26AWG/1P 26AWG/2C wäre brauchbar gewesen, doch leider scheint es defekt zu sein — der RPi3 tat keinen Wank, weshalb ich auf Kabelbruch tippte.
  3. Das dritte Kabel funktionierte schlussendlich. Es ist sehr, sehr kurz und trägt den Schriftzug 28AWG/1P and 28AWG/2C. Zuerst befürchtete ich, dass dies bereits ein zu hoher AWG-Wert ist — doch der gelbe Blitz ist seither nicht mehr sichtbar.

Kabel Nummer 1:

image-8067

Kabel Nummer 2:

image-8068

Kabel Nummer 3:

image-8069

Nachtrag 1

Ich muss noch bemerken, dass ich das Kabel seit langem nicht mehr direkt in den USB-Port des Monitors einstecke, sondern noch ein USB-Winkelstück (90 Grad; männlich, weiblich) gekauft habe, damit das Kabelende nicht so hässlich am oberen Ende des Monitors heraussticht. Ein solches Stück kann selbstverständlich auch noch zu Spannungsverlusten führen; in meinem Fall ist der Verlust zusammen mit einem qualitativ hochstehenden Kabel aber offenbar vernachlässigbar.

Nachtrag 2

Leider sind die Kernel-Meldungen nicht ganz weg. Seit Austausch des Kabels habe ich in kern.log folgende Einträge gefunden:

...
Oct 16 19:18:55 DASHBOARD kernel: [  370.259369] Under-voltage detected! (0x00050005)
Oct 16 19:20:06 DASHBOARD kernel: [  440.980952] Under-voltage detected! (0x00050005)
Oct 16 20:31:53 DASHBOARD kernel: [ 4748.658891] Under-voltage detected! (0x00070005)
Oct 16 20:38:41 DASHBOARD kernel: [ 5156.348023] Under-voltage detected! (0x00050005)
Oct 16 20:49:53 DASHBOARD kernel: [ 5828.208492] Under-voltage detected! (0x00070005)
Oct 16 20:53:00 DASHBOARD kernel: [ 6015.403857] Under-voltage detected! (0x00070007)
...

Tags: , , , , , , , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 9. September 2018

Zwischenstand abfragen bei „Elasticsearch is still initializing the kibana index“

In meinem Netzwerk läuft eine ElasticSearch-, Lucene- und Kibana- oder kurz ELK-Komponente, an welche alle Geräte im Netzwerk per syslog ihre Log-Events zusenden. Gelegentlich muss ich den ELK-Docker-Container herunter- und wieder hochfahren. Da ich ELK auf einem Laptop laufen lassen und die CPU-Frequenz des Geräts auf den tiefstmöglichen Wert für diese CPU festgelegt habe (1200 MHz; Überhitzung führte vorher zu unregelmässigen Abstürzen), kann es manchmal eine Weile dauern, bis ELK nach einem solchen Neustart wieder hochkommt. Doch bis es soweit ist, strahlt einem dieses Kibana Status-Fenster entgegen:

image-8034

Wenn man sich dafür interessiert, wie weit der Kibana-Index bereits wiederhergestellt ist, ruft folgende URL auf:

http://1.2.3.4:9200/_cluster/health?pretty=true

Im Browser sieht man dort dann nützliche Informationen über den Cluster, und für unseren Fall ganz wichtig, das Attribut active_shards_percent_as_number:

{
  "cluster_name" : "elasticsearch",
  "status" : "red",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 1753,
  "active_shards" : 1753,
  "relocating_shards" : 0,
  "initializing_shards" : 4,
  "unassigned_shards" : 4035,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 10,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 807617,
  "active_shards_percent_as_number" : 30.265883977900554
}

Im Browser kann man nun regelmässig diese Seite neu laden und sollte sehen, wie active_shards_percent_as_number kontinuierlich nach oben zählt. Sobald 100 Prozent erreicht sind, läuft der Cluster wieder wie erwartet.

Wer nur eine Kommandozeile zur Verfügung hat, hilft sich folgendermassen:

$ watch -n 1 curl -XGET 'http://1.2.3.4:9200/_cluster/health?pretty=true'

Quelle: Monitor ElasticSearch cluster health – Useful for keeping an eye on ES when rebalancing takes place

Tags: , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 4. August 2018

logrotate meldet „mysqladmin: connect to server at ‚localhost‘ failed“

/etc/cron.daily/logrotate:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'
error: error running shared postrotate script for '/var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-slow.log /var/log/mysql/error.log '
run-parts: /etc/cron.daily/logrotate exited with return code 1

Hat man das root-Passwort angepasst (sprich: es ist nicht mehr leer, wie standardmässig vorgegeben), muss man das Passwort in der Datei /etc/mysql/debian.cnf ergänzen.

Die dort erfassten Parameter werden vom logrotate-Script unter /etc/logrotate.d/mysql-server eingelesen und zum Zugriff verwendet.

Quelle: MySQL logrotate error

Tags: ,
Labels: Linux

2 Kommentare | neuen Kommentar verfassen

Sonntag, 8. Juli 2018

OpenVPN meldet „INSECURE cipher with block size less than 128 bit (64 bit).“

Zwar erscheint die folgende Fehlermeldung seit längerem in den Logs meiner Site-to-Site-VPNs, doch heute erst hatte ich die Zeit, mich dem Problem anzunehmen:

Sun Jul  8 09:24:37 2018 Outgoing Static Key Encryption: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jul  8 09:24:37 2018 WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).

Zuerst dachte ich, dass ich die statischen Schlüssel der VPN-Verbindungen neu erstellen muss, weshalb ich zuerst einmal das Script optimierte. Falsch gedacht! Obwohl ich die Schlüssel ersetzt hatte, erschien beim erneuten Verbindungsaufbau erneut dieselbe Fehlermeldung.

Nach etwas Googlen dann die effektive Lösung: Ich muss die Konfigurationsdateien der jeweiligen Verbindungen anpassen! Folgende Zeile habe ich nun in die OpenVPN-Konfigurationsdateien auf beiden Seiten eingefügt:

...
cipher      AES-256-CBC
...

Et voilà! Auf der Seite des Servers sehe ich nun in der Log-Datei:

Sun Jul  8 10:47:17 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Sun Jul  8 10:47:17 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Sun Jul  8 10:47:17 2018 Outgoing Static Key Encryption: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Jul  8 10:47:17 2018 Outgoing Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jul  8 10:47:17 2018 Incoming Static Key Encryption: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Jul  8 10:47:17 2018 Incoming Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
...

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen