Bash: Mehrfachaufrufe eines Skriptes sequentiell abarbeiten

Mittwoch, 28. Juli, 2021

Ich habe ein Shellskript. Dieses wird von mehreren Rechnern und auch von denen ggf. mehrfach aufgerufen.
Und nun möchte ich, dass viele dieser Aufrufe nicht parallel, sondern nacheinander ausgeführt werden - gern in der Reihenfolge des Aufrufs.

In diesem Fall war es ein Wrapper Skript [1], das mit Acme.sh [2] SSL Zertifikate via Let’s Encrypt [3] löst. Man kann ein Ansible [4] Skript parallelisieren: N Server möchten also gleichzeitig vielleicht dasselbe Zertifikat. Nur der erste Aufruf soll ein Zertifikat erstellen und die nachfolgenden Aufrufe, die “vielleicht” dasselbe Zertifikat bearbeitet haben wollen, sollen nicht ebenfalls das Zertifikat erstellen, sondern auf die Ausstellung des ersten Aufrufes warten und dann dessen erstellte Zertifikatsdateien verwenden.
Anm: Let’s Encrypt Live-Server blockieren nach zu vielen Aufrufen für dieselbe Domain für 1 Woche alle Zertifikats-Aktionen, was sehr unangenehm für ein produktives System “sein kann” - auch das möchte ich daher applikatorisch unterbinden.

Ein Queuing will ich nicht bauen oder Semaphoren nutzen. Alles zu kompliziert für diesen Zweck.

Mein Ansatz: die Prozessliste.

Ich baue zunächst eine Funktion - so rein für Wiederverwendungszwecke und/ oder für ein gesourctes Skript mit Funktionen. Aus der Prozessliste per ps -ef filtere ich alle Prozesse, die den Interpreter Bash enthalten und das Shellskript des eigenen Namens $0. Die Prozessliste wird nach der Spalte mit den PIDs numerisch sortiert. Das Filtern mit der Bash ist wichtig, dass nicht andere Prozesse mit demselben Shellskript - z.B. ein offener Editor, der das Skript gerade bearbeitet - versehentlich die echten Abrufe blockieren.

ps -ef | grep "bash.*$0" | grep -v "grep" | sort -k 2 -n

Wenn darin in der ersten Zeile …

[irgendein Kommando] | head -1

… die eigene Prozess ID $$ in der 2. Spalte steht, dann ist der gerade laufende Prozess derjenige mit der kleinsten PID und darf weiterlaufen.
Wenn nicht, gibt es ein sleep für ein paar Sekunden, bevor nochmals getestet wird.

Und so sieht die Funktion _wait_for_free_slot() dann aus:

showdebug=1

# "neverending" loop that waits until the current process is
# the one with lowest PID
function _wait_for_free_slot(){
    local _bWait=true
    typeset -i local _iFirstPID=0
    _wd "--- Need to wait until own process PID $$ is on top ... "
    while [ $_bWait = true ];
    do
        _iFirstPID=$( ps -ef | grep "bash.*$0" | grep -v "grep" | sort -k 2 -n | head -1 | awk '{ print $2}' )
        if [ $_iFirstPID -eq $$ ]; then
            _bWait=false
            _wd "OK. Go!"
        else
            _wd "- all instances"
            test ${showdebug} && ps -ef | grep "bash.*$0" | grep -v "grep" | sort -k 2 -n
            sleep 10
        fi
    done
}

# write debug output if showdebug is set to 1
function _wd(){
        test ${showdebug} && echo "DEBUG: $*"
}

Und dann baue ich in mein Skript jene Funktion _wait_for_free_slot ein - immer dort, wo ich eine sequentielle Ausführung wünsche. Wenn ich dasselbe Skript mit einem Parameter für die Hilfe-Ausgabe starte oder die Liste wartender Instanzen auflisten lasse, dann will ich eigentlich nicht auf die Abarbeitung aller vorherigen Instanzen warten. Naja, ihr seht vielleicht schon, worauf es hinausläuft. Bei jeder Aktion zum Erstellen, Erneuern oder Löschen eines Zertifikats wird die sequentielle Ausführung erzwungen, indem die Funktion _wait_for_free_slot in die erste Zeile geschrieben wird. Und bei den anderen Funktionalitäten lässt man den evtl. parallelisierten Aufruf zu.

