Linux Kernel first meta block group too large

Das Thema von Spectre und Meltdown hat uns ebenfalls gut beschäftigt, aber heute wollen wir nicht darüber reden. Viel mehr gehen wir auf einen Bug im Linux Kernel ein, welcher uns bei den Upgrade-Aktionen über den Weg gelaufen ist und zuerst für Verwirrung sorgte.

Im Detail betrifft es den Mount Vorgang von Ext4 Filesystemen, welche in der Vergangenheit vergrößert oder verkleinert wurden. Dies quittiert sich mit der Fehlermeldung ‘first meta block group too large’. Das Ganze trat im Kernel 4.4.48 das erste mal auf und zieht sich leider durch die Reihe. ( z.B. hier und hier ). Die Behebung ist für Stable Releases geplant, aber unsere Tests mit einem recht aktuellen 4.13er Kernel zeigten noch das gleiche Verhalten. In den genannten Links existiert auch schon ein Patch für einen manuellen Kernel Build, falls Bedarf besteht.

Die Lösung des Problems lässt sich leider nur mit einem neueren/selbst gebauten Kernel oder einer Portierung der Daten mittels altem Mount und neuem Filesystem beheben. Wir hoffen Euch mit dieser Information ein paar graue Haare und Zeit zu ersparen.

Und wem all das Ganze zu viel wird, der kann sich von uns gern unterstützen lassen.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

MariaDB Upgrade von 10.0.x auf 10.2.x in 10 einfachen Schritten

Ein Upgrade von verschiedenster Software ist von Zeit zu Zeit nötig. So auch von MariaDB. Der Folgende Blogpost ist ein Leitfaden für ein normales Upgrade.

Wenn man noch MariaDB 10.0.x im Einsatz hat und möchte nun auf 10.2.x ist dies in der Regel kein Problem. Es gibt jedoch ein paar wenige Punkte auf die man dabei achten sollte.


  • Ab MariaDB 10.1.x  können unter “/etc/mysql/conf.d” keine speziellen Parameter mehr für Multi-Instanzen angeben werden. Hier wurden in der Vergangenheit beispielsweise Parameter gespeichert, die man mit einem Config-Management Tool verwaltet hat und man nicht wollte, dass mehrere Server die gleichen Parameter bekommen. Bei manchen Setups kann dies etwas aufwendig werden, aber es gibt keinen Weg drum herum.
  • ich empfehle vorher auf jeden Fall ein Backup der Konfigurationsdateien und der Datenbanken anzufertigen.
  • Unbedingt erst die Slaves upgraden, dann die Master. Denn:
    Master MariaDB 10.0.x <=> Slave MariaDB 10.2.x funktioniert
    Master MariaDB 10.2.x <=> Slave MariaDB 10.0.x funktioniert nicht 
  • Es haben sich zwischen den Versionen verschiedene Default Parameter der DBs geändert. Es sollten also auch die Changelogs für die jeweils wichtigsten Parameter geprüft werden.

Sofern oben genannte Punkte berücksichtigt wurden, kann das eigentliche Upgrade vorbereitet werden. Als Zwischenschritt, empfehle ich MariaDB 10.1.x zu installieren, um eventuell anfallende Abhängigkeiten mitzunehmen:

  1. Parameter aus /etc/mysql/conf.d anpassen
    Wichtig dabei, auch die Instanznummerierungen [mysqldX] auszukommentieren 

    #[mysqld1]
    # * Basic Settings
    #read_only = 1
    #[mysqld2]
    # * Basic Settings
    #read_only = 1
  2. Datenbank Instanz(en) stoppen
    Mutli-Instanzen stoppen mit:

    mysqld_multi stop X
  3. Pins aus /etc/apt/preferences.d/mariadb.pref entfernen (oder die Datei löschen)
    rm /etc/apt/preferences.d/mariadb.pref
  4. Upgrade vorbereiten
    /etc/apt/sources.list.d/mariadb.list

    deb http://mirror2.hs-esslingen.de/mariadb/repo/10.1/ubuntu xenial main
    deb-src http://mirror2.hs-esslingen.de/mariadb/repo/10.1/ubuntu xenial main
  5. Upgrade durchführen
    Allgemein:

    apt-get update && apt-get upgrade

    mariadb-server upgraden

    apt-get upgrade mariadb-server
  6. Das gleiche nun nochmal mit der Version 10.2.x
    /etc/apt/sources.list.d/mariadb.list

    deb http://mirror2.hs-esslingen.de/mariadb/repo/10.2/ubuntu xenial main
    deb-src http://mirror2.hs-esslingen.de/mariadb/repo/10.2/ubuntu xenial main
  7. Upgrade dürchführen
    Allgemein:

    apt-get update && apt-get upgrade

    mariadb-server upgraden

    apt-get upgrade mariadb-server mysql-common
  8. Die Instanz(en) nun wieder anstarten
    Multi Instanzen werden gestartet mit:

    mysqld_multi start X
  9. Datenbank Upgrade durchführen
    Für eine Instanz: 

    mysql_upgrade

    Für multi-Instanzen:

    for sock in /var/run/mysqld/mysqld_33*.sock ; do mysql_upgrade -S $sock ; done
  10. Aufräumen
    dpkg -l | grep maria

    Hier kann alles entfernt werden, was mit “rc” gekennzeichnet ist. 

    apt-get purge $alte-mariadb-versionen && apt-get autoremove

 

Nun sollten die Instanzen alle mit der aktuellen MariaDB 10.2.x laufen. Dieser Artikel ist nur ein Vorschlag, wie das Upgrade durchgeführt werden kann. Letztendlich kann es sein, dass in Einzelfällen noch Pakete nachinstalliert werden müssen. Ein mir bekannter Kandidat ist zum Beispiel: libmariadb3

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Fast ein halbes Jahr NETWAYS

Am 01.September 2017 haben wir (Afeef, Killian, Philipp) bei NETWAYS unsere Ausbildung zum Fachinformatiker angefangen. Um uns auf die bevorstehende Arbeit im Professional Service vorzubereiten, bekamen wir gleich in der ersten Woche eine “Linux Basic”-Schulung. Damit wir das Gelernte weiter festigen können, wurde uns ein “LAMP”-Projekt aufgetragen. Ziel war es einen hochverfügbaren Webserver mit einer WordPress-Installation zur Verfügung zu stellen. Wir haben das Projekt in drei Teilbereiche aufgeteilt: LoadBalancer, Webserver und Datenbank. Nach erfolgreicher Zusammenarbeit haben wir das Projekt fertiggestellt und gemeinsam präsentiert.

Um Einblicke in andere Abteilungen zu bekommen, wurden wir in den daurauffolgenden Wochen aufgeteilt. Afeef durfte Managed Service unterstützten indem er ein automatisiertes Grafana-Dashboard mittels Puppet konfigurieren sollte. Besonders gefallen hat Ihm dabei die Hilfsbereitschaft der Kollegen aus Managed Service die Ihm bei Fragen über Puppet sofort geholfen haben. Meine Aufgabe war es derweil einen Maillserver aufzusetzen. Damit der Mailserver auch leicht zu benutzen ist, implementierte ich eine WebGUI mittels Roundcube.  Schon stand ein Wechsel zur Events-Abteilung an, die ich im November besuchen durfte. Ich half dabei, dass Schulungen richtig geplant und durchgeführt werden. In dieser Zeit kümmerte sich Killian um die neuen Schulungslaptops und konfigurierte ein neues Backupsystem namens ReaR. Schon stand auch die OSMC im November an, eine Premiere für uns Drei. Damit alle Vorträge auch aufgenommen werden hatten wir die ehrenvolle Aufgabe, als Raumwächter jeden Vortrag aufzunehmen, damit man diesen später anschauen kann.

Das nächste große Highlight war die Teilnahme unserer ersten NETWAYS-Schulung. “Fundamentals for Puppet” stand auf dem Programm, welche eine komplett neue Erfahrung für uns drei war. Damit meine ich nicht nur die technische Seite sondern auch, wie von NETWAYS gewohnt, die herzliche Umgangsweise und die super Verpflegung.

Damit wir das Gelernte gleich umsetzen können, stand das nächste große Projekt an und zwar mit Puppet. Killians Aufgabe ist es einen LAMP-Stack mittels Puppet zu realisieren, dazu benötigt er das Wissen von unserem ersten gemeinsamen LAMP-Projekt. Afeef kümmert sich derzeit weiter um das Grafana-Dashboard und ich realisiere meinen zuvor erstellten Mailserver mittels Puppet.

