MySQL Workbench 8

Kleines Ratespiel: Wurde für diese Meldung eine SQL-Datenbank benutzt oder nicht? 🙂 Wenig überraschend lautet die Antwort: „Ja“. Das könnte an der weiten Verbreitung und den vielfältigen Anwendungsmöglichkeiten liegen. Es folgt übrigens keine SQL Einführung oder gar ein SQL Lehrgang 😉

Desktop-App: MySQL Workbench 8

Wenn man mit einer SQL-Datenbank arbeiten möchte, braucht man i.d.R. drei Dinge: Einen SQL-Server, einen SQL-Clienten und ein Programm, daß mit den Daten in der SQL-Datenbank etwas machen möchte.

Der im FOSS vermutlich am häufigsten eingesetzt wird, ist MariaDB. Dieser Fork von MySQL entstand, weil Oracle, die die Firma hinter MySQL gekauft hatten, der Meinung war, mal die Regel zu ändern. Das hat einem Teil der Gemeinde, die bislang MySQL mit entwickelt hatten nicht gefallen und so zogen/forkten Sie in eine eigene Trägergesellschaft „The MariaDB Foundation“ um. Zu den größten Sponsoren zählen Booking.com ( die mit den dicken Spamproblem ), Alibaba Cloud und Microsoft (die mit dem eigenen Closed Source MSQL-Server {Wieso eigentlich Microsoft!?!?!?!}), aber auch WordPress Hersteller Automattic, IBM und ein paar Andere.

Bei MariaDB handelt es sich also um den Serverteil, der verschiedene Datenbank Engines unter ein Dach bringt, so daß man diese mit dem SQL-Clienten der Wahl ansprechen kann. Im MariaDB Paket ist ein einfacher Kommandozeilen Client namens „mysql“ mit dabei. Ja, der heißt nicht „mariadb“ sondern „mysql“, weil das ein Fork von MySQL ist, der eine möglichst große Rückwärtskompatibilität anstrebt. Mit anderen Worten, für den Endbenutzer sollte sich nichts ändern. Möglich ist das, weil MySQL eine FOSS Entwicklung ist, die jeder clonen und weiterentwicklen kann, solange er sich an die Lizenzregeln hält.

Jetzt mag nicht jeder in der Konsole rumschrauben, auch wenn das nicht wirklich schwierig ist, und möchte vielleicht eine Desktop-Anwendung benutzen. Hier kommt die MySQL Workbench ins Spiel:

man sieht ein Startfenster mit der Auswahl in welche Datenbank man einloggen möchte.Wenn man das Fedora Paket MariaDB-Server installiert ( dnf install mariadb-server mariadb ), dann kann man direkt mit der Workbench mit der Arbeit anfangen, da der ROOT Zugang zu dem Datenbankserver nicht beschränkt ist. Das ist natürlich auf Dauer eine völlig untragbare Situation, aber irgendwie muß man erstmal in den Datenbankserver rein kommen, um dann dort die Zugangsdaten für den Rootzugang zusetzen 🙂 In meinem Beispiel ist das erst einmal kein Problem, da die spätere App auf einem abgesicherten Server neu aufgesetzt wird. Aber sobald Eurer Server übers Netz erreichbar ist, ist ein Passwortschutz unumgänglich.

Mein drittes Problem, das welches mit den Daten arbeiten soll, gibts noch nicht, aber das wird dann in PHP oder JAVA geschrieben sein. Beide Sprachen bringen einen kompletten Support für MySQL(und Forks) Datenbankserver  mit.

Mit dem SQL-Clienten kann man jetzt die eigentlichen Datenbanken, Tabellen, Views, Indexe und in letzter Konsequenz auch die Datensätze anlegen und bearbeiten:

Im Beispiel oben die Datenbank namens „census“ und darin die Datenbanktabelle „users“.

Der eine oder andere könnte an der Tabellenbeschreibung erkennen, um was für ein Projekt es sich handelt, aber laßt Euch sagen, es funktioniert leider nicht sauber…{ PAM_MYSQL Frustanflug niederkämpf}.. Wie man hier sehen kann, ist die Ansicht der Datenzeile(n) reicht ansehnlich. Für einfache Bearbeitungen ist der Client gut zu benutzen, aber ehrlich gesagt ist PHPMyAdmin weitaus besser!

Also wenn Ihr mal ein Desktopprogramm sucht, mit dem Ihr in einer SQL Datenbank arbeiten könnte, das wäre ein brauchbares.

Für Fedora herunterladen könnt Ihr das hier: https://dev.mysql.com/downloads/workbench/#downloads Ihr müßt aber erstmal das passende OS ( hier Fedora ) auswählen, damit Euch die Downloadlinks angeboten werden. Das klappt sogar erfreulicherweise ohne Javascript 🙂 Die Fedora RPM-Pakete gibt es nur für 64Bit Versionen, aber das dürfte einen heutzutage nicht mehr wirklich stören.

 

The Revenge of Mariadb IV

Es ist mal wieder Zeit für eine MariaDB Geschichte. Keine Panik, die wird nicht wieder biblisch werden 🙂