#
# pulic function ADD certificate
# 
function add(){
	_wait_for_free_slot

	// actions follow here ...
}

weiterführende Links:

  1. IML certman Wrapper für Acme.sh mit DNS Authentication
  2. DOCs: os-docs.iml.unibe.ch/iml-certman/
  3. Acme.sh Let’ Encrypt Client als Bash Implementierung
  4. Let’s Encrypt Kostenlose SSL Zertifikate
  5. Ansible Automations Plattform

Manjaro update - pacman (6.0.0-1) breaks dependency ‘pacman<5.3′ required by package-query

Mittwoch, 14. Juli, 2021

Der grafische Software-Manager wollte pacman nicht aktualisieren … und wegen jenes Konflikts alle möglichen Pakete auch nicht.

Dann aktualisere ich halt “pamac upgrade pacman” von Hand und schaue, was passiert.

axel@mypc~> pamac upgrade pacman
(...)
   vulkan-intel                      21.1.4-1 
(21.1.2-1)                  extra      2.3 MB
   vulkan-radeon                     21.1.4-1 
(21.1.2-1)                  extra      1.7 MB
   wireless-regdb                    2021.04.21-1 
(2020.11.20-1)              core       10.3 kB
Wird installiert (10):
   syndication 5.84.0-1                                              
extra 1.0 MB
   electron12 12.0.14-1                                             
community 50.7 MB
   layer-shell-qt 5.22.3-1                                              
extra 23.1 kB
   ksystemstats 5.22.3-1                                              
extra 162.9 kB
   pahole 1.21-1                                                extra 
262.9 kB
   nodejs-nopt 5.0.0-2                                               
community 13.4 kB
   libpamac                          11.0.1-3 (Ersetzt: 
pamac-common)     extra      818.4 kB
   kio-fuse 5.0.1-1                                               extra 
70.3 kB
   fakeroot 1.25.3-2                                              core
   bison 3.7.6-1                                               core
Zu erstellen (2):
   package-query                     1.12-1 (1.10-1)                    AUR
   zoom                              5.7.1-1 (5.6.7-1)                   AUR
Wird entfernt (1):
   pamac-common                      10.0.6-2 (Konflikt mit: libpamac)

Download-Größe gesamt: 2.3 GB
Gesamtgröße installiert: 269.3 MB
Gesamtgröße entfernt: 9.5 MB

Build-Dateien bearbeiten : [e]
Transaktion durchführen ? [e/j/N] j

Warning: installing pacman (6.0.0-1) breaks dependency 'pacman<5.3' 
required by package-query
Add package-query to remove
Fehler: Failed to prepare transaction:
could not satisfy dependencies:
- removing package-query breaks dependency 'package-query>=1.9' required 
by yaourt,
- if possible, remove yaourt and retry

Leider nein.

Beim Lesen von “installing pacman (6.0.0-1) breaks dependency ‘pacman<5.3' " dachte ich schon fast: oh, ein Henne-Ei-Problem?

Die Lösung:

Ich bin einfach dem letzten Rat in der Ausgabe gefolgt und habe yaourt entfernt.

axel@mypc~ [1]> pamac remove yaourt
Vorbereitung...
Abhängigkeiten werden überprüft...

Wird entfernt (1):
   yaourt  1.9-2

Gesamtgröße entfernt: 849.9 kB

Transaktion durchführen ? [j/N] j
Removing yaourt (1.9-2)... [1/1]
Vorgang erfolgreich abgeschlossen.

Und nun nochmal der Versuch eines Updates …

axel@mypc~> pamac upgrade pacman
...

