How to use ext4 beyond 16TiB

Using large file systems with several terabytes of data is quite common. Usually system administrators use well-known file systems like ext4, xfs, zfs or newcomers like btrfs. Even ext4, the more or less standard Linux file system, supports up to 10 EiB of data and is marked as stable since Kernel 2.6.28 (release in December 2008). Increasing volumes beyond 16 TiB shouldn’t be a problem.

In the case of ext4 this is only true if the file system was explicitly created with the 64bit feature enabled, which isn’t the default on recent Linux distributions like Ubuntu 16.04. Without 64-bit support your ext4 volumes are limited to 16TiB of data. The 64bit feature is enabled by default since e2fsprogs >= 1.43, but this version isn’t packed for many Linux distributions yet.

 

Fortunately converting a 32-bit ext4 volume to 64-bit is supported since e2fsprogs >= 1.43. A online conversion is not possible.


  1. download and compile e2fsprogs, at least version 1.43
    $ git clone -b v1.43 https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git e2fsprogs
    $ cd e2fsprogs
    $ ./configure
    $ make
    $ cd resize2fs
    $ ./resize2fs
    
  2. unmount the file system
  3. run fsck and repair your file system
  4. run resize2fs with the -b flag to enable the 64bit feature
    $ resize2fs -b /dev/my-block-device
    
  5. check if 64bit feature is enabled
    $ tune2fs -l /dev/my-block-device
    

Depending on your number of inodes the file system check and the conversion to 64-bit can took a lot of time. For resizing or running a file system check you should use at least the latest minor release of e2fsprogs of 1.42.x


For a more detailed information, just have a quick look into the Release notes of e2fsprogs and on AskUbuntu.
Achim Ledermueller

Autor: Achim Ledermueller

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Postfix – SPF, DKIM und DMARC

In der heutigen Zeit werden E-Mails oftmals nicht mehr über einen einzelnen Server verschickt. Wie sollten große Anbieter es sonst schaffen alle E-Mails Ihrer Millionen Nutzer zeitnah abzuhandeln? Spätestens wenn es zu Versand von Newslettern kommt, wird auf mehrere Server zurückgegriffen, damit zum Beispiel E-Mails der Mitarbeiter nicht in einer Warteschlange landen mit 100.000 Newslettern.

Damit diese Server vom Empfänger verifiziert werden können wurden die Mechanismen SPF, sowie DKIM eingeführt. Basierend auf diesen beiden kam später noch DMARC hinzu. Im folgenden möchte ich beschreiben, wie man diese Mechanismen mit Postfix verbindet und entsprechende Informationen publiziert.

 

SPF – Sender Policy Framework

Fangen wir mit SPF an. Bei SPF wird im DNS einer Domain ein TXT-Record hinterlegt. Dort gibt man in einer bestimmten Syntax an, welche Server für diese Domain verifiziert sind. Beispielhaft sieht ein SPF Record in etwa so aus:

v=spf1 ip4:1.2.3.4 ip4:1.2.3.5 a:mx.domain.tld include:other-domain.tld ?all

Dieser sagt aus, dass Mails von der IPv4 Adresse 1.2.3.4 und 1.2.3.5 verschickt werden dürfen, sowie vom Server hinter dem A-Record mx.domain.tld. Zudem sollen die Einstellungen der Domain other-domain.tld included werden und über alle anderen soll keine weiter Aussage getroffen werden mit ?all. Mit “-all” würde man den Versand über alle anderen Mailserver verbieten. Dies kann jedoch zu Problemen führen in Szenarien, wie Beispielsweise bei der Weiterleitung von Mails. Bitte beim include aufpassen, hier gibt man einiges aus der Hand, wenn “other-domain.tld” nicht von einem selbst verwaltet wird.

SPF mit Postfix verbinden

apt-get install postfix-policyd-spf-python

Anschließend öffnen wir die Datei /etc/postfix/master.cf und fügen folgendes hinzu:

postfix-policyd-spf unix – n n – 0 spawn user=policyd-spf argv=/usr/bin/policyd-spf

Und um die policy auch zu verwenden, editieren wir die smtpd_recipient_restrictions in /etc/postfix/main.cf. Bitte beachtet, dass ihr diese unbedingt NACH reject_unauth_destination einfügt.

smtpd_recipient_restrictions = … reject_unauth_destination check_policy_service unix:private/postfix-policyd-spf …