Es war mal wieder Zeit für ein OS-Upgrade

Mittlerweile waren drei OS-Releases ins Land gegangen und eine sich anbahnende Sicherheitslücke im Exim .. PSSST! Ich habe sie Euch nicht verraten. Tut so, also wenn Ihr nächste Woche das erste mal davon gelesen habt, ja? 😉 .. zwang zu einem schnellen Update auf eine nicht betroffene Version. Fedora 29 sollte es sein 😉

Nun, glücklicherweise war auch ein anderer Testserver noch auf der gleichen alten OS Release, so daß er als Testlauf herhalten durfte. Dieser Test lief ausgesprochen positiv ab, um genau zu sein, makellos. Daher wurde kürzestfristig entschieden, auch den eigentlichen Kandidaten auf die gleiche Art zu updaten. Ein Snapshot der VM und 30 Minuten später  war das Update komplett und der Server startete wieder.

Mailserver, Webserver, IMAP-Server, diverse Dienste liefen. Was natürlich nicht lief war die MariaDB .. Ätzzz. N I C H T  S C  H O N  W I E D E R!   Auch gutes Zureden, energisches Nachtreten mit systemctl änderte nichts an diesem Status, der Datenbankserver startete nicht.

Same procedure als last year, Miss Sophie?

Leider nein. Letztes mal hatte sich bekanntlich ein Konfigfile des Systemd geändert, so daß die zum Start nötigen Limits nicht gesetzt wurden. Natürlich wurde der DIFF Test vom letzten mal auch wieder angewendet, zeigte aber keinen Unterschied an. Also mußte die gute alte Methode „Start den Dienst von Hand, dann bekommst Du Infos“ herhalten.

Wie macht man das?

Wir schauen uns mal an, was der Systemd so starten wollen würde:

cat /usr/lib/systemd/system/mariadb.service

Da findet dann das hier:

ExecStartPre=/usr/libexec/mysql-prepare-db-dir %n
# MYSQLD_OPTS here is for users to set in /etc/systemd/system/mariadb@.service.d/MY_SPECIAL.conf
# Note: we set –basedir to prevent probes that might trigger SELinux alarms,
# per bug #547485
ExecStart=/usr/libexec/mysqld –basedir=/usr $MYSQLD_OPTS $_WSREP_NEW_CLUSTER
ExecStartPost=/usr/libexec/mysql-check-upgrade

Das POST können wir ignorieren, soweit kommen wir nicht, bleiben nur Pre und der eigentliche Dienststart.

Das in den einschlägigen Envfiles  unter /etc/sysconfig/ nichts steht, reicht also ein :

/usr/libexec/mysqld –basedir=/usr

für den Test aus. Ja super.. eine Fehlermeldung:   Can’t set requested open_files (1024) to 2000 …

Das lag an dem ulimit hier:

# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 32088
max locked memory (kbytes, -l) 16384
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 32088
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Damit kann nicht mal die minimale Version der Datenbank starten 😉 Ergo geben wir ein: „ulimit -n 99999“ und starten es nochmal und siehe da, es hat sich doch wieder was geändert:

2019-06-04 23:13:41 0 [ERROR] /usr/libexec/mysqld: unknown variable ‚innodb_additional_mem_pool_size=50M‘
2019-06-04 23:13:41 0 [ERROR] Aborting

Wenn man denn endlich mal in Logfile schaut, sieht man dort auch die Warnung, daß sich das ja mal ändern könnte. Wer rechnet schon mit damit, daß da jemand mal Ernst macht 😉

2019-05-26 09:18:16 b753fd80 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB’s internal memory allocator.
2019-05-26 9:18:16 3075734912 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

Merke, erst ins Datenbank Log schauen, dann Server updaten!

Drei OS-Versionen sind dann vielleicht doch etwas happig bei einem Update. Diese Option findet man, so man sie gesetzt hat, in der Datei /etc/my.cnf . Anweisung auskommentieren, diesmal Datenbank über systemctl starten und läuft wieder 🙂

Und hier dachte ich eigentlich, ist die Story zu ende… war sie aber nicht!

Der an diesem Master angeschlossene Replications Elf ( Sklave sagt man im PCSG nicht mehr 😉 ) mochte die Replikationsblöcke vom Master nicht mehr lesen, weil Checksumme unbekannt! Das lag daran, daß der Replikations Elfe eine ältere Datenbankversion laufen hatte, da LTS. Einer langen Suche kurzes Ende:

Elfen anhalten: mysql -p -e „stop slave
auf den Master connecten: mysql -p -e „set global binlog_checksum=’NONE‘; SHOW MASTER STATUS;“ ausführen.

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000138 | 521505   |              |                  |
+------------------+----------+--------------+------------------+

Datenbank auf dem Master dumpen, auf den Elfen kopieren. Auf dem Elfen die Datenbank wipen, den SQL Dump einspielen.

Auf dem Elfen : mysql -p -e „change master to MASTER_LOG_FILE=’mysql-bin.000138′, MASTER_LOG_POS=521505;start slave

