chr.istoph, der Blog

Fehler beim updaten von Zabbix 3.4 auf 4.0:

Sonntag, Oktober 7th, 2018

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]

1

2

3

4

5

6

7

8

9

10

11

12

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

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;

1 2	DROP TABLE tag_filter; DROP TABLE task_check_now;

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

Veröffentlicht am: 07.10.2018 von: CHR | Tags: zabbix | publiziert in: Computer, public

Debian 6 Kernel with Meltdown fixes

Sonntag, Januar 7th, 2018

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.

Veröffentlicht am: 07.01.2018 von: CHR | publiziert in: Debian, public, Security

localen git Server via ssh forwarden

Mittwoch, Dezember 13th, 2017

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

1	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
...

1

2

3

...

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].

Veröffentlicht am: 13.12.2017 von: CHR | Tags: git, ssh | publiziert in: Linux, public

Der vim Mausmodus unter Debian 9

Freitag, November 17th, 2017

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

1	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

1

2

3

4

5

" 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&

1

2

3

4

5

6

7

8

9

$ 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

Veröffentlicht am: 17.11.2017 von: CHR | Tags: vim | publiziert in: Debian, public

systemd KillMode und systemd-run

Sonntag, Oktober 8th, 2017

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

1

2

3

4

5

6

7

#!/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

1 2	[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

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

Veröffentlicht am: 08.10.2017 von: CHR | Tags: systemd | publiziert in: bash, Linux, public

chr.istoph, der Blog

Kategori public

Fehler beim updaten von Zabbix 3.4 auf 4.0:

Debian 6 Kernel with Meltdown fixes

localen git Server via ssh forwarden

Der vim Mausmodus unter Debian 9

systemd KillMode und systemd-run

Seiten

Kategorien

Blogs

Meine Seiten

Webseiten

c/o Authors

Meta

Archive

chr.istoph, der Blog

Kategori public

Fehler beim updaten von Zabbix 3.4 auf 4.0:

Debian 6 Kernel with Meltdown fixes

localen git Server via ssh forwarden

Der vim Mausmodus unter Debian 9

systemd KillMode und systemd-run

Seiten

Kategorien

Blogs

Meine Seiten

Webseiten

c/o Authors

Meta

Archive

Schlagwörter