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.

Ein Dockerfile zum Bauen von PHP5.6 auf einem CentOS6 Image:

FROM centos:6
RUN yum -y groupinstall "Development Tools"
RUN yum -y --enablerepo=extras install epel-release
RUN yum install -y wget libxml2-devel libxml2 openssl-devel sqlite-devel bzip2-devel libcurl libcurl-devel libjpeg-turbo-devel openjpeg-libs openjpeg-devel libpng-devel libvpx-devel libxslt-devel net-snmp-devel readline-devel aspell-devel unixODBC-devel libicu-devel libc-client-devel freetype-devel libXpm-devel libpng-devel gmp gmp-devel libc-client libc-client-devel libmcrypt-devel libtidy libtidy-devel
RUN wget https://fossies.org/linux/misc/old/t1lib-5.1.2.tar.gz; tar -xzf t1lib-5.1.2.tar.gz; cd t1lib-5.1.2 && ./configure && make without_doc && make install
RUN git clone https://github.com/php/php-src.git
RUN cd php-src; git fetch origin PHP-5.6.38; git checkout -b php5.6 origin/PHP-5.6.38; echo 'LC_ALL="en_GB.utf8"' >> /etc/environment; export CXXFLAGS="-O3 -Os -s"; export CFLAGS="$CXXFLAGS"; ./buildconf --forcebuildconf --force && ./configure --disable-static --prefix=/opt/php-5.6 --with-config-file-path=/opt/php-5.6/etc --with-config-file-scan-dir=/opt/php-5.6/etc/conf.d --enable-bcmath=shared --enable-calendar --enable-exif=shared --enable-fpm --enable-intl=shared --enable-mbstring --enable-mysqlnd=shared --enable-ftp=shared --enable-opcache=shared --enable-pdo=shared --enable-shmop=shared --enable-soap=shared --enable-sockets=shared --enable-zip=shared --with-bz2=shared --with-curl=shared --with-freetype-dir=/usr --with-gettext=shared,/usr --with-gmp=shared --with-imap=shared --with-imap-ssl --with-jpeg-dir=/usr --with-kerberos --with-ldap-libs=/usr/lib/x86_64-linux-gnu --with-libxml-dir=/usr --with-mcrypt=shared,/usr --with-mhash=shared,/usr --with-mysql=shared,mysqlnd --with-mysqli=shared,mysqlnd --with-mysql-sock=/var/run/mysqld/mysqld.sock --with-openssl --with-openssl-dir=/usr --with-pdo-mysql=shared,mysqlnd --with-pdo-sqlite=shared,/usr --with-png-dir=/usr --with-sqlite3=shared,/usr --with-t1lib=/usr --with-tidy=shared --with-xpm-dir=/usr --with-xsl=shared,/usr --with-zlib --with-zlib-dir=/usr --with-libdir=lib64 && make && make install


Eines meiner Bilder von der Mondfinsternis am 27.07.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.

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