… hurra, nun klappt es!

weiterführende Links:

  1. manjaro.org (en)

Linux: Kommando unter einem anderen User starten

Donnerstag, 8. Juli, 2021

Um die Frage des Titels zu beantworten, kommt man schnell auf ein … als root startet man

su - [USERNAME] -c [KOMMANDO]

Und wenn der User, unter dem ich das Kommando starten will, keine Shell hat? Tja, dann kommt eine Fehlermeldung der Art

This account is currently not available.

Wirklich sehr lange habe ich mir beholfen, dass ich dem User in der /etc/passwd eine Shell gegeben habe - das /usr/bin/nologin oder /bin/false wurde durch ein /bin/bash o.ä. ersetzt. Jaja, ganz generell fördern man [Kommando] oder [Kommando] –help hilfreiche Dinge zutage. Aber das ist völlig unnötig. Der “Trick” ist, dass man bei su mit dem Parameter -s eine Shell vorgibt, z.B. die /bin/sh.

su - [USERNAME] -c [KOMMANDO] -s /bin/bash

Um die Parameter wegzulassen und optisch zu vereinfachen, kann man auch eine kleine Funktion in sein Skript setzen:

# run a command as another posix user (even if it does not have a shell)
#
# example:
# runas www-data "/some/where/mysript.sh"
#
# param  string  username
# param  string  command to execute. Needs to be quoted.
# param  string  optional: shell (default: /bin/sh)
function runas(){
    local _user=$1
    local _cmd=$2
    local _shell=$3
    test -z "$_shell" && _shell=/bin/sh

    su $_user -s $_shell -c "$_cmd"
}

Dann kann man im Skript etwas kürzer schreiben:

runas [USERNAME] [KOMMANDO]

weiterführende Links:

  1. man7.org: Manpage für su

Mysql Replikation neu aufsetzen als Bash Skript

Donnerstag, 24. Juni, 2021

Wenn eine bestehende Mysql Replikation nicht mehr funktioniert, so half mir etliche Male im Laufe der Berufszeit als Webmaster beim Schweizer Radio DRS / Sysadmin Daseins an der Uni Bern ein top-down-Skript weiter. Wenn gerade Stress ist und man in der Situation nicht erst alle Kommandos zur Wiederinbetriebnahme des Slave nachschlagen mag, dann ist ist man froh, wenn man ein Skript dafür parat liegen hat.

reinit_mysql_replication.sh

Es gibt keine Parameter.

Installation:

Man benötigt einen Mysql Client. Ich hatte daher die Skripte am Mysql-Slave unterhalb /root zu liegen. Daher ist die Verbindung zum Slave ohne Passwort (wird aus der /root/.my.cnf gelesen).
Es wird auch vom eigenen Rechner aus funktionieren, der die Mysql-Ports von Master und Slave erreichen kann. Es ist nur “einen Tick” langsamer (sprich: bei vielen und/ oder grossen Datenbanken > 1 GB Gesamtgrösse nicht zu empfehlen).

Konfiguration:

Die *dist Datei ist umzukopieren und die Hostnamen und Root-Passwörter für Master + Slave sind zu setzen.

Start:

Das Skript reinit_mysql_replication.sh führt der Reihe nach folgende Aktionen aus: es …

  • zeigt aktuellen Slave Status
  • wartet dann auf ein RETURN, bevor die Replikation neu aufgesetzt wird

Aktionen zum Neuaufsetzen der Replikation: das Skript …

  • liest die Position des Binlog am Master (per SQL “SHOW MASTER STATUS G;”)
  • sperrt den Master für Schreibaktionen (”FLUSH TABLES WITH READ LOCK;”)
  • holt aktuelle Datenbank-Dumps vom Master (mysqldump –all-databases –lock-all-tables …)
  • hebt Schreibsperre am Master auf (”UNLOCK TABLES;”)
  • stoppt den Slave (”STOP SLAVE G;”)
  • importiert Dumps des Master auf dem Slave (cat $dumpMaster | mysql $paramdbSlave)
  • setzt am Slave binfile und Position (”CHANGE MASTER TO MASTER_LOG_FILE = …” ; “CHANGE MASTER TO MASTER_LOG_POS = …”)
  • startet den Slave (”START SLAVE G;”)

weiterführende Links:

  1. git-repo.iml.unibe.ch: iml-open-source/mysql-slave-scripts

Manjaro: ttyrec installieren

Freitag, 30. April, 2021

Ttyrec ist ein Open Source Werkzeug, mit dem man auf der Konsole alle Eingaben “mitschneiden” kann. Damit lassen sich Demos zur Handhabe von Installationen anfertigen oder ASCII Animationen aufzeichnen. Zur Wiedergabe gibt es ein ttyplay - oder für Webseiten auch einen Video Player, um eigene Online Dokumentationen zu ergänzen.

BTW: von ttyrec gibt es noch Portierungen in anderen Programmiersprachen, wie Python, Go, …

Aber zurück zu Manjaro. Es gibt mehrere AUR Pakete, um ttyrec auf Manjaro Linux builden zu lassen. Der Compilervorgang schlug bei mir aber jeweils fehl, weil ein man Verzeichnis bereits existiert:

Fehler: Vorgang konnte nicht abgeschlossen werden:
In Konflikt stehende Dateien:
- ovh-ttyrec-git: /usr/local/share/man existiert bereits im Dateisystem (gehört zu filesystem)

Die Lösung klingt etwas zu einfach … aber immerhin funktioniert es: man schaut einmal, was in diesem Verzeichnis ist und benennt es temporär um, um es dann anschliessend nach der Complilierung wiederherzustellen.

Gesagt - getan … und mit einem Underscore umbenannt:

axel@tux > sudo -i
root@tux# ls -l /usr/local/share/man
lrwxrwxrwx 1 root root 6 20. Jan 17:33 /usr/local/share/man -> ../man
root@tux# mv /usr/local/share/man /usr/local/share/man_

Ja, dann installieren / compilieren wir das nochmal … und starten pamac install ovh-ttyrec-git

root@tux# pamac install ovh-ttyrec-git
Warnung: ovh-ttyrec-git ist nur im AUR verfügbar
Vorbereitung...
Klone ovh-ttyrec-git Build-Dateien...
Running as unit: run-u161595.service
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 309ms
Running as unit: run-u161597.service
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 9ms
Überprüfe ovh-ttyrec-git Abhängigkeiten...
Abhängigkeiten werden aufgelöst...
Interne Konflikte werden überprüft...

Zu erstellen (1):
   ovh-ttyrec-git  v1.1.6.3.r0.gb8bdaab-1    AUR

Build-Dateien bearbeiten : [e]
Transaktion durchführen ? [e/j/N] j

Erstelle ovh-ttyrec-git...
Running as unit: run-u161604.service
Press ^] three times within 1s to disconnect TTY.
==> Making package: ovh-ttyrec-git v1.1.6.7.r1.ga13ca74-1 (Di 13 Apr 2021 17:24:30)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
   -> Updating ovh-ttyrec git repo...
Fetching origin
==> Validating source files with sha256sums...
     ovh-ttyrec ... Skipped
==> Removing existing $srcdir/ directory...
==> Extracting sources...
   -> Creating working copy of ovh-ttyrec git repo...
Cloning into 'ovh-ttyrec'...
done.
Switched to a new branch 'makepkg'
==> Starting prepare()...
Looking for compiler... gcc
Checking if compiler can create executables... yes
Checking how to get pthread support... -pthread
Looking for libzstd... yes
Checking whether we can link zstd statically... no
Looking for isastream()... no
Looking for cfmakeraw()... yes
Looking for getpt()... yes
Looking for posix_openpt()... yes
Looking for grantpt()... yes
Looking for openpty()... yes (pty.h, libutil)
Checking for supported compiler options...
... OK -Wall
... OK -Wextra
... OK -pedantic
... OK -Wno-unused-result
... OK -Wbad-function-cast
... OK -Wmissing-declarations
... OK -Wmissing-prototypes
... OK -Wnested-externs
... OK -Wold-style-definition
... OK -Wstrict-prototypes
... OK -Wpointer-sign
... OK -Wmissing-parameter-type
... OK -Wold-style-declaration
... OK -Wl,--as-needed
... OK -Wno-unused-command-line-argument