Sollte wieder gehen. Ging nicht.. Neuer Fehler! Statt:

Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave can not handle replication events with the checksum that master is configured to log; the first event 'mysql-bin.000136' a'

gabs jetzt :

Last_IO_Errno: 1045
Last_IO_Error: error connecting to master 'test@masterserver:3306' - retry-time: 60  retries: 86400

Er zum Geier ist „TEST“ !?

Tja, keine Ahnung wie das passieren konnte, aber der „change master to …“ Befehl hatte den Replikationsusernamen durch „test“ ersetzt! Einfach so! Passwort war ok, Servername war ok, Username weg! Wie geil ist das denn ?!?!?

Also nochmal mit dem change master an den Elfen ran:

/usr/bin/mysql -p -e „stop slave;;CHANGE MASTER TO MASTER_USER=’myreplicationusername‘,MASTER_PASSWORD=’MeinPasswort‘;start slave

Da machste was mit als Admin … Ich wollte doch nur den Exim abdichten, nicht das Rad neu erfinden! Naja, jetzt gehts ja erstmal wieder 🙂 Und bevor noch einer fragt, nein, der Server hatte extern nur Port 25 zu bieten, deswegen ja auch das Update 😉

MariaDB Bugfix sorgt für ein bisschen Ärger

Ein kleiner selbstverursachter Logikfehler bei Datenbankstrukturen macht kleinen Webanwendungen grade ein bisschen Stress. Damit Ihr damit keinen Stress habt, eine kurze Erklärung zum Thema und wie man das behebt und vermeidet.

MariaDB Update

Bis vor kurzem hatten wir auf den Servern noch die MariaDB 10.1.33 laufen, jetzt die 10.2.21 . Beim Wechsel von 10.1 auf  10.2 haben die Devs von MariaDB den globalen SQL-Modus umgestellt, daß er jetzt eher failed, statt tolerant zu sein.

Eine Beispieltabelle:

beispiel

#NameTypKollationAttributeNullStandardKommentareExtra
1 int(11) Neinkein(e)AUTO_INCREMENT
2 int(11) Nein2
3 text utf8_general_ciNein
4 int(11) Neinkein(e)

Jetzt führen wir diesen Insert aus:

INSERT INTO beispiel SET id=NULL, test = 3, name=“Fritz“, counter = 0;

Klappt. Kein Fehler. Nächster Insert :

INSERT INTO beispiel SET name=“Hans“, counter = 0;

Klappt.Tabelle sieht jetzt so aus :

testnamecounterid
3Fritz01
2Hans02

Nun der Insert hier:

INSERT INTO beispiel SET id=NULL, test=9,name=“Killer“;

und schon kommt die Meldung:

ERROR 1364 (HY000): Field ‚counter‘ doesn’t have a default value

Vollkommen zurecht, weil ich im Insert der Datenbank durch Auslassung gesagt habe, nimm den Defaultwert für das ausgelassene Feld.  Da es keinen Defaultwert für das Feld gibt, kann die Datenbank den auch nicht benutzen.

Jetzt ist das aber in MariaDB 10.1 noch möglich gewesen. Das lag daran, daß sich mit 10.2.4 die Defaults des Servermode geändert haben und der Modus „STRICT_TRANS_TABLES“ jetzt aktiv ist, wenn die  Webanwendung das nicht selbst anders haben will. Beweis:

MariaDB [msctest]> INSERT INTO beispiel SET id=NULL, test=9,name=“Killer“;
ERROR 1364 (HY000): Field ‚counter‘ doesn’t have a default value
MariaDB [msctest]> SELECT @@SQL_MODE;
+——————————————————————————————-+
| @@SQL_MODE |
+——————————————————————————————-+
| STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+——————————————————————————————-+
1 row in set (0.00 sec)

MariaDB [msctest]> set sql_mode = „ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION“;
Query OK, 0 rows affected (0.00 sec)

MariaDB [msctest]> INSERT INTO beispiel SET id=NULL, test=9,name=“Killer“;
Query OK, 1 row affected, 1 warning (0.00 sec)

Jetzt die spannende Frage, mit was die Datenbank den Wert aufgefüllt hat, von dem Sie nicht weiß, wie der aussehen müßte:

idtestnamecounter
13Fritz0
22Hans0
59Killer0

Mit „0“ , was bei einem INT ja auch naheliegend ist.

Klare Ansage

Bevor jetzt jemand den MariaDB Entwicklern die Schuld dafür geben will, daß die eigene Webseite nicht mehr so funktioniert: selbst Schuld!

Ihr habt von vornherein einen Logikbug in Eurer Datenbankstruktur + Weblogik gehabt, sich darüber zu beschweren ist heuchlerisch. Da die Webanwendung sich selbst den Modus setzen kann, mit dem die Datenbank mit Ihr arbeiten soll, hätte man das ja auch mal selbst explizit so setzen können, wie man es braucht. Defaults können sich ändern, damit muß man rechnen.

Abhilfe schaffen

  1. Datenbankstruktur so ändern, daß ein Default vorhanden ist.
  2. Im Insert keine Felder auslassen, sondern explizit setzen.
  3. vor der Anwendung set sql_mode = „ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION“;  absetzen, dann hat man wieder das alte Verhalten

