Systemd-Unitfiles und Multi-Instanz-Setups

Tux

Vor einer Weile hab ich bereits eine kurze Erklärung zu Systemd-Unitfiles geschrieben, diesmal will ich auf das Multi-Instanz-Feature von Systemd eingehen, da auch dieses anscheinend nicht jedem bekannt ist.

Als Beispiel soll mir diesmal Graphite bzw. genauer gesagt die Python-Implementierung carbon-cache dienen. Diese skaliert nicht automatisch, sondern erfordert, dass man weitere Instanzen des Dienstes auf anderen Ports startet. Die Konfiguration auf Seiten des carbon-cache ist hierbei recht simpel, denn es wird in einer Ini-Datei nur eine neue Sektion mit den zu überschreibenden Werten geschrieben. Der Sektions-Name gibt hierbei der Instanz den Namen vor. Das ganze sieht dann beispielsweise für Instanz b so aus.

[cache:b]
LINE_RECEIVER_PORT = 2013
UDP_RECEIVER_PORT = 2013
PICKLE_RECEIVER_PORT = 2014
LINE_RECEIVER_PORT = 7102

Mit SystemV hätte man nun das Startskript für jede Instanz kopieren und anpassen müssen, da das mitgelieferte Unitfile leider das Multi-Instanz-Feature nicht nutzt muss ich dies zwar auch einmal tun, aber immerhin nur einmal. Hierbei ist es sinnvoll den Namen zu verändern, um nicht mit dem bestehen in Konflikt zu kommen, wenn man möchte kann man es aber auch durch Verwendung des gleichen Namens “überschreiben”. Für das Multi-Instanz-Feature muss nur ein @ an das Ende des Namens. Baut man nun an entsprechenden Stellen den Platzhalter %i ist auch schon das Multi-Instanz-Setup fertig und man kann einen Dienst mit name@instanz.service starten. In meinem Beispiel wäre dies carbon-cache-instance@b.service mit folgendem Unitfile unter /etc/systemd/system/carbon-cache-instance@.service.

[Unit]
Description=Graphite Carbon Cache Instance %i
After=network.target
 
[Service]
Type=forking
StandardOutput=syslog
StandardError=syslog
ExecStart=/usr/bin/carbon-cache --config=/etc/carbon/carbon.conf --pidfile=/var/run/carbon-cache-%i.pid --logdir=/var/log/carbon/ --instance=%i start
ExecReload=/bin/kill -USR1 $MAINPID
PIDFile=/var/run/carbon-cache-%i.pid
 
[Install]
WantedBy=multi-user.target

Ich hoffe diese kurze Erklärung hilft dem ein oder anderen und ich würde mich freuen zukünftig mehr Dienste, die auf Instanzierung ausgelegt sind, bereits mit einem entsprechenden Unitfile ausgeliefert zu sehen.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

Samba Samba die ganze Nacht

samba.org logoWer in seinem Unternehmen heterogene Umgebungen vorfindet ist oftmals gezwungen Brücken zwischen der Linux/Unix Welt und Windows zu schlagen. Hierfür wird gerne der freie und quelloffene Samba Server eingesetzt. Dieser stellt per SMB Protokoll Freigaben bereit.
Nun ist es eine Sache die Windows Kollegen zu hetzen, alte Windows XP Maschinen abzustellen. Die andere Seite der Medaille ist die Absicherung der eigenen Serverdienste. Denn wenn der Linux Server immer noch SMBv1 spricht ist der nächsten WannaCrypt/WannaCry Attacke Tür und Tor geöffnet. Microsoft warnt z.B. im Technet Blog vor dieser Möglichkeit.

Die Abhilfe dagegen ist relativ einfach, man verbiete SMBv1. Die Änderung erfolgt in /etc/samba/smb.conf innerhalb der “global” section.

 [global]
 ...
 #min protocol = SMB2
 client min protocol = SMB2
 server min protocol = SMB2
 ...

 

Christoph Niemann

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

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.

Max Deparade

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.