You may run make now
==> Starting pkgver()...
==> Starting build()...

(...)

Vorgang erfolgreich abgeschlossen.

Das “erfolgreich abgeschlossen” klingt ja schonmal gut.

Jetzt muss ich nur noch das man Verzeichnis wiederherstellen. Durch das Complilieren entstand:

root@tux# ls -l /usr/local/share/man/man1/
insgesamt 12
-rw-r--r-- 1 root root  641 13. Apr 17:24 ttyplay.1.gz
-rw-r--r-- 1 root root 1751 13. Apr 17:24 ttyrec.1.gz
-rw-r--r-- 1 root root  308 13. Apr 17:24 ttytime.1.gz

In /usr/local/share/ sieht es nun so aus:

root@tux# ls -l
insgesamt 4
lrwxrwxrwx 1 root root    6 20. Jan 17:33 man -> ../man
drwxr-xr-x 3 root root 4096 13. Apr 17:24 man_ttyrec

Hier muss man nur das man_ttyrec/man1 in das man hineinschieben.

root@tux# mv man_ttyrec/man1/ ../man

Und das war’s dann.
Hurra, das Paket ist erfolgreich installiert… und ttyrec lässt sich starten.

weiterführende Links:

  1. Wikipedia: ttyrec (en)
  2. Arch-Linux AUR: Suche nach ttyrec (en)

Restic client auf 64 Bit Linux installieren

Mittwoch, 28. April, 2021

Restic [1] ist ein in Go geschriebenes Backup-Tool für die Kommandozeile … oder zum Skripten. Es besteht aus einem einzigen Binary und hat keinerlei Abhängigkeiten zu Libs, Paketen oder irgendwas. Es erzeugt dedulizierte Backups: initial wird ein Vollbackup gemacht und dann nie wieder - es braucht dann nur noch inkrementelle Backups. Restic gibt es für Windows/ Mac/ Linux und diverse Plattformen (BSD, Solaris, Mips, … - siehe Releases (dort etwas scrollen :-) [2]).

Das hat was.

Daheim werfe ich gerade einen Http-Server als Backup-Endpoint auf die Synology [3].

Auf Systeme am Institut habe ich grob 150 Linux-Systeme - mit altem und neuen Linux Varianten verschiedener Distributionen. Ich habe ein Bash Skript geschrieben, das mit wget das Binary des Restic Client holt, entpackt und ins /usr/bin legt. Wer es für ein anderes OS oder Architektur braucht, müsste den Suffix “_linux_amd64” ersetzen … oder aber auch dynamisch machen (mit

uname -a

könnte man hinkommen).

#!/usr/bin/env bash

# ------------------------------------------------------
# CONFIG
# ------------------------------------------------------
resticversion=0.12.0
doLink=0

installdir=/usr/bin
resticfile=restic_${resticversion}_linux_amd64
downloadfile=${resticfile}.bz2
downloadurl=https://github.com/restic/restic/releases/download/v${resticversion}/${downloadfile}

# ------------------------------------------------------
# MAIN
# ------------------------------------------------------
echo
echo "##### INSTALL RESTIC CLIENT into $installdir #####"
echo

echo ----- DOWNLOAD
if [ ! -f "${downloadfile}" ]; then
         wget -O "${downloadfile}.running" -S "${downloadurl}" 
                 && mv "${downloadfile}.running" "${downloadfile}"

else
         echo SKIP download
fi
echo

echo ----- UNCOMPRESS
bzip2 -d "${downloadfile}"
echo

echo ----- INSTALL
mv "${resticfile}" "${installdir}"
chmod 755 "${installdir}/${resticfile}"
rm -f "${installdir}/restic" 2>/dev/null
test $doLink -eq 0 || ln -s "${installdir}/${resticfile}" "${installdir}/restic"
test $doLink -eq 0 && mv "${installdir}/${resticfile}" "${installdir}/restic"

echo
echo ----- SELF-UPDATE
restic self-update
echo
echo ----- RESULT:
test $doLink -eq 0 || ls -l "${installdir}/${resticfile}" 
ls -l "${installdir}/restic"
echo
echo ----- CURRENT VERSION:
restic version
echo
echo ----- DONE

weiterführende Links:

  1. https://restic.net/ Homepage von Restic
  2. Github: Restic Releases
  3. Github: Skript zur Installation eines Restic Http Servers auf einer Synology

Linux Bash - Zufallspasswort für Mysql-Monitoring User

Montag, 28. September, 2020

Ich möchte Mysql/ MariaDB Server monitoren. Dazu legt man einen Monitoring-User in der Datenbank an, der dann Select Rechte auf mysql.* bekommt, um aus der Datenbank Statusinformationen zu lesen. Der User soll ein langes Zufallspasswort bekommen. Die Installation muss mit dem root User auf der Datenbank erfolgen.

Im Monitoring Modus will ich kein Passwort als Parameter übergeben, damit es nicht in der Prozessliste erscheinen kann. Dies lässt sich mit einer .my.cnf im HOME Verzeichnis bewerkstelligen.

Schritt 0: Vorbereitung
Initial setze ich mein HOME und die Variable cfgfile auf die .my.cnf:

# --- set HOME
HOME=/etc/icinga2-passive-client

# --- other vars...
cfgfile=$HOME/.my.cnf
myuser=icingamonitor
datafile=/tmp/mysql-status.txt

Schritt 1: Ein Zufalls-Passwort erzeugen.

Ich will nur parametriesieren können, wie lang das zu erstellende Passwort ist … daher die Variable vorab.
Das Passwort kommt durch eine Ausgabe des Zufallsgenerators /dev/urandom zustande - wobei mittels tr nur Ziffern und Buchstaben gefiltert werden.

    pwlength=64
    mypw=$( head /dev/urandom | tr -dc A-Za-z0-9 | head -c $pwlength )

Schritt 2: Mysql-User mit Rechten anlegen.

Dieser Aufruf funktioniert nur mit dem root (oder anderen zusätzl. angelegten Admin-) User.

Wenn Linux-Root passwortlosen Zugriff auf den Datenbank-Root-User hat, muss man das HOME auf /root setzen, damit dessen .my.cnf gefunden wird.

    HOME=/root

    mysql -e "CREATE USER $myuser@localhost IDENTIFIED BY '$mypw';"
    if [ $? -ne 0 ]; then
        echo "ERROR: mysql command to create user failed."
        exit 1
    fi
    echo "- grant SELECT on mysql tables ..."
    mysql -e "GRANT SELECT ON mysql.* TO $myuser@localhost;"
    if [ $? -ne 0 ]; then
        echo "ERROR: mysql command to grant permissions failed."
        exit 1
    fi

    echo "- flush privileges ..."
    mysql -e "FLUSH PRIVILEGES;"

OK, damit habe ich nun meinen Datenbank-User. Dessen Passwort ich selbst nicht kenne, aber ich weiss, dass es 64 Zufalls-Zeichen besitzt und “halbwegs” safe sein dürfte. Damit erspare ich mir bei zig-zig lokalen Mysql/ MariaDb Services die Verwaltung der Kennwörter für den Monitoring-User.

Schritt 3: Mysql-User-Konfigurationsdatei anlegen.

Die Konfigurationsdatei ist in einem Verzeichnis des Monitoring-Users anzulegen. Zum Erzeugen der Datei wird hier nur auf $cfgfile zurückgegriffen.

    cat  >$cfgfile <<EOF
#
# generated on `date`
#
[client]
user=$myuser
host=localhost
password=$mypw

EOF
    ls -l $cfgfile
    if [ $? -ne 0 ]; then
        echo "ERROR: creation of config file failed."
        exit 1
    fi

Nachdem Schritte 1..3 als root erfolgten, sollte bei Aufruf des Skripts mit dem Monitoring User das $HOME wie in Schritt 0 umgebogen sein, damit die soeben erzeugte .my.cnf angezogen wird. Und voila: dann hat der Monitoring Aufruf einen passwortlosen Zugriff.

Man kann den Status lesen, dies in eine Datei umleiten … und dann die gewünschten Variablen per grep lesen.

function _mysqlreadvars(){
    mysql -e "SHOW GLOBAL VARIABLES ;" --skip-column-names >$datafile
    mysql -e "SHOW STATUS ;"           --skip-column-names >>$datafile
}

function _mysqlgetvar() {
    local sVarname=$1
    grep "^$sVarname[^_a-z]" ${datafile} | awk '{ print $2 }'
}

# init
_mysqlreadvars

_mysqlgetvar max_connections
_mysqlgetvar Max_used_connections

# cleanup
rm -f $datafile

Die Codeschnipsel sind zur Veranschaulichung aus dem Gesamtkontext herausgerissen. Das komplette Skript ist unten verlinkt.

weiterführende Links:

  1. git-repo.iml.unibe.ch: check_mysqlserver

Sourcen für Icinga Checks und Graphen mit Graphite

Freitag, 31. Juli, 2020

An “meinem” Institut geht ohne Open Source eigentlich nichts. Damit wir nicht nur nehmen, geben wir an und wann auch etwas als Open Source zurück. Für dieses Thema wird auf unserer Instituts-Webseite kein Platz eingeräumt, daher publiziere ich es hier in meinem privaten Blog.

Ich habe seit Anfang des Jahres eine Icinga Instanz bei uns aufgebaut. Als Icinga-Client auf unseren Servern verwenden wir ein Bash-Skript, das die REST API des Icinga-Servers als auch des Directors anspricht.

Es gibt es diverse mit Bash geschriebene Checks, die die Standard-Nagios Checks ergänzen (und nur teilw. ersetzen). Zur Abstraktion diverser Funktionen, wie z.B.

  • Prüfung auf notwendige Binaries im Check
  • Schreiben von Performance-Daten
  • Handhabe von Exitcodes

… gibt es eine Include Datei, die gemeinsame Funktionen beherbergt. Oder anders: wer einen der Checks verwenden möchte, muss neben dem Check auch einmal die Include-Datei übernehmen.

Die Sourcecodes der Checks sind nun publiziert in [1].

Viele Plugins schreiben Performance-Daten, die wir mit dem Icinga-Graphite-Modul visualisieren. Die unsrigen Ini-Dateien der Graph-Templates liegen in einem separaten Repository [2]. Beim Schreiben der Ini-Dateien der Graph-Templates kam ich immer wieder ans Limit und es gibt (noch?) nicht so wirklich viele dokumentierte Vorlagen. Und so manche in Graphite dokumentierte Funktionen greifen (scheinbar?) nicht in den Inis für Icinga Graphite.

icinga-graph-check_cpu.png icinga-graph-check_netio.png

Ich hoffe, dass trotz ausbaufähiger Dokumentation der ein oder andere doch entwas mitnehmen kann.

Ich kann mir gut vorstellen, den ein oder anderen Check noch einmal im Detail hier im Blog vorzustellen.

weiterführende Links: (en)

  1. git-repo.iml.unibe.ch: icinga-checks
  2. git-repo.iml.unibe.ch: icinga-graphite-templates
  3. Graphite - Icinga Web 2 Module
  4. Graphite Functions