Viel Spaß jetzt damit 🙂

Systemd : The Revenge of Mariadb III

Ich möchte Euch heute eine kleine Weihnachtsgeschichte erzählen, die sich so im Linux Lande Fedora zugetragen hat. Um diese Geschichte zu verstehen, solltet Ihr Euch in diese Vorgeschichte von Mariadb eingelesen haben. Die Geschichte wird Euch lehren, Euch nicht mit dem SystemD anzulegen, denn er wird Euer Ende sein ..

Also, sprach der Admin …

Es ist mal wieder kurz vor Weihnachten. Der erste Schnee fiel schon auf den Boden, da trug es sich zu, daß ein älteres Fedora-System ein Upgrade brauchte. Also hisste der Admin die Wartungsflagge des Servers und begab sich an die Konsole. „Hmm..“  sprach er zu seinem Monitor, „der Server ist alt, und wir könnten zwei Versionen überspringen, und damit viel Zeit sparen.“ Auf dem Monitor lächelte ihn seine Reflektion erfreut an und so ward dnf beauftragt, die OS-Release um zunächst zwei Stufen anzuheben.

Dnf tat wie ihm befohlen und ackerte um die gewünschten Pakete zu installieren. Nach 20 Minuten, war das Werk getan und der Admin beauftragte den Server sich neu zu starten. Er tat wie befohlen.

Nach dem Reboot, ist vor dem nächsten Reboot

In freudiger Erwartung, loggte sich der Admin wieder auf seinen Server ein. Tomcat lief, Cron lief, die Datenbank… lief.. und so startete der Admin die Post-Reboot Prozeduren, um die neue MariaDB Version zu initialisieren, das PHP zu setupen, die Chroot zu füllen und sich seinem eigentlichen Ziel, dem DNS Server zu widmen.

Nach einiger Zeit sagte sein treuer Freund pstree erstaunt zu Ihm : „Aber oh Herr, siehe. Der PowerDNS will nicht antworten, obwohl er läuft.“ Der Admin war geneigt an einen kleinen Post-Upgrade Bug zu glauben und startete den PowerDNS neu. Aber auch das zeigte keine Wirkung. Der Prozess blieb stumm. Wieder war es pstree, das aufgeregt zu ihm rief:  „Meister, Mariadb läuft gar nicht, wie soll PowerDNS da antworten?“

Und so befahl der Admin dem SystemD MariaDB neu zu starten. Er tat wie ihm geheißen, kehrte aber nicht von seinem Auftrage zurück. Auch nach 5 Minuten, blieb der SystemD auf dem Wege der Arbeit verschollen. Unruhe machte sich beim Admin breit. Wieso kam SystemD nicht von seinem Job zurück? Was konnte ihm nur passiert sein?

Auf der Suche nach dem Timeout

Also fragt der Admin den journald, was denn dem Systemd zugestoßen sein könnte. Aber der journald wußte es nicht. Ihm hatte keiner einen Fehler gemeldet. Unterdessen meldete sich pstree und sagte: „Herr, so freue Dich. MariaDB ist wieder da. Und PowerDNS antwortet auch wieder! “ . Der Admin schaute auf den Monitor und brummte ein „Hmmmm“ vor sich hin, als der Job endlich zurück kam. Aber was war das ? Weder MariaDB noch PowerDNS funktionierten noch.

Ein schnelles „systemctl status mariadb“ zeigte nur einen „Fehler 203/Exited“ an, und meinte es sei per Signal beendet worden. Wieder dieses „hmmm“ , diesmal von Reflex auf dem Monitor. „Danke“, sagte der Admin laut. pstree sprang aufgeregt durch die Konsole, nichts ging mehr, das war zuviel für ihn. „Komm wieder runter Tree, ich starts nochmal“. Aber auch das brachte nur das gleiche Ergebnis.

Der SystemD war, oder?

Dann durchfuhr es den Admin wie einen Blitz: „Das ist das verdammte Prozesslimit vom SystemD! Das wars doch beim letzten mal auch !“ Gesagt, geändert. Kein Erfolg! Der Admin wurde nervös. Tree hatte sich bereits in die weit entfernteste Konsole zurückgezogen. „Wir haben doch damals eine eigene Limit.conf gemacht.. wo war die nochmal .. ach ja, /etc/systemd/system/mariadb.d/ … könnte es sein, daß sich das Servicefile geändert hat und jetzt irgendeinen Timeoutmist macht ? “ murmelte der Admin zu seinem Abbild auf dem Monitor.

Ein kurzes „diff /usr/lib/systemd/system/mariadb.service /etc/systemd/system/mariadb.service “ erhellte die Mine des Admin.. „JA, DAS WARS“. Endlich. Das eigene Unitfile war derart veraltet, weil es für zwei OS Releases früher gemacht war, daß der Systemd einen falschen Weg zum Start einschlagen mußte. Als der Admin das File entfernte und den Dienst startete, sprang Tree jubilierend aus seiner Konsole. Es war geschafft !

Merke, wenn es um MariaDB geht, versteht der SystemD keinen Spaß. Also halte Dich immer an die Anleitung, wenn Du die Limits konform einbauen willst. Außerdem: MariaDB macht immer nur Ärger beim Update ! Aber wieso immer zu Weihnachten ??!?!?! 😀

 

Linux – mysqldump sieht Leerzeichen als leeren Datenbanknamen an

Erinnert Ihr Euch noch an diesen Beitrag : Solution – mysqldump – No database selected when selecting the database aus dem Jahr 2016 ?

MariaDB & mysqldump

Damals stolperte ich über einen Fehler im Kommandozeilenparsing von Mysqldump.

Wie sich herausgestellt hat, konnte der Betreuer Michael Scholm bei Redhat die Ursache für das Problem entdecken. Kommt Ihr nie drauf: Das  war Schuld ! Oh ?! Ihr habt es nicht gesehen, hier nochmal  . Vielleicht mit der Lupe, da: > <. Ein Space.  Hier … zwischen dem „usr/bin/mysqldump“ und dem „–addlocks“ ist ein “ “ zuviel drin:

/usr/bin/mysqldump  --add-locks -e --force -R ....

Da es keine Option ist, wird es tatsächlich als valider Versuch, einen Datenbanknamen anzugeben gewertet.IMHO, ein Parser-Logik-Bug. Redhat sieht das anders: „not a bug“. Da jetzt raus ist, was es verursacht, kann man es ja leicht beheben.

etwas Kontext

Die Parser für Linux sind, sagen wir mal, ein bisschen eigen und deren Interpretation auch. Als Trenner zweier Argumente einer Kommandozeile gilt ein freistehendes Leerzeichen. Die Bash-Shell entfernt doppelte Leerzeichen und setzte ein Leerzeichen an die Stelle. So ein Leerzeichen zu viel ist schnell getippt und würde zu vielen „Dicke Finger-Syndrom“-Problemen führen, weil ..

… Ja, weil der Parser ohne diesen Trick, zwei Leerzeichen in Folge so übersetzen :

ls -la  foo => ls -la "" foo

Weil „Leerzeichen“ sind Trenner, also steht da oben eigentlich: „ls{Trenner}-la{Trenner}{Trenner}foo .

Wenn man aber zwischen den Trennern nichts hat, dann kommt ein leeres Argument raus. Was ein leeres Argument bedeutet, zeigt sich hier im Beispiel:

[marius ~]$ ls -la "" foo
ls: Zugriff auf '' nicht möglich: No such file or directory
ls: Zugriff auf 'foo' nicht möglich: No such file or directory

Wie man sehen kann versucht ls tatsächlich auf aka. „“ zuzugreifen. Wie das gehen soll ? Gar nicht. Ist ein Logikbug im Kontext von ls . Es wiederspricht der Natur eines ls , etwas aufzulisten, das es nicht gibt. Ergo müßte das Argument ignoriert werden. Jeder Mensch würde das so machen. Computerprogramme sind in der Beziehung blöde. Deswegen gibt es die Bash, die das Doppel-Leerzeichen wegnormaliziert und so vorhersehbare Fehler vermeidet, weil ..

Fehler vermeiden

wie man im obigen ls Beispiel gesehen hat, kann man es ja explizit angeben, wenn man muß => „“ oder “

MariaDB zieht sich jetzt auf den Standpunkt zurück, daß mysqldump sich ja nur wie ls verhalten würde. Tut es natürlich nicht, weil mysqldump komplett failed, wo ls einfach weitermacht und einen Fehler ausgibt.  Naja, Nobodys perfect.

Update

… oh, Redhat hat die Meinung geändert und einen Featurerequest bei MariaDB für einen besseren Parser erstellt. \o/ Das gibt einen dicken Daumen rauf! Mal sehen wies bei MariaDB ausgeht.

Ein MCP namens SystemD

Bunte Linien kreisen vor meinen Augen und bilden bunte Muster. Die Augen schmerzen. Der Kopf schmerzt und auch das Gehirn hat Schaden genommen. Die Welt ist dunkel, aber bunt.  Ich öffne die Augen. Ein rötlich strahlender Wächter stößt mich mit einer Energielanze an: „Aufstehen, Programm!“ Er will, daß ich mit ihm komme. Wir beschreiten Wege aus Energie… bunter Energie, seltsam neonfarbend und doch schwarz, wie die Nacht. Unterwegs treffen wir andere „Programme“ mit Ihren „Wächtern“. Bald stehe ich vor einem Kopf aus Licht: Der MCP, es gibt ihn wirklich!!!!!!

Verstört wache ich auf. Ein Computeradminalptraum, mitten am Tag, vermutlich am Keyboard eingenickt. Aber was könnte mir so einen Schrecken eingejagt haben, daß ich davon einen Tron .. ähm… traum hatte ?

Es fällt mir wieder ein, ich war grade dabei den Beitrag „Revenge of MariaDB“ Part II zu schreiben. Ja, MariaDB, was war doch gleich … achja.. ging mal wieder nicht nach dem Wechsel von F23 auf F24. Einer unserer Datenbankserver  macht merkwürdige Dinge. Die Webanwendung produzierte sporadisch „Kann nicht in die Datenbank verbinden“ Fehlermeldungen und brachte damit die QA vom Kunden an den Rand des Nervenzusammenbruchs.

Die Analyse geschaltete sich schwierig, weil die Admins immer erst nach einem Vorfall gerufen wurden, aber da ging es wieder. Erst eine zeitnahe Analyse des Netzwerkverkehrs bracht dann den ersten Hinweis: „Can’t create a new Thread. If you have enough free memory, check if … “

Damit konnte man etwas anfangen, ein Blick in eine spezielle Überwachungsdatei brachte dann den Hinweis, daß statt 40.000 Datenbankprozessen, nur wenige Hundert liefen. Also half nur ein Testlauf, mit einer Software, die Verbindungen in die Datenbank aufbaut und offen hält. Sowas kann man schnell in PHP, Perl oder Java schreiben:

import ordb.*;

public class Test {

    public static void main(String[] args) {

        Httpd[] liste = new Httpd[100000];
        for(int i=0;i< Integer.parseInt( args[0] );i++) {
            System.out.println("i="+i);
            liste[i] = new Httpd();
        }
        try {
            Thread.sleep(30000);
        } catch(Exception e) {

            e.printStackTrace();
            System.out.println(e);
        }

    }

}

In einer zweiten Konsole, kann man dann den Datenbankserver überwachen :

strace -e send,read,write -s 1024 -f -p `pidof mysqld`

Damit hat man alle Datenbankserverinstanzen im Blick, was die so Lesen und Schreiben und tatsächlich bestätigte dies den Anfangsverdacht, daß der Datenbankserver nicht genug Prozesse spawnen kann. Er setzte bei 512 Prozessen aus, viel zu wenig für unsere Anwendung.

Der schwierige Teil : Limits prüfen

Als erstes denkt man natürlich, daß sich bei den Limits aus Systemd und die Limits : The Revenge of Mariadb etwas geändert hätte, hatte es aber nicht. Wenn man das OS updatet können aber noch ganz andere Dinge passieren, also muß man hier nach „neuen“ Limits suchen.  Um überhaupt die Limits eines Prozesses Live einsehen zu können, muß man ins /proc/ eintauchen:  cat /proc/`pidof mysqld`/limits

Das kann dann so aussehen:

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            unlimited            unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             unlimited            unlimited            processes 
Max open files            65536                65536                files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       32195                32195                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us

Dummerweise sagt dies genau, was man nicht hören will: Alles ok, es gibt keine Limits bei den Prozessen.

Und jetzt steht man da, wo zum Geier kommt dieses 512 Prozesse Limit her?

Es gibt eine Datei namens:  /etc/security/limits.conf

In der könnte man Limits für User eintragen, was aber nicht der Fall war. Außerdem wäre das in der Auflistung genau dieser Limits aufgefallen. Wo kommt dann das Limit her ?

An der Stelle muß man dann praktisch zu Denken anfangen, weil Docs lesen bringt einen fast nicht weiter, weil man gar nicht damit rechnet, daß es noch mehr Limitmöglichkeiten gibt, also auch nicht weiß in welcher Richtung man suchen sollte. Ein gesunder Pragmatismus ist jetzt hilfreich, vielleicht wars auch eine Verzweiflungstat :  grep -r 512 /etc/ /proc/sys/

Also in allen Dateien von ETC und PROC nach einer EIntragung mit 512 zu suchen. Und genau das hat zum Erfolg geführt, so daß ich jetzt eine Anklage wegen Ruhestörung und einen Abdruck meiner Hand an der Stirn habe 😀

Der SystemD macht mehr als er sollte

Im SystemD gibt es eine Konfigurationsdatei : /etc/systemd/system.conf

Der Auslieferungszustand bei Fedora ist, daß dort alle Werte auskommentiert sind, also ungültig sind. Dort fand sich eine 512 Eintragung und der Name der Option war … DefaultTasksMax=512 !

Aber die Option war abgeschaltet, also ist doch die erste Annahme, daß es kein Limit gibt, oder? Tja, Pech gehabt! Der Wert ist nur Deko, weil als Default in den SystemD einkompiliert 🙁

Zum Glück kann man den Wert in dieser Config ändern, den SystemD + MariaDB neustarten und dann wird der neue, unlimitierte Wert auch übernommen. Er taucht in keiner ( mir bekannten ) Procdatei auf. (Hinweise willkommen)

Alles in allem eine Änderung die wohl zu einer heftigen Reaktion seitens der Betroffenen geführt hat, weil die Systemd Entwickler das in einer neueren Version auf 15% der möglichen Prozesse eines Systems limitiert haben. In  unserem Fall wäre das noch schlimmer gewesen, weil wir so noch schlechter hätten Debuggen können, weil es sehr viel seltener passiert wäre.

Warum gibt es das Limit überhaupt ? Ja, weil es Bomben gibt. Das sind z.b. Bashscripte die sich selbst starten und dabei von der Shell abforken, so daß nach kurzer Zeit alle Resourcen eines Systems aufgebraucht sind. Hackt man also einen Server, könnte man den so intern dosen. Damit das nicht geht, gibt wenigstens ein Limit 😉 Das mal jemand Fedora als Server benutzt und dann auch noch als High Performance, damit hatte wohl niemand gerechnet 😀

Meiner Meinung nach, sollte sich der SystemD auf das Starten von Programmen konzentrieren, denn da ist er bedingt besser als SystemV. Aber die ganzen anderen Anmaßungen die das Teil so vornimmt, sind nicht so schön. Der SystemD kann einen echt fertig machen 😉

Ich bin mal gespannt, was beim nächsten OS Upgrade auf uns wartet 😉

Noch keine Patches für MariabDB Root Exploits vorhanden

Für die u.a. bei The Hacker News gemeldeten Root-Exploits für MariaDB gibt es noch keine Patche im Fedora Repository, auch nicht im Unstable Bereich. Da hilft nur, den möglichen Exploit durch Verschleierung zuvermeiden.

Der bereits verfügbare Testexploit, legt Dateien im /tmp/ Ordner an. Das kann man schon mal verhindern, indem beim Start mit Systemd ein privates Temp-Verzeichnis benutzt wird. Das verhindert den Hack nicht, aber die kleinen Scriptkids werden an der Hürde scheitern 😉

Wenn man sein mariadb.service File nicht geändert hat, kommt es in Fedora bereits mit der richtigen Einstellung:

[Unit]
Description=MariaDB 10.0 database server

# Place temp files in a secure directory, not /tmp
PrivateTmp=true

In der my.cnf sollte man sowieso immer das Benutzen von Symbolischen Links abschalten, eine Serverdatenbank braucht das i.d.R. nicht:

symbolic-links=0

Damit kann man auch ohne Patch CVE-2016-6662 nicht ausnutzen um seine Rechte zu eskalieren. Wer bislang „mariadb-10.0.27-1“ noch nicht eingespielt hat, sollte das trotzdem dringend nachholen.

Gegen die Lücken CVE-2016-6663 und CVE-2016-6664 sind die Patche bei Fedora noch in Arbeit. Leider ist auch im Koji noch keine Testversion ersichtlich. Die letzten Builds stammen vom Anfang des Monats, welche zudem die CVE Patche nicht enthalten. Dies kann natürlich daher rühren, daß diese Versionen nicht anfällig waren, da es sich um den 10.1.17/18 er Zweig von Mariadb handelt.

2038 ist schneller da als man denkt

In 23 Jahren, wenn die Unixwelt Y2K erlebt, wird die Welt zusammenbrechen.

Wir haben ja jetzt 2015 und die gängigste Datenbank MySQL legt Timestampfelder immer noch als 32-Bit Feld an. Es sollte ja eigentlich kein Problem sein dort intern 64-Bit zu benutzen, aber wie das so ist, die Tücke liegt im Detail.

MySQL speichert die Daten in einer großen Datei im Binärformat. In dem Augenblick wo dieser Feldtype auf 64-Bit umgestellt wird, muß zwangsweise mysql_upgrade laufen, sonst gibt es nur Probleme. Und wie das Leben so spielt,  mysql_upgrade wird bei normalen Updates eigentlich nie ausgeführt. Da muß man als Admin selbst machen.

„Wenn das noch 23 Jahre sind, warum nervst Du jetzt schon rum?“

Ich kenne Euch halt 🙂 Dabei wollte ich auf etwas anderes hinaus:

Führt öfter mal mysql_upgrade durch. Erst dieser Befehl schreibt die Strukturen im Mysql um z.b. wenn neue Felder in der „mysql“ Datenbank hinzugekommen sind. Mit den Updates von Fedora 20 auf 21 z.b. mußte so ein mysql_upgrade auch zwangsweise laufen, wenn man die neuen „Features“ benutzen wollte.

Zurück zum Jahr 2038. Es werden dann mehr als 40 Jahre zwischen den Leuten liegen, die Y2K mitgeplant haben und denen, die dann für die Systeme verantwortlich sind. Da darf man annehmen, daß die meisten das auf die gleiche leichte Schulter nehmen werden, wie Ihre Vorfahren.

Deswegen wünsche ich heute schon einen schönen Weltuntergang 😉

Tip: Update der Inhalte eines SQL Views

In einer Datenbank wie MySQL kann man sich Selects als Pseudotabellen anlegen und dann selbst wieder über den diese Tabelle einen Select bauen. So etwas nennt man einen View.

Beispiel:

SELECT a.vorname,a.name,b.beruf as beruf FROM Personen as a,Berufe as b WHERE a.berufsid=b.id;

Wenn man diesen Select als View anlegt, hat man drei Felder : Vorname,Name,Beruf

Nennen wir den View mal Test, wäre dieser Select möglich :

SELECT vorname,name FROM Test WHERE beruf = „Bäcker“;

Wenn man nun versucht den VIEW mit UPDATE zu ändern, geht das eigentlich nicht, weil es eine nicht eindeutige Beziehung der Datensätze untereinander ist.

Für mein aktuelles Pandora Projekt habe ich nun einen View gebaut, bei dem das Update tatsächlich möglich ist:

