chr.istoph, der Blog

Beim Updaten von Zabbix 3.4 auf 4.0 startete der Zabbix Server nicht mehr. Als ich ins log schaute, fand ich folgende Fehlermeldungen:

current database version (mandatory/optional): 03040000/03040007
required mandatory version: 04000000
starting automatic database upgrade
...
 25862:20181007:104142.929 [Z3005] query failed: [1050] Table 'tag_filter' already exists [create table tag_filter (
`tag_filterid` bigint unsigned not null,
`usrgrpid` bigint unsigned not null,
`groupid` bigint unsigned not null,
`tag` varchar(255) default '' not null,
`value` varchar(255) default '' not null,
primary key (tag_filterid)
) engine=innodb]

  2301:20181007:105802.685 query [txnlev:1] [create table task_check_now (
`taskid` bigint unsigned not null,
`itemid` bigint unsigned not null,
primary key (taskid)
) engine=innodb]
  2301:20181007:105802.692 [Z3005] query failed: [1050] Table 'task_check_now' already exists [create table task_check_now (
`taskid` bigint unsigned not null,
`itemid` bigint unsigned not null,
primary key (taskid)
) engine=innodb]
  2301:20181007:105802.693 query [create table task_check_now (
`taskid` bigint unsigned not null,
`itemid` bigint unsigned not null,
primary key (taskid)
) engine=innodb] failed, setting transaction as failed

Lösung:
Ich habe die MySQL Tabellen für tag_filter und task_check_now gelöscht. Nach dem Starten des Zabbix Server kam keine Fehlermeldung und das Updaten der Datenbank funktionierte.

DROP TABLE tag_filter;
DROP TABLE task_check_now;

Um sicher zugehen, dass Ihr an der Stelle nichts falsch macht, solltet ihr vorher ein Backup der Datenbank machen.

Da aktuell nur für Debian 9 stretch, für den Meltdown Bug, ein Kernel Update verfügbar ist. Habe ich für die folgenden Versionen ebenfalls einen Kernel nach vorlagen der jeweils letzten Kernelconfig gebaut:

Squeeze
linux-image-4.14.12_1-squeeze_amd64.deb

Wer noch nichts von Meltdown und co mitbekommen hat sollte hier einmal weiter lesen:
meltdownattack.com
access.redhat.com cve-2017-5754

[UPDATE]
Die Updates für Debian und Ubuntu sind endlich veröffentlicht worden. Deshalb habe ich die Versionen für Jessie und Wheezey in diesem Artikel entfernt. Sie sollten nun wieder auf den Distro Kernel wechseln. Für Debian 6 ist noch kein Kernel Update angekündigt, daher bleibt dieser Antiekel hierfür noch bestehen.

Folgendes Problem: auf eine ententen Server möchten wir auf ein Git Repository zugreifen auf dies der Server eigentlich keinen Zugriff hat, da der Git Server in einem Lokalen Netz steht. Der Rechner von dem ich dieser Operation ausführen möchte, kann all Server erreichen.

Somit habe ich mich per SSH mit Port Fortging auf den Server verbunden:

ssh -A -R 2222:git.local:22 server.tld

Hier wird mit der Option -R der Port 2222 auf dem entfernten Server bereit gestellt und auf den „git.local“ Server mit dem Port 22 weitergeleitet. Mit der Option -A habe ich zusätzlich SSH Agent Forwading eingegeben. Somit wird nicht einmal ein SSH Key auf dem Server benötigt.

Als nächstes habe ich in der .git/config die URL des Repositories angepasst.

...
url = git@[localhost:2222]:gitreponame
...

Eigentlich sollte die IP oder der DNS Name des Git Servers stehen. Dies habe ich durch localhost ersetzt. Leider ist der Port 22 natürlich belegt, somit habe ich diesen ebenfalls umgebogen. Dies geht nur mit den Eckige Klammern [localhost:2222].

Unter Debian 9 Stretch hat vim eine neue default Einstellung bekommen, den Mouse Modus. Möchte man Texte per Maus kopieren bzw in die Zeichenablage legen dies nicht mehr.

Ich habe mir zum editieren der vim Konfiguration Datei folgenden Einzeiler geschrieben, den ich einmalig ausführen muss:

sed -i 's/^  set mouse=/"  set mouse=/' /usr/share/vim/vim80/defaults.vim

Was macht er im Detail:
In der /usr/share/vim/vim80/defaults.vim muss unter folgender Sektion der set mouse Parameter auskommentiert werden.

" In many terminal emulators the mouse works just fine.  By enabling it you
" can position the cursor, Visually select and scroll with the mouse.
if has('mouse')
"  set mouse=r
endif

[UPDATE]
beim Updaten von vim wird die vom Paket mitgebrachte defaults.vim mit einem merge conflict behandelt. Des wegen ist die oben eingeführte Varianten nicht sinnvoll. Alternativ kann man die /etc/vim/vimrc.local oder ~/.vimrc erstellen oder anpassen:

$ cat /etc/vim/vimrc.local

" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837761#76
"
runtime! defaults.vim

let g:skip_defaults_vim = 1

set mouse&

Ein einfaches touch ~/.vimrc reicht aber auch. Achtung dann werden die anderen Default Einstellungen ebenfalls nicht geladen.

Quelle: blog.bricart.de

Für eine Video Projekt habe ich ein Script das in einer Schleife ein Einminütiges Video erstellt und dieses danach verarbeitet. Damit man die Erstellung sauber beenden kann, habe ich beim Starten eine Datei angelegt und zum beenden wird diese Datei wieder gelöscht. In der schleife wird immer abgefragt ob diese noch Existiert:

#!/bin/bash
touch run
trap "rm run" 0 15
while [ -f run ]; do
  ffmpeg ...
  ./verarbeitung.sh &
done

So kann man das Skript sehr gut von „außen“ steuern. Ein weiteres Script zum verarbeiten, das sich ebenfalls in der schleife befindet, habe ich geforkt.

Nun habe ich das Script auf einen systemd Service umgestellt, bei dem ich auf zwei Probleme gestosen bin.
1. Systemd beendet das Script und alle hiervon aufgerufenen Programme ebenfalls mit Signal 15. Das bedeutet das, dass Video erstellen und verarbeiten umgehend unterbrochen werden.
2. Das „verarbeitung.sh“ Script ist eigentlich vollkommen unabhängig und es muss nicht auf dessen Beendigung gewartet werden.

Lösung:
Im SystemD Services habe ich den Kill Mode auf Mixed umgestellt. Das Sendet nur noch an eigentliche Script ein Signal 15. Hier tiggert dann der trap und löscht die Datei zum Beenden der Schleife.

[Service]
KillMode=mixed

Den fork habe ich mit mit systemd-run in eine eigene Unit verfrachtet. Somit kann die Verarbeitung abgeschlossen werden und SystemD kann den Dienst als beendet erklären.

systemd-run --unit "verarbeitung-$(date +%y%m%d-%H%M%S)" ./verarbeitung.sh