Philipp Dorschner

Autor: Philipp Dorschner

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the roots" quasi!

Benutzername und Kennwort war gestern: SSH-Key

Heute möchten wir euch zeigen wie man die Authentifizierung gegen ein OpenSSH-Server mittels SSH-Key realisiert.

Unser Schlüsselpärchen erzeugen wir mit dem Befehl ssh-keygen und übergeben die Option -t rsa und -b 4096.  Die Option -t definiert welcher Algorithmus und -b welche Schlüssellänge genutzt werden soll:

root@icinga2-node1a:~# ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
-cutted output- root@icinga2-node1a
The key's randomart image is:
+---[RSA 4096]----+
| .... .=. . |
| o o.+oo.+. . |
| . + o+oE. . |
| . o.o + |
| S. + . |
| . .. |
| . |
| |
| |
+-----------------+
root@icinga2-node1a:~#

Wir sehen in der Ausgabe den Punkt “Enter passphrase”, dort sollte man unbedingt ein Kennwort vergeben. Da es sonst dem Szenario gleich kommen würde, dass wir unsere EC-Karte ohne PIN betreiben!

Alternativ kann man die Schlüssel auch mit einer Elliptische-Kurven-Kryptografie erzeugen. Hierzu bietet sich die Elliptische-Kurve ed25519 an, die ab OpenSSH 6.5 unterstützt wird:

root@icinga2-node1a:~# ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_ed25519.
Your public key has been saved in /root/.ssh/id_ed25519.pub.
The key fingerprint is:
-cutted output- root@icinga2-node1a
The key's randomart image is:
+--[ED25519 256]--+
| . |
| o |
| . E |
| o + o |
| = S o . |
| + + + . |
| +.* o |
| ..+* |
|.o.o oo |
+-----------------+
root@icinga2-node1a:~#

 

Sofern man den Pfad während der Generierung nicht verändert hat findet man die Zertifikate unter:

root@icinga2-node1a:~# ls -la ~/.ssh/
total 28
drwx------ 2 root root 4096 Jan 26 12:26 .
drwx------ 5 root root 4096 Jan 25 17:04 ..
-rw------- 1 root root 464 Jan 26 12:09 id_ed25519
-rw-r--r-- 1 root root 101 Jan 26 12:09 id_ed25519.pub
-rw------- 1 root root 3326 Jan 26 12:26 id_rsa
-rw-r--r-- 1 root root 745 Jan 26 12:26 id_rsa.pub
-rw-r--r-- 1 root root 666 Jan 25 10:29 known_hosts
root@icinga2-node1a:~#

 

Für die Verteilung unseres Öffentlichen Schlüssels wird bereits einen Befehl mitgeliefert:

root@icinga2-node1a:~# ssh-copy-id netways@icinga2-node1b
The authenticity of host 'icinga2-node1b (192.168.56.12)' can't be established.
ECDSA key fingerprint is -cutted output-
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
netways@icinga2-node1b's password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'netways@icinga2-node1b'"
and check to make sure that only the key(s) you wanted were added.

root@icinga2-node1a:~#

 

Direkt im Anschluss kann man testen ob der Verbindungsaufbau mittels SSH-Key funktioniert:

root@icinga2-node1a:~# ssh netways@icinga2-node1b
Enter passphrase for key '/root/.ssh/id_rsa':

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Wed Jan 24 18:22:11 2018 from 192.168.56.1
netways@icinga2-node1b:~$

 

Im letzten Schritt müssen wir unserem OpenSSH-Server die Anmeldung per Benutzername und Kennwort abgewöhnen. Hierzu editieren wir folgenden Optionen in unserer OpenSSH-Server Konfiguration:

icinga2-node3b:~# vi /etc/ssh/sshd_config

--- #PasswordAuthentication yes
+++ PasswordAuthentication no

--- #AuthorizedKeysFile %h/.ssh/authorized_keys
+++ AuthorizedKeysFile %h/.ssh/authorized_keys

--- PermitRootLogin no
+++ PermitRootLogin without-password

icinga2-node3b:~# service sshd restart

Sobald der Neustart des OpenSSH-Servers abgeschlossen ist, wird nur noch die Anmeldung per SSH-Key akzeptiert. Wenn man sich jetzt regulär verbindet, wird zwar zunächst eine Verbindung aufgebaut, jedoch bei der Übergabe des Benutzernamens die Verbindung mit der Meldung “publickey” beendet.

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

Serveradministration mit ISPConfig 3

Für Administratoren die sich nicht viel mit der CLI (Command Line Interface) beschäftigen wollen, gibt es die Administrationssoftware ISPConfig 3, eine Open-Source Software für Linux.

Dieses Tool ermöglicht eine umfangreiche Verwaltung von einem oder mehreren Server durch ein webbasiertes Front-End, welches jedoch vorher über die CLI installiert wird. 🙂

Die Installation kann sowohl auf physischen sowie auf virtuellen Servern erfolgen und unterstützt werden die Distributionen:

  • Debian 5 – 9 (empfohlen)
  • Ubuntu 8.10 – 17.10 (empfohlen)
  • CentOS 5.2 – 7
  • Fedora 10 und 12  20
  • OpenSUSE 11.1 – 13.1

Die Zugriffsebenen teilen sich auf den Administrator, Wiederverkäufer und Kunden ein. Kunden und Wiederverkäufer können auf der Weboberfläche einfach über Kunden > Kunde/Reseller hinzufügen, hinzugefügt werden.

Automatisierte Installation der Konfigurationsoberfläche und der jeweiligen Server-Dienste wie E-Mailserver, Webserver, DNSserver, Dateiserver, Datenbankserver, vServer und XMPP Server durch einen Script, machen es dem unerfahrenen Linux Benutzer um einiges einfacher. Über die Oberfläche lassen sich Webseiten mit letsencrypt wie aus Magie kostenlos mit gültigen Zertifikaten signieren.

Unterstützte werden die Daemons:

  • HTTP: Apache2 und nginx
  • SMTP: Postfix
  • POP3/IMAP: Courier und Dovecot (1.2.x)
  • FTP: PureFTPd
  • DNS: BIND und MyDNS
  • Datenbank: MySQL
  • Statistiken: Webalizer und AWStats
  • Virtualization: OpenVZ

 

Quick-Guide für Ubuntu und Debian

Bitte nur auf einem frischen Server ohne jegliche Vorinstallationen ausführen um Probleme zu vermeiden.

Vorbereitung

apt-get update && apt-get -y upgrade
apt-get install -y unzip 
cd /tmp
wget --no-check-certificate -O installer.tgz "https://github.com/servisys/ispconfig_setup/tarball/master"
tar zxvf installer.tgz

Installation

cd *ispconfig*
bash install.sh

Die Installation erfolgt dann durch Beantwortungen von Fragen im auswählbaren Experten- oder Standartmodus, dazu gehört auch die Wahl zwischen der Einrichtung von einem Master- oder Slaveserver (Automatisiert nur im Expertenmodus und nur unter Debian).

Shall this server join an existing ISPConfig multiserver setup (y,n) [n]: y

Beispielsweise wird als erstes auf Server1 eine Masterinstallation durchgeführt, danach muss auf Server2 bei einer Slaveinstallation der Hostname und die dazugehörigen Datenbankinformationen des Server1, nach der bejahten Frage ob bereits ein Multiserver setup existiert, eingetragen werden. Der Rest wird dann im Hintergrund automatisch erledigt.

Weitere Informationen und Features zum ISPConfig 3: klick mich

Demo ISPConfig 3: klick mich

Nach der Installation erspart man sich als Admin einiges an Tipparbeit und vermeidet dadurch fatale Konfigurationsfehler.

Ufuk Sentuerk

Autor: Ufuk Sentuerk

Ufuk ist seit 2015 bei NETWAYS. Er macht seit September eine Ausbildung zum Fachinformatiker für Systemintegration. Sein Interesse für Computer war schon im Grundschulalter groß. In seiner Freizeit spielt Ufuk außerdem gern Gitarre oder verbringt die ein oder andere Stunde beim Lauftraining.

Userspace-Tracing mit DTrace

Als Entwickler habe ich oft das Problem, dass mir auf Produktionssystemen die Sichtbarkeit auf Programminterna fehlt: Wie viele Requests verarbeitet mein Programm gerade pro Sekunde? Ist die Queue aktuell voll?

Nun kann man anfangen, an allen möglichen Stellen Logeinträge zu schreiben. Allerdings wirken sich diese zum einen auf die Performance aus (nichts ist gratis, auch und gerade das Schreiben von Logs nicht) und zum anderen ist es extrem mühsam, die so gesammelten Daten im Anschluss in ein annehmbares Format zu bringen, um wirklich eine Aussage über die Performance treffen zu können. Andere Tools wie rr und valgrind sind dagegen zum Debuggen sehr praktisch, verlangsamen die ausgeführten Programme jedoch extrem, weswegen sie sich nicht für den produktiven Einsatz eignen.

Einen Lösungsansatz bieten hier Tracing-Frameworks. Hierzu liefert das eigene Programm bei bestimmten Ereignissen (z.B. wenn ein Request verarbeitet wurde) strukturierte Daten (z.B. Länge des Requests, Anzahl der Ergebnisse, o.ä.). Diese werden vom Tracing-Framework gesammelt und aufbereitet. Ein solches Framework ist DTrace. Es wurde ursprünglich von Sun Microsystems für Solaris entwickelt, ist allerdings auch für macOS verfügbar. Zudem bietet SystemTap unter Linux Kompatibilität für Teile der DTrace-Infrastruktur.

DTrace erlaubt es, interessante Stellen in den eigenen Programmen mit Probes auszustatten:

provider icinga {
	probe wq__full(void *wq);
	probe wq__starved(void *wq);
	probe wq__task__interleaved(void *wq);
	probe wq__task__begin(void *wq);
	probe wq__task__end(void *wq);
};

Zur Laufzeit des Programms sind diese Probes zunächst nicht aktiv und verursachen keinen Overhead. Dies erlaubt es, Probes auch in Release-Versionen mit auszuliefern, was das Analysieren von Performance-Problemen erleichtert, da nicht erst spezielle Pakete installiert werden müssen.

DTrace kann Probes je nach Bedarf aktivieren und auch wieder deaktivieren, auch wenn das Programm bereits läuft. Auch können Ereignisse mit DTrace-Scripts direkt in Relation zueinander gesetzt werden, um z.B. die Dauer zwischen zwei Ereignissen zu erfassen:

$ cat wq.d
icinga$target:::wq-task-begin
{
	self->ts = timestamp;
}

icinga$target:::wq-task-end
{
	@ = quantize(timestamp - self->ts);
}

Dieses Script können wir nun verwenden, um eine bereits laufende Icinga-Instanz zu analysieren:

$ ps ax | grep icinga2
56711 s003  R+     0:00.00 grep icinga2
56685 s006  R+     0:05.68 /Users/gunnar/i2/lib/icinga2/sbin/icinga2 daemon
56705 s006  S+     0:00.05 /Users/gunnar/i2/lib/icinga2/sbin/icinga2 daemon
$ sudo dtrace -s wq.d -p 56685
dtrace: system integrity protection is on, some features will not be available

dtrace: script 'wq.d' matched 2 probes
^C


           value  ------------- Distribution ------------- count
          524288 |                                         0
         1048576 |@                                        5
         2097152 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@       160
         4194304 |@@@                                      14
         8388608 |                                         1
        16777216 |                                         0
        33554432 |                                         0
        67108864 |                                         0
       134217728 |                                         0
       268435456 |                                         1
       536870912 |@                                        3
      1073741824 |                                         0
      2147483648 |                                         0
      4294967296 |                                         0
      8589934592 |                                         0
     17179869184 |                                         0
     34359738368 |                                         0
     68719476736 |                                         0
    137438953472 |@                                        4
    274877906944 |                                         0

$

Mein Ziel ist es, in absehbarer Zeit in Icinga 2 offiziell Support für DTrace einzubauen. Mal schauen, was sich damit dann alles rausfinden lässt. 🙂

Gunnar Beutner

Autor: Gunnar Beutner

Vor seinem Eintritt bei NETWAYS arbeitete Gunnar bei einem großen deutschen Hostingprovider, wo er bereits viel Erfahrung in der Softwareentwicklung für das Servermanagement sammeln konnte. Bei uns kümmert er sich vor allem um verschiedene Kundenprojekte, aber auch eigene Tools wie inGraph oder Icinga2.