Archiv ‘Linux’

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

Montag, 27. April 2020

Debian-Pakete melden bei der Installation ‚unknown option „–skip-systemd-native“‚

Ich betreibe hier noch mehrere Debian Stretch-Instanzen, installiere aber gelegentlich bereits (aktuellere) Buster-Pakete mit folgendem Befehl: apt-get install -t testing %PAKET%

Gestern erschien ein Update eines meiner Lieblingstools, monit. Doch bei der Installation passierte folgendes

...
invoke-rc.d: syntax error: unknown option "--skip-systemd-native"
dpkg: error processing package monit (--configure):
 subprocess installed post-installation script returned error exit status 1
...

Was nun? Heute fand ich die Lösung nach einer kurzen Recherche. Das Problem behebt man (unter Debian Stretch) folgendermassen:

# apt-get install -t testing init-system-helpers

Ab sofort kennt invoke-rc.d nun das Flag --skip-systemd-native. Die Lösung fand ich in folgendem Beitrag, zu welchem ich über ein Github-Issue rüberstolperte:

[…] init-system-helpers >= 1.54 which supports the required option.

Bis dahin war unter Debian Stretch nur init-system-helpers 1.48 vorhanden. Jetzt läuft apt-get wieder durch.

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

Keine Kommentare | neuen Kommentar verfassen

Montag, 13. April 2020

Bildschirm eines Debian-Servers nach Inaktivität ausschalten

Ich habe hier bereits erwähnt, dass gebrauchte ThinkPads mit Debian die Linux-Server meiner Wahl sind.

Gestern habe ich meinen ELK Log-Server von einem Lenovo ThinkPad X201 auf ein Lenovo ThinkPad T440p migriert (und habe gleichzeitig von einem unsäglichen Docker-Gefrickel auf native Pakete gewechselt).

Eines der bis eben ungelösten Probleme war, dass sich der Bildschirm des ThinkPads nach einer Inaktivitäts-Zeitlimite nicht automatisch ausschaltete. Das habe ich nun folgendermassen gelöst:

/etc/default/grub

...
GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=60"
...

Der Wert 60 drückt die Inaktivitätszeit in Sekunden aus.

Danach muss noch GRUB aktualisiert werden, und dann wird’s ab dem nächsten Neustart nach 60 Sekunden dunkel:

# update-grub

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 8. März 2020

Unter Linux Nicht-ASCII-Charakter in einer Datei ausgeben

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.

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 7. März 2020

Festplatte mit NTFS-Partition unter Linux mounten

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.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen