Cronwrapper Logs mehrerer Server zentral sammeln
Es ist gar nicht so lange her, dass ich 20 Jahre Cronwrapper vermeldet habe [1].
Der Cronwrapper vereinfacht die Handhabe, Logging und Überwachung von Cronjobs [2]. OK, er ist von mir geschrieben, aber ich mag irgendwie, was er wie tut - schon dass man Ausgabe schreiben kann, wie man will, sich nicht um Ausgabe-Umlenkung und Loggin kümmern muss. Die Asugabe ist normiert, dass man mit grep schnell zu Details, wie Laufzeit oder Exitcode kommt. Ein mitgeliefertes cronstatus.sh liefert basierend darauf pfannenfertig den Zustand aller lokal laufenden Cronjobs. Aber wer will sich denn dafür auf jeden Server einloggen? Ich hätte da lieber eine zentrale Cronjob-Zentrale.
Wir haben an unserem Institut 200+ Server. Die meisten haben einen Cronjob … oder mehrere. Bisher hatte ich einen Hilfs-Cronjob am Laufen, der alle 5 min ein rsync zu einem Logserver machte. Aber alle paar Minuten immer wieder nur dumm rsync starten, ist auch nicht gerade so toll.
Daher wurde das Sync-Skript [3] erweitert: er startet nur dann rsync, wenn tatsächlich ein neueres Logfile nach dem letzten Sync vorliegt. Das ist selten einfach zu implementieren: nach dem Rsync toucht man eine Datei im Logverzeichnis. Beim nächsten Aufruf ein ls -ltr und man schaut, ob die neueste Datei noch immer das Touchfile ist. Das würde die Zahl der rsyncs deutlich reduzieren, wenn es nur stündlich oder tägliche Cronjobs gibt.
Was ist noch besser? Nur dann synchen, wenn tatsächlich ein Cronjob gelaufen ist. Der Pferdefus ist: ich habe Jobs mit unsterschiedlichen Usern am Laufen. Ein Skript des Cronjobs unter einem x-beliebigen User laufend kann nicht selbst zum Abschluss das rsync auslösen.
Aber ich habe schonmal für ähnlichgelagerte Zwecke ein Skript onfilechange geschrieben [4], das bei Modifikation eines Fileobjekts ein Kommando startet. Initial entstand es, damit Vorgänge mit unprivilegierten Benutzer (mit SSH Zugang oder auch anderweitig) auf einem Applikationsserver den Webservice restarten zu können, was eben nur als root geht. Das Skript selbst loopt zwar ewig, aber man kann es recht einfach in ein Systemd Configfile verpacken, damit es als Systemd Prozess handhabbar ist [5]. Also: man kann es per systemctl starten/ stoppen oder mit jounrnalctl -u [Name] im Systemlog dessen Aktionen begutachten.
Für unsere Logs des Cronwrappers läuft ebenjenes onfilechange Skript in einem solechen systemd Service mit dem User, der berechtigt ist, zu einem Logserver per SSH zu verbinden. Es überwacht das Logverzeichnis des Cronwrappers und startet bei Änderung das Sync-Skript.
Zielserver und Zielverzeichnis liegen in einer Configdatei, die sich mit Ansible, Puppet und Co einfach generieren lässt.
Es gibt pro Server ein eigenes Zielverzeichnis - es enthält dabei den FQDN des jeweiligen Systems.
Last but not least: Auf einem Logserver ein grosses Logverzeichnis vieler Server … wie ist nun das zu handhaben? Dazu ist vor ein paar Jahren auch ein Webinterface mit PHP entstanden, das über alle Server und Jobs durch deren Logs browsen lässt: der Cronlog Viewer [6].
weiterführende Links:
IML CI Server von PHP 7 auf PHP 8.1 portiert
Der IML CI Server ist ein seit 2015 produktives Werkzeug, mit dem bei uns am Institut gut 50 Projekte ausgerollt werden. Bediente Programmiersprachen für unsere Projekte sind PHP, NodeJs und Ruby - aber eine Zielsprache ist nicht limitiert. Der CI Server erzwingt den Workflow der Installations-Reihenfolge über Preview -> Stage -> Live.
Einschub:
F: Warum beschreibe ich das hier auf einer privaten Webseite?
A: Opensource wird an unserem Institut in einem Ausmass genutzt, dass ohne Opensource Produkte bei unserem Betrieb so ziemlich nichts ginge. Aber auch hauseigene Opensource-Projekte werden auf unserer offiziellen Seite ferngehalten. Begriffe, wie “Opensource” oder “GPL” sind genauso inexistent, wie “mein” hier beschriebener CI Server in der Rubrik Software-Entwicklung.
Wie das Rollout im Groben funktioniert:
Build
- Mit einem Git clone wird der Sourcecode des Projektes in ein temporäres Build-Verzeichnis geholt.
- Das Projekt kann mit einem definierten Hook-Skript Aktionen triggern, um Module nachzuladen, etwas compilieren, Javascript+CSS minimieren … was auch immer
- Was dann noch im Build-Verzeichnis überbleibt, wird zu einem Archiv zusammengepackt und eine Metainfo-Datei angelegt.
- Der CI Server kann die Installation triggern. Mitgeliefert werden 2 Plugins für einen SSH-Aufruf und Ansible AWX. Damit etwaige Tools die Installation starten können - und ohne Zugriff auf den CI-Server im internen Netz haben zu müssen, kann man das Paket per Rsync zu mehreren Zielsystemen syncen, z.B. zu einem Puppet Master oder einem abgesicherten Software-Download-Server (das ist ein seperates Open Source-Projekt).
Installation auf der ersten Phase (Preview)
- Das Paket wartet in der Queue im Modus “zur Installation bereit”. Die Queue besitzt eine zeitliche Freigabe. Man kann erzwingen, dass eine Installation beipielsweise nur von Montag bis Donnerstag im Zeitfenster 14:00-15:00 Uhr erfolgen darf.
- Im Projekt-spezifischen Setup ist festgelegt, ob das Rollout per SSH oder AWX mit entsprechender Parametrisierung erfolgt … und auch welche Zielsysteme existieren. Das AWX Rollout-Plugin holt sich per API die Templates, Inventories und Playbooks vom AWX Server, die in den Prohjekteinstellungen als Dropdown zur Auswahl stehen. Nach einem Build wird das Rollout-Plugin auf die erste Projekt-Phase angewendet, um das Projekt zu installieren.
- Die Implementierung der Installation ist keine Komponente des CI Servers. Es gibt aber eine Bash-Implementierung für ein Installations-Werkzeug (ebenfalls ein separates Opensource Projekt).
- Unsere Installation umfasst … (sicherer) Download des Software Archivs … Entpacken dessen … Start eines Hook-Skripts zur Installation und anderen Aktionen (Cleanup des Cache, Restart von Services) … Generieren von systemspezifischen Konfigurationsdateien mittels Templates
- Feedback an den CI Server, damit dieser weiss, wie weit das Paket ausgerollt wurde.
Rollout auf Stage und Live
Rein technisch ist das identisch mit dem, was zur Installation auf Preview gesagt wurde.
Damit ein Paket von einer zur nächsten Phase freigegeben werden kann, bedingt es die Interaktion - den Klick eines [Accept] Buttons plus Bestätigung, dass man die Featrues und Software-Zustand für OK befunden hat.
Zum Update auf PHP 8.1 habe ich für eine Entwicklungsumgebung mit rootless Docker die benötigte Konfiguration aufgebaut - diese ist im Repository im Unterverzeichnis “docker” enthalten (zuvor habe ich mit einer lokalen Virtualbox-Instanz entwickelt). Das wird Weiterentwicklungen vereinfachen.
Das Update beinhaltet rein die Portierung auf ein aktuelles PHP 8.1 um es auf einem Server mit aktuellesten OS zum Laufen zu bringen. Andere Komponenten, wie Bootstrap 3 sind gnadenlos veraltet und dürfen wohl in naher Zukunft aktualisiert werden.
Screenshots
In der Übersichtsseite aller Projekte kann man filtern, um die Ansicht zum Auffinden “seines” Projektes zu reduzieren.
Ein neuer Build erhält basierend auf dem Hash der Commit ID einen Farbcode. Damit lässt sich optisch darstellen, wie weit ein neuer Build bereits ausgerollt ist. In jeder Phase gibt es [Info] Buttons, die einem Details im Popup aufzeigen.
Erstellen eines neuen Projektes.
Wahlt man ein Projekt, sieht man zunächst eine Seite mit Repo, Archiv (der Builds) und die Phasen des Projekts
In den Projekt-Einstellungen .. Tab Rollout: hier das AWX-Plugin mit den allg. Voreinstellungen. Jedes einzelne Feld lässt sich in jeder der Phasen äbernehmen oder aber nochmals übersteuern.
weiterführende Links:
- Repo: IML CI Server (Opensource; GPL 3.0)
- Docs: IML CI Server auf os-docs.iml.unibe.ch (WIP)
- Repo: IML CI Paket Server (Opensource; GPL 3.0) - Software-Archiv für ein öffentlich zugängliches System, welches nur sichere Downloads mit one time Tokens zulässt
- Docs: IML CI Paket Server auf os-docs.iml.unibe.ch
- Repo: IML CI Deployment Client (Opensource; GPL 3.0) - Bash-Skript zur Installation via IML CI Paket Server, Ondeploy-Hook, Generierung von Konfigurationen aus Templates
- Docs: IML CI Deployment Client auf os-docs.iml.unibe.ch
Update meiner Open source docs
Unter https://www.axel-hahn.de/docs/[POJEKT] habe ich diverse Hilfen für PHP- und Javascript Tools bereitgestellt, die ich mit einem Parser generieren lasse. Jener Ansatz ist etwas älter und länger her - und stellt bereits geraume Zeit so einige meiner Dokumentationen bereit…
Eigentlich suchte ich nach einem mehr generischen Ansatz, um heutzutage in Git übliche Markdown-Dateien in statisches HTML umzuwandeln. Es gibt da diverse Tools, aber ich bin beim PHP-CLI Tool Daux hängengeblieben. Insbesondere, weil ich hier im Gegensatz zu anderen angetesten Werkzeugen keine Extra Konfiguration für einen Navigationsbaum als Config-Datei hinterlegen muss. Auch hat der Entwickler sehr schnell reagiert und auf gemeldete Feature Requests reagiert. Kurz: ich habe nun diverse einzelne Dokumentationen verschiedener Produkte und Klassen mit Daux gebaut. Das sind jeweils statische Verzeichnisse mit statischen HTML-Dateien + Javascript und Css out of the Box in jedem Browser laufen, wenn man sie vom Filesystem oder aber USB-Stick startet.
Was diverse Markdown zu Html Generatoren bieten, ist ein eingebauer Webserver für eine Vorschau. Der hilft beim Schreiben der Markdown-Dateien. Mittlerweile in Markdown Quasi-Standard ist der Support von mathematischen Formeln oder aber Graphen (mermaid.js) - das soweit ich auf Github, Gitlab oder aber lokal im Visual Studio Code per Markdown Preview gesehen habe.
Soweit so gut. Und wenn ich nun zig alleinstehende Dokumentationen habe und eine Index-Seite haben will?
Ich habe dazu einen Ansatz zum Generieren einer Index-Seite wie folgt gewählt:
- ich möchte Gruppen: nach Programmiersprache oder nach einer sonstigen Rubrik
- in jeder Rubrik werden N Projekt-Dokumenationen verlinkt
- … wobei jene referenziert wird als Git-Repository, um diese mit Daux on the fly generieren zu lassen
- … oder aber: weil ich noch meine geparsten Dokumentationen habe: ich kann anderweitig bestehende Dokumentationen ebenfalls einbetten
- die Index-Seite soll flexibel sein und verschiedene Templates/ CSS/ Javascritpt unterstützen
Ich habe dazu ein Bash-Skript geschrieben, das mit jq eine JSON Config-Datei parst und mittels eines Templates die Seitenelemente generieren lässt. Die Flexibilität steckt in den Templates - dese bestimmen, ob es ein
OK, all das ist zu viel Text … so sieht meine Übersichtsseite mit dem Template mit Gruppen und Boxen sieht so aus: Axels Docs
weiterführende Links: (en)
- Axels Docs-Index-Seite
- daux.io Hilfe-generator - Markdown zu HTML
- Github: axelhahn/multidoc-generator
- Statische Hilfe zum multidoc-generator
- Mermaid.js
Ruckelnde Videos mit Emby auf Synology
Es ist ein halbes Jahr her, dass ich Synology von DSM 7 auf Version aktualisierte. Dies bedingte eine neue Installation einer neueren Version von Emby. Und irgendwie war die Video-Wiedergabe seither immer nur am Ruckeln, dass ich den Spass verlor. Verursacher war Ffmpeg, das on-the-fly das Video-Ausgangsfile für eine Wiedergabe auf einem Ziel in eine Auflösung umrechnet. Mit Herunterschrauben der Auflösung während der Videowiedergabe kam man dem bei, aber schlechtere Auflösungen trüben auch den Filmgenuss.
Wie es der Zufall will habe ich mich nun nochmals in den Emby-Einstellungen verirrt (von der Emby Startseite rechts oben das Zahnrad-Symbol).
Unter Wiedergabe -> Video -> Heimnetzwerkqualität habe ich “auto” voreingestellt.
Im Menü unterhalb “Server” gibt es den Eintrag “Transcodiere“, wo man Hardware-Beschleunigung und andere Transcoding-Einstellungen setzen kann. Ich habe weder Emby Premiere noch würde ich mit der Synology eine Hardware-Beschleunigung aktivieren können. Aber auf dieser Einstellungsseite ist ja noch mehr.
Unter “H264-Kodiereinstellung” war “auto” gewählt. Und was soll ich sagen: das bewusste wählen einer langsameren Einstellung wirkt Wunder. Während bei Einstellung “auto” bei Fimlwiedergabe die CPU nahezu ausgelastet war und der Load sich bei 15 einpegelte … hingegen bei “superfast” wird die CPU nur noch kurz zu 20% belastet und liegt dann im einstelligen Bereich. Und bei Videowiedergabe die gewählte Videoqualität mit “auto” besser, als die zuvor gedrosselte Bandbreiten-Auswahl, damit es nicht ruckelte.
Wer mag, kann es von der schlechtesten Qualitätsstufe “superfast” schrittweise noch hochsetzen. Aber das ist eine gute Stellschraube, bei der man ansetzen kann.
Mysqldump - trotz Exitcode 0 keine Daten im Dumpfile
Ich verwende diesen Aufruf, um Schemata auf dem Mysql Server zu dumpen:
mysqldump --opt --default-character-set=utf8 --flush-logs --single-transaction --no-autocommit --result-file="$_dumpfile" "$_dbname" 2>&1 $myrc=$?
… und stand vor dem Phänomen, dass der Exitcode 0 war - also eigentlich den Erfolg meldet - aber es keinerlei Daten im Dump gab.
Das Betriebssystem war ein Centos8 Stream. Das Problem lag in der Option –flush-logs, die nicht ausgeführt werden konnte, da das Verzeichnis /var/log/mysql/ (warum auch immer) nicht mehr vorhanden war. Dass ein leerer Dump ohne Daten erzeugt wird und kein Exitcode > 0, ist m.E. ein Fehler im mysqldump. Und den versuche ich, zu umschiffen.
Ich habe nach dem Dump noch einen Check hinzugefügt, der das Vorhandensein auf mind. ein CREATE oder aber INSERT Statements prüft. Oder anders: wenn man eine (korrekte) leere Datenbank ohne einzige Tabelle oder auch nur 1 einzigem gesicherten Datensatz hat, würde ein Fehler beim Backup gemeldet. Ich meine, damit lässt es sich leben.
mysqldump --opt --default-character-set=utf8 --flush-logs --single-transaction --no-autocommit --result-file="$_dumpfile" "$_dbname" 2>&1 $myrc=$? if [ $myrc -eq 0 ]; then if ! zgrep -iE "(CREATE|INSERT)" "$_dumpfile" >/dev/null then typeset -i local _iTables _iTables=$( mysql --skip-column-names --batch -e "use $_dbname; show tables ;" | wc -l ) if [ $_iTables -eq 0 ]; then echo "EMPTY DATABASE: $_dbname" else echo "ERROR: no data - the dump doesn't contain any CREATE or INSERT statement." # force an error $myrc=1 fi fi fi if [ $myrc -eq 0 ]; then echo "OK" # Und dann hier noch komprimieren... # gzip $_dumpfile" # ... und Erfolg der Kompression auswerten else echo "ERROR: mysqldump failed." fi
Update:
- 24.03.2022 - eine leere Datenbank würde als Fehler gemeldet - daher zähle ich mal noch die Tabellen
weiterführende Links:
- mysql.com: mysqldump
- mariadb.com: mysqldump
- IML open source: IML-Backup (mein Backup Tool an unserem Institut zum lokalen Dumpen div. DBs und Backup mit Restic/ Duplicity)
- DOCs: os-docs.iml.unibe.ch/iml-backup/
20 Jahre Axels Cron-wrapper
Ich habe grad in die History geschaut: 20 Jahre (!!!) nutze ich schon den meinigen Cronwrapper auf Linux/ Unix-Systemen.
Und ich bin noch immer am Aktualisieren und Verfeinern von dessen Skripten oder Dokumentation. Auch weil ich dessen Idee so mag. Alles ist OpenSource - GNU GPL 3.0.
Das Repository [1] enthält
- cronwrapper.sh - ein Wrapper - wenn man Cronjobs hat, dann stellt man den einfach mal vorn dran
- cronstatus.sh - das Skript zeigt den Status aller auf dem System befindlichen Cronjobs
- inc_cronfunctions.sh - ein Script, dass in Bash geschriebene Cronjobs gesourct werden kann, um div. nützliche Funktionen zu nutzen.
- Dokumentation im Markdown Format zur Installation und allen Features.
Der einfachste Einstieg ist, den Wrapper cronwrapper.sh zu verwenden: mit allen bestehenden Cronjobs, egal welcher Programmiersprache jene sind, lässt sich dieser ergänzen. Und man erhält out-of-the-box kleine nette Features.
- STDOUT und STDERR werden eingefangen und in ein normiertes Logfile geschrieben (ohne jenes explizit angeben zu müssen)
- Das Logfile wird normiert und ist mit grep nach Output oder Metadaten durchsuchbar
Alle Cronjobs, die den Wrapper verwenden, werden mit dem Skript cronstatus.sh aufgelistet und bewertet:
- weisen sie exitcode 0 auf?
- sind sie in der vorgegebenen Frist gestartet worden?
Diese Ausgabe kann man auch in einem Monitoring Script für die Überwachng aller Cronjobs auf seinen Systemen einbinden.
Und als Goodie gibt es ein Include file inc_cronfunctions.sh,welches hilfreich sein kann, sofern die Cronjobs in Bash geschrieben sind: eine Reihe nützlicher Funktionen werden darin bereitgestellt, um das Schreiben von “sicheren” und lesbaren Conjobs zu erleichtern.
weiterführende Links: (en)
- Github: cronwrapper
- Docs auf axel-hahn.de
Manjaro update - pacman (6.0.0-1) breaks dependency ‘pacman<5.3′ required by package-query
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:
- manjaro.org (en)
Linux: Kommando unter einem anderen User starten
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:
Mysql Replikation neu aufsetzen als Bash Skript
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:
Manjaro: ttyrec installieren
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: