Archiv ‘Linux’

Montag, 5. April 2021

Mit upower den Batteriestatus von Linux-Laptops überwachen und aufzeichnen

upower ist ein sehr nützliches Kommandozeilen-Tool, wenn man sich für den Batteriestatus seiner Linux-Laptops interessiert (Linux-Server meiner Wahl: Lenovo Thinkpads).

Ich verwende es auf zwei Arten (Anleitung zum Schnellstart):

  • Alarm wenn auf Batteriebetrieb geschaltet wird Ein cron-Script schreibt den Status der Batterie alle fünf Minuten in eine Datei. Die Datei wird von monit überwacht. Wenn das Gerät (1) auf Batteriebetrieb schaltet (wegen Stromausfall, oder weil das Stromkabel ausgezogen wurde) und (2) die Ladung der Batterie unter einen vordefinierten Grenzwert sinkt (aktuell: weniger als 80 Prozent), erhalte ich von monit regelmässig eine Meldung per Email. In einem Fall konnte ich so aus der Ferne zuschauen wie die Batterieladung kontinuierlich abnahm, bis dass Gerät offline ging.
  • Aufzeichnung mit cacti Die von upower ausgegebenen Vitaldaten speise ich in cacti ein, um den Verlauf der Vitaldaten darstellen zu können. Was ich derzeit aufzeichne: Verbleibende Maximalkapazität der Batterie in Prozent der Design Capacity, Ladung Batterie in Prozent, Ladung der Batterie in Wh, Ausgangsspannung, Ausgangsleistung („Draw“).

Problem

Der Parameter energy-rate (Dokumentation) …

Amount of energy being drained from the source, measured in W. If positive, the source is being discharged, if negative it’s being charged.

… enthält bei einigen Laptops plausible Werte …

...
# OPENVPN 1
energy-rate:         4.761 W
...
# OPENVPN 2
energy-rate:         3.298 W
...
# ELK (Elasticsearch Lucene Kibana)
energy-rate:         21.288 W
...

… bei anderen Laptops nicht:

...
# Web-Server
energy-rate:         0.00409639 W
...

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 2. April 2021

APT meldet für packages.cloud.google.com NO_PUBKEY

...
Err:10 http://packages.cloud.google.com/apt cloud-sdk-stretch InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 8B57C5C2836F4BEB NO_PUBKEY FEEA9169307EA071
...

Die Lösung:

# curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

Quelle: NO_PUBKEY error in google cloud debian packages update

ACHTUNG:

  • Auf eigene Gefahr: Man sollte Ausgaben mit curl nie an lokale Kommandos pipen …
  • Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 1. April 2021

Das nervende „You have mail.“ beim SSH-Login loswerden

Gestern habe ich auf allen meinen Linux-Systemen /etc/motd geleert, um bei SSH-Logins kein grosses Login-Banner mehr angezeigt zu bekommen.

Jetzt aber ist mir auf verschiedenen Systemen die folgende Zeile markanter ins Auge gestochen:

Linux GRIFFINDOR 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1 (2020-01-20) x86_64
You have mail.
Last login: Thu Apr  1 15:13:36 2021 from 10.1.2.3

Wie wird man diesen Hinweis los? Ganz einfach:

  1. $ mail
  2. d1-%Anzahl Emails in INBOX%
  3. q

Quelle: Safely get rid of “You have new mail in /var/mail” on a Mac?

Der Befehl d1-100 weist mail an, die ersten hundert Emails zu löschen. q bedeutet „quit“.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 25. März 2021

Supports Wake-on: pumbg

Kürzlich habe ich nachgeschaut, welche meiner Lenovo ThinkPad Linux-Server Wake-on-LAN (WOL) aktiviert haben.

Dies überprüft man mittels des folgenden Kommandos:

# ethtool eth0
...
        MDI-X: on (auto)
	Supports Wake-on: pumbg
	Wake-on: g
        Current message level: 0x00000007 (7)
...

Doch was bedeutet pumbg?

p   Wake on PHY activity
u   Wake on unicast messages
m   Wake on multicast messages
b   Wake on broadcast messages
a   Wake on ARP
g   Wake on MagicPacket™
s   Enable SecureOn™ password for MagicPacket™
d   Disable (wake on nothing). This option clears all previous options.

Quelle: Wake on LAN unter Linux

Schön. Jetzt muss ich nur noch überprüfen, ob die Laptops auch wirklich hochfahren, wenn ich ihnen im ausgeschalteten Zustand ein WOL-Paket sende.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 12. Februar 2021

Mit apt-get auf eine bestimmte Paket-Version downgraden

Gestern habe ich ohne lange zu Überlegen Kibana auf meinem ELK-Server gelüpft. Schlechte Idee:

{"type":"log","@timestamp":"2021-02-11T23:20:13+01:00","tags":["error","savedobjects-service"],"pid":501,"message":"This version of Kibana (v7.11.0) is incompatible with the following Elasticsearch nodes in your cluster: v7.10.0 @ 10.1.2.3:9200 (10.1.2.3)"}

Abbruch, zurückbuchstabieren — aber wie?

Zuerst überprüft man, was die letzte funktionierende vorherige Version war:

$ apt-cache madison kibana
    kibana |     7.11.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |     7.10.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |     7.10.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |     7.10.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.9.3 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.9.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.9.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.9.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.8.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.8.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.7.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.7.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.6.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.6.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.6.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.5.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.5.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.5.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.4.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.4.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.4.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.3.2 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.3.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.3.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.2.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.2.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.1.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.1.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.0.1 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages
    kibana |      7.0.0 | https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages

Somit muss ich versuchen, 7.10.2 über 7.11.0 zu installieren. Doch wie macht man das?

# apt-get install kibana=7.10.2

Und damit beim nächsten Lauf Kibana 7.11.0 nicht erneut installiert wird, benötigt man noch einen Eintrag in /etc/apt/preferences:

...
Package: kibana
Pin: version 7.10.2
Pin-Priority: 1001

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

Keine Kommentare | neuen Kommentar verfassen

Freitag, 29. Januar 2021

Welcher Linux-Prozess schreibt am meisten Daten auf die Festplatte?

Ganz einfach, dafür installiert man sich unter Debian GNU/Linux am Besten das Tool iotop:

# apt-get install iotop

Sofort habe ich das soeben installierte Tool gestartet, wurde aus der sich ständig wechselnden Ausgabe aber nicht schlau.

Nach einigen Recherchen im Netz fand ich dann die Startparameter, um die (jedenfalls von mir) gesuchte Diagnose-Funktionalität herbeizuzaubern:

# iotop --accumulated --only --processes
  • --accumulated Summiere alle Lese- und Schreibaktivitäten eines Prozess fortlaufend
  • --only Zeige nur Prozesse, welche auch tatsächlich von der Festplatte lesen oder auf sie schreiben
  • --processes Führe nur Prozesse auf, nicht aber Threads

Nachgelesen unter man iotop.

Anschliessend hilft es vermutlich, mittels Cursor rechts resp. Cursor links diejenige Spalte auszuwählen, nach welcher man die Ausgabe sortieren möchte. Für meinen Anwendungszweck war das natürlich die Spalte DISK WRITE. Die ausgewählte Spalte erkennt man an der Fettschrift sowie dem rechtsstehenden Grösser als.

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

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 3. Dezember 2020

PHPs session_start() meldet „Permission denied (13)“

Ein kürzlich live gegangenes Web-Projekt, welches bei Hostpoint gehostet wird, füllt mir das PHP Error Log mit folgendem Müll:

...
[03-Dec-2020 13:32:32 Europe/Zurich] PHP Notice:  session_start() [function.session-start.php]: ps_files_cleanup_dir: opendir(/var/cache/php-sessions) failed: Permission denied (13) in /home/tenant/file.php on line 14
...

Die Lösung liegt darin, in der Datei .user.ini im Web-Root des Projekts mit dem Parameter session.save_path zu ergänzen und diesen Eintrag auf ein Verzeichnis im eigenen Tenant zeigen zu lassen. Ich empfehle, das Verzeichnis nur für den Besitzer les- und schreibbar zu machen, d.h. auf linuxisch chmod 700 anzuwenden, damit die Berechtigungsmaske drwx------ lautet.

...
[PHP]
error_reporting = E_ALL
display_errors = Off
error_log = /home/tenant/var/log/domain.php.err
session.save_path = /home/tenant/tmp

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

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 1. Dezember 2020

Mehrere Unix Timestamps auf der macOS Kommandozeile in Daten umwandeln

Voraussetzung: MacPorts und das Utility gdate (unter Linux: date) (Teil des Pakets coreutils) sind installiert.