select `pa`.`id` AS `id`,`pa`.`vorname` AS `vorname`,`pa`.`nachname` AS `nachname`,`pa`.`server` AS `server`,`pc`.`value` AS `friendmode` from (`pandora`.`pandora_config` `pc` join `pandora`.`pandora_account` `pa`) where ((`pa`.`id` = `pc`.`uid`) and (`pc`.`name` = ‚michsuchen‘))

Das funktioniert aufgrund dieser Beziehung „((`pa`.`id` = `pc`.`uid`)“ , denn in beiden Tabellen gibt es exakt einen eindeutigen Datensatz. d.b. :

Für jede Person gibt es exakt einen Config Eintrag in der anderen Tabelle. Damit kann der Datenbankserver jetzt die logische Verbindung der Datensätze „rückwärts“ auflösen und in der richtigen Tabelle den richtigen Eintrag ändern:

UPDATE `pandora_userliste` SET friendmode = ‚erlauben‘ WHERE vorname =’meinvorname‘;

Damit ist der View Read/Writeable geworden was es man mit Hilfe des ORDB Frameworks ausnutzen kann, denn Views werden ein Java Datenobjekte erzeugt. Über Views lassen sich schlanke Strukturen und Datenbankobjekte erzeugen, die dazu noch updatefähig sein können (aber nicht müssen). Als Folge davon erhält man übersichtliche Datenbankstrukturen, die von einem Menschen leicht gelesen und verstanden werden können, aber trotzdem Datenbanktechnisch höchst performant gestaltet sein können.

Systemd und die Limits : The Revenge of Mariadb

Es hätte so ein schöner Tag werden können, Weihnachten ist grade rum, der deutsche Wetterdienst droht uns endlich mit Schnee und das Upgrade von Fedora 19 auf Fedora 20 lief gestern Nacht ohne Probleme ab. In freudiger Erwartung einer guten Meldung laß ich den morgendlichen Report meiner Serverfarm. Ok, es ist die Serverfarm meines Arbeitgebers, aber da ich mich morgens drum kümmern muß, ist es meine Farm. Mein System, meine Farm ! Pah.

Ich laß also im Bett die Emails der Nacht und alle Server schienen glücklich zu sein, nur einer meldete um 3 Uhr nachts über 500 Emails in seiner Mailqueue. Ein typischer Fall von Mailspam über ein gehacktes Mailkonto, doch dann wurde mir klar, es ist der Server der gestern sein Upgrade hatte und der hat gar keine Mailkonten die man hacken könnte. Mifft!

Einer ersten Analyse nach, liefen alle Dienste, schon mal ein gutes Zeichen. Dann schaute ich in das Logfiles des Mailserver und stiess auf eine große Anzahl von Fehlermeldungen, da der Mailserver nicht in den Datenbankserver einloggen konnte. Da aber die Emails über diesen Server angekommen waren, schien das nur ein temporäres Problem zu sein:

gave DEFER: MYSQL connection failed: Too many connections

Ohoh… nicht schon wieder.. In 2013 hatte wir nach einem Upgrade ein ähnliches Problem mit dem Httpd, der wollte nach Umstieg auf Systemd auch nicht mehr mit seinen Limits arbeiten. Zum Glück kann man das auf die gleiche Weise lösen, sollte man jedenfalls meinen.

Zunächsteinmal einen Blick in die /etc/my.cnf ob noch alles da ist, man weiß ja nie ..

[mysqld]
max_connections = 2000
max_join_size = 10M

noch alles da. Merkwürdig. Ein Blick ins Mysql-Logfile zeigte dann das hier :

10:26:15 [Warning] Changed limits: max_open_files: 1024  max_connections: 214  table_cache: 400

Das macht der liebe Mysqld, wenn das Open-Files-Limit nicht stimmt, denn Sockets sind auch nur Filedescriptoren. Aber moment, das hatten wir doch beim letzten Upgrade schon mal behoben! Wieso geht das nicht mehr ?

Ein Blick in /etc/systemd/system/mariadb.service zeigt uns: (u.a.)

[Service]
LimitNOFILE=1000000
Type=simple
User=mysql
Group=mysql

Da steht doch, daß er das Filelimit anheben soll, wieso tut er das nicht? Ab dieser Stelle haßte ich den Systemd wiedermal.. wie sich rausstellte, ist das Teil einfach großer „Mifft!“ wie Bernd sagen würde.

Es reicht nicht mehr, das NOFILE Limit ins eigene Servicefile zu packen, man muß es (auch noch) in einer eigenen Limitsdatei eintragen :

# cat /etc/systemd/system/mariadb.service.d/limits.conf 
[Service]
    LimitNOFILE=1000000

Wenn ich jetzt nostalgisch werde, müßt Ihr das verzeihen : Früher war alles besser !

Da gab es son Mist nicht. Der Systemd hat auch Vorteile, daß kann man nicht leugnen, aber für das Teil braucht man ein ganzes Handbuch, wo man vorher einfach mal „ulimit -n 100000“ im Initscript benutzen konnte und die Welt war wieder ok. Das war wirklich besser !