Danach restarten wir postfix. Bei eingehenden Mails sollte nun ein Header enthalten sein, der in etwa wie folgt aussieht:

Received-SPF: Pass (sender SPF authorized) …

Weitere Einstellungen kann man noch unter /etc/postfix-policyd-spf-python/policyd-spf.conf vornehmen.

 

DKIM – DomainKeys Iidentified Mail

DKIM verfolgt ebenfalls das Ziel den Absender zu verifizieren, jedoch mit anderem Ansatz. Dabei werden Headerdaten, die man auch selbst definieren kann mittels eines privaten Schlüssels signiert, während sich der öffentliche Schlüssel im DNS der jeweiligen Domain befindet. Wo dieser genau zu finden ist, bestimmt der Selector – dazu aber gleich noch mehr. Sollte man die Headerdaten, welche signiert werden sollen, selbst definiert, sollte man unbedingt darauf achten, dass es Header sind, die im Verlauf des Versands nicht verändert werden, mehr dazu aber auch im RFC6376 – Abschnitt 5.4.

Beide Verfahren dienen nur dazu den Absender zu verifizieren, es bietet daher keinen Spamschutz im eigentlichen Sinn, wie manche sich vielleicht erhoffen. Sie sind aber relativ schnell eingerichtet und manche Mailserver und Dienste bewerten Mails mit gültigem SPF und DKIM besser, daher ist die Einrichtung kein absolutes “Muss”, aber dennoch ein “Nice-to-have”.

OpenDKIM mit Postfix verbinden

apt-get install opendkim opendkim-tools

Bevor wir nun mit opendkim und postfix weiter machen generieren wir erst einmal Keys, die wir verwenden möchten:

mkdir -p /etc/opendkim/keyfiles/domain1.tld
cd /etc/opendkim/keyfiles/domain1.tld
opendkim-genkey -s mail -d domain1.tld

Damit werden zum einen die Datei mail.private generiert, die den privaten Schlüssel beinhaltet, sowie mail.txt. welche den öffentlichen Schlüssel beinhaltet. Der oben genannte Selector ist “mail”. Den öffentlichen Schlüssel können wir daher schon im DNS der Domain domain1.tld hinterlegen. Dabei handelt es sich um einen Textrecord, der in unserem Beispiel unter mail._domainkey.domain.tld hinterlegt sein muss. Ist dies erledigt geht es weiter in der Konfiguration.

Anschließend ist die Datei /etc/opendkim.conf wichtig, hier wird die zentrale Konfiguration von opendkim vorgenommen. Beispielsweise so kann eine Konfiguration aussehen:

Mode sv
AutoRestart Yes
AutoRestartRate 10/1h
UMask 002
UserID opendkim:opendkim
Syslog yes
KeyTable /etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
Canonicalization relaxed/relaxed
LogResults yes
LogWhy yes
SyslogSuccess yes
Socket inet:10080@localhost
SignatureAlgorithm rsa-sha256

Wichtig sind hier zum einen der Port, zum anderen aber natürlich die beiden Parameter KeyTable und SigningTable. Weitere Konfigurationsparameter kann man in der Dokumentation der offiziellen Seite von opendkim nachlesen. Gehen wir aber weiter in unserem Beispiel. Ein Keytable kann z.B. wie folgt aussehen:

mail._domainkey.% %:mail:/etc/opendkim/keyfiles/domain.tld/mail.private

Das “%” in diesem Beispiel ist ein Platzhalter für die jeweilige Domain. Es werden daher alle Domains mit dem privaten Schlüssel signiert, welcher unter /etc/opendkim/keyfiles/domain.tld/mail.private liegt. Als selector wird “mail” verwendet. Sollte man für jede Domain einen anderen Key verwenden, was auch im Normalfall so ist, dann kann man einfach folgende Änderungen vornehmen:

mail._domainkey.domain1.tld domain1.tld:mail:/etc/opendkim/keyfiles/domain1.tld/mail.private
mail._domainkey.domain2.tld domain2.tld:mail:/etc/opendkim/keyfiles/domain2.tld/mail.private

Kommen wir zum SigningTable. Hier wird festgelegt, welche Mails mit welchem Eintrag im KeyTable signiert werden.

*@domain1.tld mail._domainkey.domain1.tld
*@domain2.tld mail._domainkey.domain2.tld

Auch hier kann man aber mit Wildcards und Platzhaltern arbeiten und Beispielsweise folgenden Eintrag setzen.

* mail._domainkey.%

Damit wird jede Mail signiert, mit mail._domainkey.<Name der Domain>

Will man nun noch postfix mit opendkim verbinden, ist es relativ einfach. Hier werden einfach entsprechende Einträge in der /etc/postfix/main.cf angehängt:

milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:localhost:10080
non_smtpd_milters = inet:localhost:10080

Danach einfach noch beide Services restarten und schon werden alle Mails entsprechend signiert.

 

DMARC – Domain-based Message Authentication, Reporting & Conformance

Mit DKIM und SPF haben wir schon zwei Mechanismen, mit denen ich als Absender gewisse Informationen weitergeben kann. Was der Empfänger damit anstellt ist jedoch ihm selbst überlassen. Lehnt Mailserver A eine Mail ab, weil der SPF Check fehlschlägt, lässt Mailserver B die Mail mit höherem Spamscore vielleicht durch. Die Bewertung liegt beim Empfänger, der neben SPF und DKIM noch viele weitere Checks implementiert hat um Spam entsprechend abzuwehren. Die Entscheidung, was nun mit der Mail im besten Fall passieren soll, soll DMARC dem Empfänger erleichtern und dem Sender ein wenig mehr Möglichkeiten geben.

Als Absender hinterlege ich im DNS einen entsprechenden Eintrag. Hier gibt es einige Variablen und zugehörige Optionen, die man setzen kann. Der Empfänger hingegen kann diese Empfehlung, die vom wirklichen Inhaber der Domain kommt nutzen um zu entscheiden was er mit der Mail passieren soll. Der DMARC Eintrag von Google sieht Beispielsweise wie folgt aus:

v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:mailauth-reports@google.com

Dies dient lediglich als Beispiel, wer mehr über die Parameter und Optionen lesen möchte sollte den zugehröigen RFC7489 genauer ansehen

Damit ist auch schon alles getan, was man als Absender machen kann. Wichtig dabei ist der p-Parameter, der auf none (keine Aussage, Entscheidung liegt weiter beim Empfänger), quarantine (Dem Empfänger wird geraten bei einem fehlerhaften Check die Mail als Spam zu betrachten und ggf. in einen Spamordner zu verschieben), oder reject (Die Mail soll auf SMTP Ebene bereits abgelehnt werden) gesetzt werden kann. Es ist schwer hierbei eine Empfehlung oder ähnliches auszusprechen, da es immer auf den Fall an sich ankommt, welche Features man von DMARC im gegebenen Szenario verwenden möchte.

OpenDMARC mit Postfix verbinden

apt-get install opendmarc

Anschließend editieren wir die Datei /etc/default/opendmarc. Hier sind schon einige Beispiele angegeben und sind auch sehr selbsterklärend. Wir tragen folgendes ein:

SOCKET=”inet:12345@localhost”

Nun editieren wir noch die Konfiguration von DMARC, welche unter /etc/opendmarc.conf zu finden ist.

AuthservID mx.domain.tld
PidFile /var/run/opendmarc.pid
RejectFailures false
Syslog true
SyslogFacility mail
TrustedAuthservIDs localhost,mx.domain.tld
IgnoreHosts /etc/opendmarc/ignore.hosts
UMask 002
UserID
FailureReports false
AutoRestart true
HistoryFile /var/log/opendmarc.log
RecordAllMessages true
SoftwareHeader true

Danach editieren wir noch /etc/opendmarc/ignore.hosts

127.0.0.1

Die Option “SoftwareHeader true” ist eher für eure ersten Tests von Vorteil, da ihr in einem weiteren Header die verwendete Version und verarbeitete E-Mail sehen könnt:

DMARC-Filter: OpenDMARC Filter v1.3.1 mx.domain.tld A3DF6FFB75

Anschließend geht es an die Integration von OpenDMARC in Postfix. Da es sich hierbei um einen Mailfilter handelt, wird er an der bereits bekannten Stelle in der main.cf nach unserem DKIM Milter eingetragen.

smtpd_milters = inet:localhost:10080, inet:localhost:12345
non_smtpd_milters = inet:localhost:10080, inet:localhost:12345

Danach starten wir OpenDMARC und restarten Postfix. Nun sollten E-Mails einen Header enthalten, der in etwa so aussieht, falls der DMARC-Check erfolgreich war:

Authentication-Results: mx.domain.tld; dmarc=pass header.from=sender-domain.tld

Angemerkt sei, dass opemdmarc seit Version 1.3 auch selbst SPF Checks ausführen kann, falls es also bei jemandem Probleme geben sollte mit postfix-policyd-spf, kann auch der eigene SPF Check verwendet werden.

Fabian Rothlauf

Autor: Fabian Rothlauf

Fabian kehrte nach seinem fünfjährigen Ausflug nach Weimar zurück in seine Geburtsstadt Nürnberg und hat im September 2016 bei NETWAYS als Systems Engineer im Hosting Support angefangen. Der Mopsliebhaber, der schon seit seinem 16. Lebensjahr ein Faible für Adminaufgaben hat, liebt außerdem Grillen, Metal und Computerspiele. An seinem Beruf reizt ihn vor allem die Abwechslung, gute Weiterentwicklungsmöglichketen und dass es selten mal einen Stillstand gibt. Nachdem er die Berufsschulzeit bereits mit Eric und Georg genießen durfte, freut er sich bei NETWAYS nun auf weitere nette Kollegen, interessante Aufgaben und neue Blickwinkel.

How to: Icinga 2 – CA Proxy

Die in Kürze erscheinende Icinga-Version 2.8 erweckt den CA-Proxy zum Leben. Mit diesem Blogpost möchte ich nun zeigen, wie man dieses Feature verwendet und wozu es nützlich ist.

Was bringt der CA-Proxy?
Am besten ist dies anhand eines Beispiels zu erklären. Man nehme an, das Setup besteht aus einem Master, einem Satellite und mehreren Clients. Während der Einrichtung dieses Setups muss man bisher für jeden Client ein Ticket auf dem Master erstellen und eine direkte Verbindung zum Master haben, was nicht in allen Setups immer möglich oder einfach ist.

Der CA-Proxy ermöglicht es nun, Certificate-Signing-Requests nicht direkt an den Master, sondern an einen Satellite zu senden. Der Satellite leitet den Request dann an den Master weiter.

Mit Version 2.8 kommt zudem die Möglichkeit hinzu, ein Certificate-Signing-Request an den Master zu senden, ohne vorher ein Ticket zu erstellen. Diese Requests können danach am Master manuell beantwortet bzw. das Zertifikat signiert werden.

Durch die Kombination dieser beiden Features, muss weder der Master, noch ein Ticket im Node-Wizard angegeben werden. Firewalls, die den Master abschirmen, stellen hier auch kein Problem mehr da, solange der Client den Satellite erreichen kann.

Einrichtung eines Clients
Auf dem Client muss nun der Node-Wizard ausgeführt werden. Hier kann, wie vorher erwähnt, das Ticket einfach leer gelassen werden:

root@icinga-agent-1:~# icinga2 node wizard
Welcome to the Icinga 2 Setup Wizard!

We will guide you through all required configuration details.

Please specify if this is a satellite/client setup ('n' installs a master setup) [Y/n]: y

Starting the Client/Satellite setup routine...

Please specify the common name (CN) [icinga-agent-1]: [ENTER]

Please specify the parent endpoint(s) (master or satellite) where this node should connect to:
Master/Satellite Common Name (CN from your master/satellite node): icinga-satellite-1

Do you want to establish a connection to the parent node from this node? [Y/n]: y
Please specify the master/satellite connection information:
Master/Satellite endpoint host (IP address or FQDN): 10.211.55.23
Master/Satellite endpoint port [5665]: [ENTER]

Add more master/satellite endpoints? [y/N]: n
Parent certificate information:

Subject: CN = icinga-satellite-1
 Issuer: CN = icinga-satellite-1
 Valid From: Nov 8 11:37:56 2017 GMT
 Valid Until: Nov 4 11:37:56 2032 GMT
 Fingerprint: BA 1F 61 BE 26 8E CB 4E 8B 4D 20 3F 10 5B D5 0C C4 BF 91 00

Is this information correct? [y/N]: y

Please specify the request ticket generated on your Icinga 2 master (optional).
 (Hint: # icinga2 pki ticket --cn 'icinga-agent-1'): [ENTER]

No ticket was specified. Please approve the certificate signing request manually
on the master (see 'icinga2 ca list' and 'icinga2 ca sign --help' for details).

Please specify the API bind host/port (optional):
Bind Host []: [ENTER]
Bind Port []: [ENTER]

Accept config from parent node? [y/N]: y
Accept commands from parent node? [y/N]: y

Reconfiguring Icinga...

Done.

Now restart your Icinga 2 daemon to finish the installation!
root@icinga-agent-1:~# systemctl restart icinga2

 

Danach können wir auf dem Master über “icinga2 ca list” alle Requests anzeigen lassen:

root@icinga-master-1:~# icinga2 ca list
Fingerprint        | Timestamp                | Signed | Subject
-------------------|--------------------------|--------|--------
92a2e5bbb9b374f... | Nov  8 11:43:06 2017 GMT |        | CN = icinga-agent-1

 

Und mit “icinga2 ca sign <fingerprint>” signieren:

root@icinga-master-1:~# icinga2 ca sign 92a2e5bbb9b374f...
information/cli: Signed certificate for 'CN = icinga-agent-1'.

Nach einigen Minuten sollten die signierten Zertifikate auf den Clients landen. Hierfür ist kein Neustart nötig.

Noah Hilverling

Autor: Noah Hilverling

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter, oder schwingt sich auf sein Mountainbike.

Training: Fundamentals for Puppet erweitert

Seit letzter Woche erst online und schon eine Erweiterung! Im neuen Release v1.1.1 sind nun zwei Definitionen zu Vagrant Boxen für den in der Schulung verwendeten Puppetmaster, sowie den CentOS-Agenten enthalten. Die Markup Datei Setup.md beschreibt die Voraussetzungen und wie die Virtuellen Maschinen benutzt werden können.

Die Boxen sind wie in der Schulung beschrieben via SSH erreichbar oder mittels vagrant ssh. Das Root-Passwort ist allerdings, wie bei Vagrant üblich, natürlich ‘vagrant’.

Fehlerreports sind wie immer herzlich willkommen und sollten via GitHub bei uns eingekippt werden. Aber auch sonstige Rückmeldung, die Schulung betreffend, sind herzlich willkommen, auch über Inhalt und Schwerpunkte.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Fundamentals for Puppet Goes Public

Heute geben wir bekannt, dass nach Veröffentlichung der Schulungsunterlagen unserer Foreman Schulung, auch die Unterlagen zum Kurs Fundamentals for Puppet als Github Pages und im Source-Code zum nicht kommerziellen Gebrauch bereit stehen. In den kommenden Wochen und Monaten werden Veröffentlichungen zu den weiterführenden Puppetschulungen folgen.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Systemd-Unitfiles kurz erklärt

Tux
Nachdem ich feststellen musst, dass immer noch der ein oder andere mit Systemd und den Unitfiles auf Kriegsfuß steht und mit tieferem Wissen manches Problem zu vermeiden wäre, will ich mit ein paar kurzen Erklärungen Abhilfe schaffen.

Systemd hat als Ersatz für init bereits 2010 angefangen in die verschiedenen Distributionen Einzug zu halten und ist mittlerweile Standard. Somit haben auch die alten init-Skripte ausgedient und wurde durch Unitfiles ersetzt. Auf den ersten Blick lassen diese weniger Optionen zu, aber sobald man sich etwas weiter mit den Einstellmöglichkeiten auseinandersetzt, wird man wohl nichts an Funktionalität vermissen.

Für die Erläuterungen möchte ich ein Beispiel nehmen, dass vielleicht der ein oder andere schon kennt, und habe mich darum für Icinga 2 entschieden. Dieses findet sich in /usr/lib/systemd/system als icinga2.service und sieht folgendermaßen aus:

[Unit]
Description=Icinga host/service/network monitoring system
After=syslog.target network-online.target postgresql.service mariadb.service carbon-cache.service carbon-relay.service

[Service]
Type=forking
EnvironmentFile=/etc/sysconfig/icinga2
ExecStartPre=/usr/lib/icinga2/prepare-dirs /etc/sysconfig/icinga2
ExecStart=/usr/sbin/icinga2 daemon -d -e ${ICINGA2_ERROR_LOG}
PIDFile=/run/icinga2/icinga2.pid
ExecReload=/usr/lib/icinga2/safe-reload /etc/sysconfig/icinga2
TimeoutStartSec=30m

[Install]
WantedBy=multi-user.target

Als erstes möchte ich auf den Pfad selbst eingehen. Diese muss per Konvention heißen wie der Service, der über sie gesteuert wird, und auf .service enden, damit sie von anderen Units unterscheidbar ist. Andere Units wären beispielsweise Sockets für die socketbasierende Aktivierung oder Targets als Gruppierung von Services und Ersatz für die Runlevel. Der Pfad /usr/lib/systemd/system ist hierbei der Ablageort für Package-Maintainer und kann mit Dateien in /run/systemd/system oder /etc/systemd/system überschrieben werden, wobei letzteres für den Administrator gedacht ist.

Die Datei selbst ist dann im Ini-Format, heißt es gibt verschiedene Sektion wie [Unit] und Key-Value-Paare, die in der entsprechenden Sektion sein müssen. In der Sektion [Unit] finden sich somit allgemeine Einstellungen die bei jedem Unit-Typen vorkommen können, in diesem Fall die Beschreibung und mit After eine Liste von Units, die wenn vorhanden vor Icinga 2 gestartet sein sollen. Die Manpage systemd.unit gibt hierüber detailliert Auskunft.

In der für den Unit-Typ spezifischen Sektion in unserem Fall [Service] werden dann weitere Einstellungen vorgenommen. Hier wird Systemd gesagt wie das Startverhalten des Dienstes ist denn standardmäßig möchte Systemd Dienste im Vordergrund starten im Gegensatz zum Standardverhalten von init bei dem sich der Dienst in den Hintergrund forkt. Über EnvironmentFile, zusätzliche Skripte in ExecStartPre oder ExecStartPost und den eigentlich Aufruf des zu startenden Dienst mittels ExecStart wird das frühere init-Skript abgelöst. In Fall von Icinga2 wird im Pre-Skript sichergestellt, dass benötigte Verzeichnisse existieren und entsprechend berechtigt sind. Zusätzlich wird der Reload-Mechanismus durch ein Skript ersetzt, damit die Konfiguration validiert wird bevor gegebenenfalls der Dienst neugestartet wird. TimeoutStartSec ist prinzipiell selbsterklärend denk ich, nimmt im Gegensatz zu den Sekunden im Namen aber auch andere Einheiten an wie hier 30m für 30 Minuten. Hierbei bitte aufpassen, dass nur der Start-Timeout und nicht der allgemeine Timeout hochgesetzt wird, da letzterer auch für den Shutdown des Systems gilt. Mehr Details liefert die Manpage systemd.service.

Die letzte Sektion gibt an in welches Target der Dienst “installiert” werden soll, wenn systemctl enable ausgeführt wird.

Die Datei unter /usr/lib/systemd/system sollte nicht angepasst werden, da diese beim nächsten Update überschrieben wird. Kopiert man es aber nach /etc/systemd/system muss man die komplette Pflege übernehmen, da es das aus dem Paket gelieferte komplett ersetzt. Hierfür gibt es den Mechanismus der Drop-Ins. Diese müssen in ein Verzeichnis mit dem Namen der Unit abgelegt werden, in unserem Fall /etc/systemd/system/icinga2.service.d und auf .conf enden. Der Name ist hierbei prinzipiell egal, sollte aber sprechend gewählt werden und da sich Eigenschaften überschreiben bietet sich eine Priorität als Präfix an. Beim Inhalt nicht die Sektionsheader vergessen! Auch hierfür ein Beispiel aus Icinga 2:

# Icinga 2 sets some default values to extend OS defaults
#
# Please refer to our troubleshooting documentations for details
# and reasons on these values.
[Service]
TasksMax=infinity

# May also cause problems, uncomment if you have any
#LimitNPROC=62883

Mit dem Kommando systemctl property kann man genau diesen Mechanismus nutzen ohne sich um die Dateistruktur kümmern zu müssen, aber leider funktioniert dies nicht für alle Optionen. Kernel-Parameter, Posix-Limits und vieles mehr lassen sich hier einstellen, welche sich in systemd.exec finden, und Einstellungen für die Kontrolle über Ressourcen, welche Systemd mittels Cgroups umsetzt, finden sich in systemd.resource-control. Die Defaults hierfür finden sich übrigens in /etc/systemd/system.conf und müssen nicht immer gleich heißen, beispielsweise DefaultTasksMax und TasksMax. Die eingebundenen Drop-Ins zeigt systemctl status sehr schön an und die aktuellen Werte für alle Einstellungen eines Services inklusive Defaults liefert systemctl show.

Und abschließend nicht vergessen Systemd die vorgenommenen Änderungen mit systemctl daemon-reload auch mitzuteilen.

Ich hoffe diese kleine Erläuterung hilft dem ein oder anderen Unitfiles besser zu verstehen und er weiß nun wo er hin langen muss wenn Stellschrauben anzupassen sind.

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.