Bash: Ausführungszeit eines Kommandos in Millisekunden messen

Dienstag, 14. Juli, 2020

Wenn man im Monitoring einen Check schreiben will, der die Antwort-Zeit einer Aktion oder Response eines Servers messen will, sind sekundengenaue Angaben zu grob. Mit dem Kommando

time [Kommando]

kann man sehen, wie lange das jeweilige Kommando brauchte:

$ time ls
[... Liste von Dateien ...]

real    0m0,022s
user    0m0,000s
sys     0m0,015s

Die Gesamtzeit ist in der Zeile real enthalten. Angegeben sind die Minuten, ein “m” und danach die Sekunden mit 3 Nachkommastellen. Wobei die Tausendstel je nach System/ Sprache mit Punkt oder Komma getrennt sein könnten.

Aha, nun muss man “nur” noch die Zeile mit der Angabe “real” in den letzten 3 Zeilen der gesamten Ausgabe suchen und das Ganze parsen.

Als kleines Demo anbei einmal mundgerecht als Funktion (es läuft unter Linux und mit CYGWIN unter MS Windows):

#!/usr/bin/env bash

# ------ FUNCTION

# measure time in ms
# @param  string  command to execute / measure
function getExecTime(){
	local sCommand=$1
	local tmpfile=$( mktemp )

	( time eval $sCommand ) >$tmpfile 2>&1
	local sRealtime=`cat $tmpfile | tail -3 | grep "^real" | awk '{ print $2 }'`
	rm -f $tmpfile

	local iMin=`echo $sRealtime | cut -f 1 -d "m" `
	local iMillisec=`echo $sRealtime | cut -f 2 -d "m" | sed "s#[.,s]##g" | sed "s#^0*##g" `
	typeset -i local iTime=$iMin*60000+$iMillisec
	echo $iTime
}

# ------ MAIN

echo
echo "ZEITMESSUNG IN MILLISEKUNDEN"
echo
mytime=`getExecTime 'ls -ltr'`
echo Dauer: ${mytime} ms

Manjaro: Update-Skript

Freitag, 1. Mai, 2020

Ein kleines Snippet von mir zum Updaten der Linux-Distro Manjaro.

Es aktualisiert die Softwarepakete der Distribution (Kernel, Programme u.s.w.) - danach aus den AUR (Arch User Repository) installierte Programme. Zum Schluss werden nicht benötigte Pakete entfernt.

Es werden noch Zwischenabfragen gestellt, die mit Yes oder No zu beantworten sind. Mit Auskommentieren der Zeile answer=Y kann man es teilautomatisieren, jedoch pamac wird immer eine Interaktion bedürfen und das Passwort erfragen.

#!/usr/bin/env bash

answer=
# answer=Y

# ------------------------------------------------------------
# FUNCTIONS
# ------------------------------------------------------------
function header(){
    echo; echo; echo "========== `date` - $*"; echo
}

# ------------------------------------------------------------
# MAIN
# ------------------------------------------------------------

echo "______________________________________________________________________"
echo
echo
echo "Axels Manjaro update script"
echo
echo "______________________________________________________________________"

header "SYSTEM UPDATE"
echo $answer | sudo pacman -Syyuu

header "Update incl. AUR..."
pamac upgrade -a

header "CLEANUP - remove unneeded packages"
echo $answer | pacman -Qdtq && sudo pacman -Rs $(pacman -Qdtq)

header "DONE."

# ------------------------------------------------------------

Nachtrag:

Wer es ein wenig bunter mag, der kann in der /etc/pacman.conf in der Sektion [options] diese 2 Einstellungen aktivieren:

[options]
(...)
Color
ILoveCandy
(...) 

UPDATE:

  • pamac does not run as root but in user context. So sudo was removed.

weiterführende Links:

  1. manjaro.org Startseite der Linux Distribution
  2. wiki.manjaro.org: AUR
  3. wiki.manjaro.org: pacman
  4. wiki.manjaro.org: Pamac