$ python -mjson.tool < netatmo.json | grep utc | cut -d ":" -f 2 | awk '{print $1}' | xargs -I '{}' gdate -d "@{}"
Mon Nov 30 22:28:06 CET 2020
Mon Nov 30 22:27:57 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:27:38 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 17:07:34 CET 2020
Mon Nov 30 17:07:21 CET 2020
Mon Nov 30 17:07:21 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:46 CET 2020
Mon Nov 30 22:07:42 CET 2020
Mon Nov 30 22:07:00 CET 2020
Mon Nov 30 22:07:07 CET 2020

Im vorliegenden Fall nahm mich Wunder, wann meine Netatmo-Sensoren das letzte Mal einen Wert an den Server übertragen hatten.

Mindestens zwei Stationen mit einer handvoll Sensoren haben den Wert seit gestern nicht mehr aktualisiert. Ich vermute auf Grund dieses Absturzes.

Hierzu lud ich über die Netatmo API das JSON mit den Daten aller meiner Stationen herunter, gab das JSON schön formatiert aus (ein Key-Value Pair pro Zeile), selektierte die Zeilen mit dem Attribut time_utc, isolierte deren Wert — die Unix Timestamp (ein Integer), entfernte die Leerzeichen vor und nach dem Wert und übergab die Liste der Werte mittels xargs dem Tool gdate zur Umwandlung in ein menschenlesbares Datum.

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

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 16. September 2020

Debian: Repository changed its ‚Codename‘ value

Heute verweigerte apt-get seinen Dienst:

# apt-get upgrade
...
Reading package lists... Done                                                                            
E: Repository 'https://dl.ubnt.com/unifi/debian stable InRelease' changed its 'Codename' value from 'unifi-5.14' to 'unifi-6.0'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

Das Problem löst man, in dem man vor apt-get upgrade folgenden Befehl ausführt:

# apt-get update --allow-releaseinfo-change

Quelle: APT codename change from unifi-5.5 to unifi-5.6 errors

Tags: , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 7. Mai 2020

monit Prozesscheck ohne PID-Datei

Wieder einmal ein Beitrag zu einem meiner Linux-Lieblingstools: monit.

Wenn man einen Prozess überwachen will, der keine PID-Datei schreibt (welche die Process ID enthält), hilft monit auch hier weiter:

check process homebridge matching "homebridge"
    start program = "/usr/local/bin/homebridge/start.sh"
    stop program = "/usr/bin/pkill -f homebridge"

Läuft auf dem System ein Prozess, der „homebridge“ enthält, ist monit zufrieden. Ansonsten wird das Start-Script ausgeführt.

Das Beste: Im zu suchenden String kann man auch reguläre Ausdrücke unterbringen. Leider funktionierte aber folgende Zeichenfolge nicht:

"^homebridge$"

Auch die leicht vereinfachte Version führte zu andauernden Neustarts des Prozess, obwohl er bereits lief (d.h. monit konnte keinen laufenden Prozess finden, der auf den folgenden Ausdruck passte):

"homebridge$"

Schlussendlich half mir eine Antwort auf superuser auf den richtigen Pfad. Um interaktiv zu überprüfen, ob und wie viele Prozesse erkannt werden, loggt man sich auf das Linux-System ein und verwendet dann folgenden Befehl, um den regulären Ausdruck zu testen:

$ monit procmatch "homebridge$"

0 Prozesse. Herrje! Dabei müsste das doch anschlagen:

$ ps ax | grep -i homebridge
12345 pts/1    S+     0:00 grep --colour=auto -i homebridge
98765 ?        Sl     1:25 homebridge
43210 ?        Sl     0:13 homebridge-config-ui-x

Schlussendlich brachte ich den Check folgendermassen zum Laufen:

check process homebridge matching "homebridge\s*$"

Aus irgendeinem Grund scheint der Prozessname von einem Leerzeichen, Tabulator oder dergleichen gefolgt zu werden.

Nebenbemerkung: Wieso ich überhaupt einen regulären Ausdruck verwende? Weil ich manchmal zu Debuggingzwecken auf den Linux-Server einlogge und folgendes Kommando ausführe:

$ tail -f /var/log/homebridge.log

Wenn man monit nun die Prozesse nach „homebridge“ durchsuchen lässt, wird tail von monit als homebridge-Prozess erkannt, und das abgestürzte Homebridge eben nicht neu gestartet, solange der Befehl läuft.

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen