Schlagwort-Archiv: Planet

Tag für den Ubuntuusers.de Planeten.

Unit-Typ systemd.path kurz vorgestellt

Mit systemd.path lassen sich Dateien und Verzeichnisse auf bestimmte Ereignisse hin überwachen. Tritt ein spezifiziertes Ereignis ein, wird eine Service-Unit ausgeführt, welche üblicherweise den gleichen Namen, wie die Path-Unit trägt.

Wie dies funktioniert, möchte ich an einem sehr einfachen Beispiel zeigen. Das Ziel ist, die Datei testfile auf Änderungen hin zu überwachen. Immer wenn die Datei nach einem Schreibvorgang geschlossen wird, soll ein bestimmtes Skript gestartet werden.

beispiel.path

Im Verzeichnis /etc/systemd/system/ wird die Datei beispiel.path mit folgendem Inhalt erstellt:

[Unit]
Description=Datei auf Änderungen hin überwachen

[Path]
PathChanged=/home/oglattermann/testfile
Unit=beispiel.service

[Install]
WantedBy=multi-user.target

In der Sektion [Path] wird mit PathChanged= der absolute Pfad zu der zu überwachenden Datei spezifiziert, während Unit= angibt, welche Service-Unit ausgeführt werden soll, wenn sich die Datei ändert. Diese Unit soll gestartet werden, wenn sich das System im Multi-User-Mode befindet.

beispiel.service

Wird die Datei testfile geändert (genau: geschrieben und geschlossen), wird folgende Service-Unit aufgerufen, um das darin spezifizierte Skript auszuführen:

[Unit]
Description=Führt Skript aus, wenn eine Datei sich geändert hat.

[Service]
Type=simple
ExecStart=/home/oglattermann/skript.sh

[Install]
WantedBy=multi-user.target

Das Skript skript.sh enthält dabei in diesem Beispiel lediglich folgenden Code:

#!/bin/bash
echo "Datei geändert" >/home/oglattermann/Output.txt

Für einen Test müssen die beiden soeben erstellten Units noch aktiviert werden:

sudo systemctl enable beispiel.path beispiel.service
sudo systemctl start beispiel.path

Schreibt man nun die Datei testfile neu bzw. wird eine Schreiboperation auf diese Datei abgeschlossen, wird die entsprechende Service-Unit ausgeführt und man findet die Datei Output.txt vor.

Anwendungsbeispiele

Die folgende, unvollständige und nicht abschließende Liste führt einige Anwendungsbeispiele auf, wo sich systemd.path sinnvoll nutzen lässt.

  • Ereignisgesteuerte Datenverarbeitung starten
  • Dateien unter /etc überwachen und bei Änderungen Benachrichtigung versenden
  • Import-Ordner auf neue Dateien hin überwachen und Verarbeitung starten

Quellen und weiterführende Links

Wie kann man mit tcpdump HTTP-Traffic eines bestimmten Hosts sniffen?

Diese Frage wurde bereits von Scott in seinem englischsprachigen Blog beantwortet. Ich gebe sie an dieser Stelle wieder, um nicht immer wieder danach suchen zu müssen.

Das Kommando lautet:

tcpdump -c 20 -s 0 -i eth1 -A host 192.168.1.1 and tcp port http

Die Parameter bedeuten:

  • -c 20: Beendet den Vorgang, nachdem 20 Pakete aufgezeichnet wurden.
  • -s 0: Die mitgeschnittenen Nutzdaten sollen ungekürzt wiedergegeben werden.
  • -i eth1: Zeichne nur Pakete an der Netzwerkschnittstelle eth1 auf.
  • -A: Gebe alle Pakete in ASCII aus.
  • host 192.168.1.1: Zeichne nur Pakete auf, die von Host 192.168.1.1 kommen.
  • and tcp port http: Zeichne nur HTTP-Pakete auf.

Ergänzt man den Befehl noch um -w DATEINAME wird die Aufzeichnung in eine Datei statt auf die Standardausgabe geschrieben.

sht21andrasppi

Raspi-SHT21 Version 2 BETA veröffentlicht

Zwei Jahre sind seit dem letzten Release vergangen. Letztes Wochenende fand ich nun endlich die Zeit, mich wieder mit dem Projekt Raspi-SHT21 zu befassen. Herausgekommen ist die BETA der Version 2.

Alle Informationen zur neuen Version gibt es in den Versionsinformationen auf GitHub und in der README-Datei des Projekts.

Bei mir daheim läuft die neue Version bisher stabil. Da ausführliche Tests fehlen, habe ich sie als BETA markiert. Falls ihr Fehler findet, Fragen habt oder der Meinung seid, dass noch etwas fehlt (Code, Doku, Spendenbutton), eröffnet bitte einen GitHub-Issue oder hinterlasst mir hier einen Kommentar.

In Zukunft soll das Projekt um Remote-Messstationen erweitert werden. Der Raspberry Pi dient dabei als Zentrale zur Speicherung und Visualisierung der Messdaten. Diese werden zukünftig nicht mehr nur ausschließlich vom direkt angeschlossenen SHT21-Sensor geliefert, sondern auch von weiteren Sensoren, die ihre Daten per WLAN übertragen. Sobald es etwas zu zeigen gibt, werde ich in diesem Blog darüber berichten.

Verwandte Artikel

  1. Überwachung von Temperatur und Luftfeuchtigkeit mit dem SHT21
  2. Visualisierung von Umweltdaten

Synology NAS: Einzelnen Ordner neu indizieren

Synology Diskstations stellen Anwendungen bereit, um Bilder, Musik und Videos verwalten zu können. Dies sind im einzelnen

  • die Photo Station,
  • die Audio Station und
  • die Video Station.

Damit die Medien in den jeweiligen Anwendungen angezeigt werden können, müssen diese zuvor indiziert werden. Die Indizierung erfolgt automatisch, wenn Medien über die entsprechende Anwendung hinzugefügt werden. Fügt man sie jedoch auf anderem Wege hinzu, z.B. durch rsync, startet die Medienindizierung nicht und die Medien können in der jeweiligen Anwendung nicht wiedergegeben werden.

Die Benutzeroberfläche „DSM“ bietet lediglich die Möglichkeit, ganz allgemein eine Medienindizierung zu starten. Dabei werden jedoch sämtliche Medien neu indiziert und nicht nur die neu hinzugefügten. Je nach Umfang dauert die Indizierung mehrere Stunden bis Tage. Es gibt jedoch eine Möglichkeit, die Indizierung manuell zu starten und dabei auf ein einzelnes Verzeichnis zu beschränken.

Dazu meldet man sich per SSH an der Diskstation an und führt folgendes Kommando aus:
/usr/syno/bin/synoindex -R /Pfad/zum/Verzeichnis/

Damit lässt sich eine Menge (Rechen-)Zeit sparen.

Ordnung in die Fotosammlung bringen

In diesem Beitrag möchte ich festhalten, wie ich mit dem ExifTool von Phil Harvey [1] ein wenig Ordnung in meine Fotosammlung brachte.

Meine Frau und ich verwenden verschiedene Geräte wie z.B. Smartphones, Tablets und Digitalkameras, um Fotos aufzunehmen. Dabei speichern diese Geräte die aufgenommenen Bilder nach folgenden Namensmustern:

  • IMG_1234.JPG
  • IMG_<YYYYMMDD>_<hhmmss>.jpg

Die so benannten Bilder landen nach Themen sortiert in Verzeichnissen auf einem NAS. Um sie in eine chronologische Reihenfolge zu bringen, möchte ich sie einheitlich nach folgendem Muster benennen:

  • <YYYY-MM-DD>T<hhmmss>_img.jpg

Dazu lese ich das Aufnahmedatum mit dem ExifTool aus den EXIF-Daten [2] der Fotos aus und verwende dies, um die Dateien nach dem gewünschten Muster umzubenennen. Der dazu genutzt Befehl sieht wie folgt aus:

exiftool '-filename<DateTimeOriginal' -d "/Pfad/zum/Zielverzeichnis/%Y-%m-%dT%H%M%S_img%%-c.jpg" Quellverzeichnis/

Mit dem obigen Kommando werden die Dateien aus dem Quellverzeichnis wie gewünscht umbenannt und in das Zielverzeichnis verschoben. Sollte dort bereits eine Datei mit gleichem Namen existieren, wird durch die Option „%%-c“ ein Index angehängt und hochgezählt.

Falls es sich bei dem Zielverzeichnis zufällig um ein Photoalbum einer Synology Diskstation handelt, interessiert euch evtl. auch, wie man einzelne Ordner neu indizieren kann.

[1] ExifTool by Phil Harvey {en}
[2] Exchangeable Image File Format {de}
[3] EXIF metadata privacy: A picture is worth a thousand data points {en}

Zertifikatsanfrage (CSR) mit OpenSSL erstellen

Dieses Tutorial beschreibt, wie eine Zertifikatsanfrage (engl. Certificate Signing Request, kurz CSR) erstellt werden kann. Dabei wird die Erstellung von Anfragen für Zertifikate mit einem und mehreren enthaltenen Hostnamen behandelt. Die nach diesem Tutorial erstellten Zertifikatsanfragen können dann genutzt werden, um sie an eine Zertifizierungsstelle (engl. Certificate Authority, kurz CA) zu übermitteln.

Voraussetzung, um diesem Tutorial zu folgen, ist eine funktionsfähige Installation von OpenSSL. Die Installation von OpenSSL ist nicht Gegenstand dieses Tutorials.

Die folgende Tabelle gibt Auskunft über die Konfigurationen, mit denen dieses Tutorial getestet wurde.

BetriebssystemOpenSSL Version
Ubuntu 16.04 LTSOpenSSL 1.0.2g
CentOS/RHEL 7OpenSSL 1.0.2k-fips
Fedora 26OpenSSL 1.1.0f-fips

Keyfile und CSR in einem Schritt erstellen

Die Dateien für den privaten Schlüssel und den CSR können auf der Kommandozeile mit dem folgenden Befehl erstellt werden. Dabei werden die benötigten Informationen interaktiv abgefragt.

/tmp$ openssl req -newkey rsa:2048 -sha256 -keyout test.key -out test.csr
Generating a 2048 bit RSA private key
..............................................................................................+++
........................................................................................................................+++
writing new private key to 'test.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:NRW
Locality Name (eg, city) []:.        
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:test.example.com
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:.
An optional company name []:.

Die einzelnen Argumente des Befehls sind wie folgt zu erklären:

openssl req ruft das Kommando zur Generierung eines PKCS#10 CSR auf [1]. Das Argument -newkey rsa:2048 gibt an, dass ein neuer RSA-Key mit einer Schlüssellänge von 2048 Bit generiert werden soll. Dieser Schlüssel wird anschließend verwendet, um den CSR zu erzeugen. Mit dem Argument -sha256 wird angegeben, dass das beantragte Zertifikat mit dem SHA256-Algorhytmus signiert werden soll. Man beachte, dass dies von der Zertifizierungsstelle überschrieben werden kann. Mit -keyout test.key wird der Dateiname angegeben, unter dem die Private-Key-Datei (test.key) im aktuellen Verzeichnis gespeichert werden soll. Dementsprechend gibt -out test.csr an, wo die CSR-Datei (test.csr) gespeichert werden soll. Im oben dargestellten Beispiel geschieht dies ebenfalls im aktuellen Verzeichnis.

Das Kommando erzeugt den privaten Schlüssel und fragt interaktiv nach einer Passphrase, mit welcher die Private-Key-Datei verschlüsselt wird. Anschließend werden die Informationen abgefragt, welche in den CSR aufgenommen werden sollen. Mit einem „.“ gibt man an, dass der Standardwert aus den eckigen Klammern in den CSR übernommen werden soll. Auf die Angabe einer E-Mail-Adresse und eines Challenge-Passworts kann guten Gewissens verzichtet werden, da diese Angaben von den meisten Zertifizierungsstellen ignoriert werden.

CSR für mehrere Hostnamen erstellen

Um einen CSR für mehrere Hostnamen zu erstellen, bedient man sich am einfachsten einer Konfigurationsdatei. Die im Folgenden verwendete Konfigurationsdatei kann unter [2] heruntergeladen und unter einem beliebigen Namen (z.B. csr_config.cnf) gespeichert werden. Ausführliche Informationen zum Aufbau der Konfigurationsdatei finden sich in Kapitel 3.3 des unter [2] verlinkten TLS-Kochbuchs. Beachten Sie, dass hinter dem Parameter subjectAltName neben den weiteren Host-/Domain-Namen auch der commonName mit aufgeführt werden muss.

[ req ]
default_bits = 2048
default_keyfile = test_privatekey.pem
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:test.example.com, DNS:*.test.example.com

[ req_distinguished_name ]
countryName = DE
stateOrProvinceName = Nordrhein-Westfalen
localityName = MeinOrt
0.organizationName = MeineFirma
organizationalUnitName = MeineAbteilung
commonName = test.example.com

Die obige Konfigurationsdatei kann nun genutzt werden, um einen CSR für den Hostnamen test.example.com und alle möglichen Hostnamen unterhalb der Domain .test.example.com zu erstellen:

/tmp$ openssl req -batch -sha256 -new -config csr_config.cnf -out test2.csr

Mit der Option -batch wird der interaktive Modus deaktiviert. Die Option -new gibt an, dass ein neuer CSR generiert werden soll. Dabei wird ein Private-Key nach den Vorgaben in der Konfigurationsdatei, welche mit -config csr_config.cnf angegeben wird, erzeugt.

Abschließende Bemerkungen

Die beiden gezeigten Methoden zur Erzeugung einer Zertifikatsanfrage stellen nur einen kleinen Ausschnitt aus dem großen Werkzeugkasten namens OpenSSL dar. Doch sind sie dazu geeignet, in einfacher Weise einen CSR zu erstellen, den man zur Signatur an eine CA seines Vertrauens senden kann.

  1. PKCS #10: Certification Request Syntax Specification
  2. TLS/SSL-Kochbuch – Rezepte für die Verwendung von OpenSSL

Vorträge 2017 auf der OpenRheinRuhr und dem LinuxDay in Vorarlberg

Nicht ganz uneigennützig möchte ich mit diesem Beitrag auf zwei Veranstaltungen zu den Themen Open Source, Freie Software und Linux in diesem Jahr hinweisen. Beide Veranstaltungen haben gemeinsam, dass ich auf ihnen mit verschiedenen Vorträgen vor Ort bin.

OpenRheinRuhr 2017

Bereits kommende Woche findet vom 4.-5. November die OpenRheinRuhr im Rheinischen Industriemuseum in Oberhausen statt.

Ich selbst bin dieses Jahr zum ersten Mal auf der OpenRheinRuhr zu Gast und freue mich bereits auf spannende Themen und darauf, das ein oder andere vertraute Gesicht wiederzusehen. Von mir gibt es als Beitrag zur diesjährigen Veranstaltung am 4. November um 17 Uhr eine Einführung und kritische Betrachtung von Ansible.

LinuxDay in Vorarlberg

Am 2. Dezember diesen Jahres bin ich dann beim LinuxDay in Vorarlberg (Österreich) zu Gast. Die Veranstaltung legt den inhaltlichen Schwerpunkt dieses Jahr auf die Themen Privatsphäre und Sicherheit. Dazu gibt es um 15 Uhr mit meinem Vortrag „Webseiten mit HTTPS bereitstellen und mit HSTS und HPKP sichern“ einen Einblick in die Welt der Internet-PKI, ihrer Schwachstellen und zwei ausgewählte Methoden, um die Angriffsfläche zu verkleinern.

Der Vortrag ist ein Auszug aus meinem TLS-Kochbuch, welches unter dem angegebenen Link kostenlos zum Download zur Verfügung steht.

Ich freue mich bereits darauf, unsere Nachbarn im Süden zu besuchen, sowie altbekannte und neue Mitglieder der Gemeinschaft kennenzulernen.
LinuxDay 2017 am 2. Dez in Dornbirn

Linux: Wann ist ein Neustart erforderlich?

Es ist allgemein bekannt, dass ein Neustart erforderlich ist, um einen neu installierten oder aktualisierten Kernel zu laden. Doch gibt es auch noch weitere Pakete, welche den Neustart eines Hosts erforderlich machen. Dieser Artikel beschreibt Methoden für CentOS, RHEL, Oracle Linux, Debian und Ubuntu, mit denen geprüft werden kann, ob ein Neustart erforderlich ist oder nicht.

Prüfung unter CentOS, RHEL, Oracle Linux

Unter den genannten Distributionen existiert das Programm needs-restarting, welches durch das Paket yum-utils bereitgestellt wird. Dieses kann genutzt werden, um Prozesse anzuzeigen, die aktualisiert wurden:

# needs-restarting
477 : /usr/bin/VGAuthService -s

Die Ausgabe gibt die Prozess-ID und den Namen des Prozesses zurück. Möchte man prüfen, ob ein Neustart des gesamten Systems erforderlich ist, so nutzt man die Option -r:

# needs-restarting -r
Core libraries or services have been updated:
  kernel -> 3.10.0-693.1.1.el7

Reboot is required to ensure that your system benefits from these updates.

More information:
https://access.redhat.com/solutions/27943

Obige Ausgabe deutet darauf hin, dass ein Neustart erforderlich ist, da ein neuer Kernel installiert wurde. Auf einem neugestarteten System sieht die Ausgabe wie folgt aus:

$ sudo needs-restarting -r
No core libraries or services have been updated.
Reboot is probably not necessary

Prüfung unter Debian und Ubuntu

Um festzustellen, ob ein Neustart erforderlich ist oder nicht, kann man prüfen, ob die Datei /var/run/reboot-required existiert. Existiert die Datei, ist es angeraten, einen Neustart des Systems durchzuführen. Ist die Datei hingegen nicht vorhanden, ist höchstwahrscheinlich auch kein Neustart erforderlich.

Quellen und weiterführende Links

Geschwindigkeit von PowerLAN mit iperf messen

PowerLAN, auch bekannt als dLAN oder Powerline, bezeichnet eine Technologie, zum Aufbau eines lokalen Netzwerks, unter Nutzung vorhandener Stromleitungen.

Adapter verschiedener Hersteller versprechen dabei eine Übertragungsgeschwindigkeit von bis zu 2000 Mbit/s. Doch ob diese Geschwindigkeit im eigenen Haushalt auch nur annähernd erreicht wird hängt von vielen Faktoren ab. Darunter fallen z.B. Alter und Zustand der Hausverkabelung, aber auch angeschlossene elektrische Geräte können die Übertragungsgeschwindigkeit negativ beeinflussen.

Um die Geschwindigkeit des PowerLAN zu messen bietet sich das Programm iperf an, welches unter allen gängigen Linux-Distributionen zur Verfügung steht.

Test der Messmittel

Bevor man mit der Messung beginnt und viel Mist misst, sollte man noch ein paar Dinge beachten.

Um mit iperf die Geschwindigkeit des Netzwerks zu messen, kommen in meinem kleinen Versuchsaufbau zwei Notebooks mit Ubuntu 16.04 LTS und Gigabit-Netzwerkkarte zum Einsatz. Denn selbstverständlich haben auch die Geschwindigkeit der verwendeten Netzwerkkarten und selbst der Netzwerkkabel einen Einfluss auf das Messergebnis. Verwendet man Netzwerkkarten mit einer Geschwindigkeit von 100 Mbit/s oder ist schon ein paar Mal mit dem Bürostuhl über das Netzwerkkabel gerollt, darf man sich nicht wundern, wenn man nicht mal annähernd an die versprochene Geschwindigkeit herankommt. Aber auch andere Programme, die evtl. zur gleichen Zeit ausgeführt werden und das Netzwerk nutzen, können die Messergebnisse beeinträchtigen. Es gilt diese Störfaktoren möglichst auszuschließen.

Die beiden Notebooks verbinde ich zuerst über einen Gbit-Switch miteinander. Dazu verwende ich die neuen LAN-Kabel, welche den PowerLAN-Adaptern beiliegen. Dank IPv6 ist keine weitere Konfiguration der Schnittstellen erforderlich. Es können direkt die link-local Adressen genutzt werden, um miteinander zu kommunizieren. Nun wird auf einem der beiden Notebooks iperf (iperf -s) im Servermodus gestartet, womit es auf eingehende Verbindungen wartet.

Auf dem anderen Notebook wird iperf im Client-Modus gestartet (iperf -c hostname), welches sich dann zum Server verbindet und mit der Messeung beginnt. Das Ergebnis einer solchen Messung ist der folgenden Ausgabe zu entnehmen:

------------------------------------------------------------
Client connecting to fe80::%eth0, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local fe80:: port 47748 connected with fe80:: port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.07 GBytes   915 Mbits/sec

Bei ca. 10 Wiederholungen dieses Tests lag die Geschwindigkeit stets zwischen 910 Mbits/s und 936 Mbits/s. Für einen kleinen SoHo-Switch ein hervorragendes Ergebnis. Nun bin ich natürlich gespannt, ob die PowerLAN-Adapter die angepriesene Geschwindigkeit ebenfalls liefern können.

Messung der PowerLAN-Verbindung

Die PowerLAN-Adapter wurden direkt in Wandsteckdosen eingesetzt. Die integrierten Steckdosen sollen von weiteren Endgeräten verursachte Störungen auf der Leitung herausfiltern und so die bestmögliche Leistung garantieren.

In meinem Versuchsaufbau befand sich ein Adapter im Erdgeschoss, während der andere im darüberliegenden Raum im 1. OG angeschlossen wurde. Beide Adapter haben sich innerhalb kurzer Zeit gefunden und zu einem Paar verbinden lassen.

Anschließend wurde die Übertragungsgeschwindigkeit mit iperf gemessen. Die Messung wurde mehrfach wiederholt, um Ausreißer erkennen zu können. Das Ergebnis war leider sehr enttäuschend. Die durchschnittliche Übertragungsrate lag bei 31 Mbit/s. Ausreißer gab es ledigich nach unten, wo bei einigen Tests nur 7 Mbit/s übertragen wurden.

In der Folge habe ich noch weitere Messungen an anderen Steckdosen im Haus durchgeführt, kam aber nicht über eine maximale Übertragungsrate von 36 Mbit/s hinaus. Hinzu kommt die Beobachtung, dass die getesteten Adapter während einer Messung wiederholt die Verbindung zueinander verloren und Messungen wiederholt werden mussten.

Leider bestätigten sich damit Ergebnisse aus früheren Tests, so dass kein sinnvoller Einsatz dieser Technik in unserem Haus möglich scheint.

Fazit

PowerLAN verspricht die schnelle und einfache Vernetzung von netzwerkfähigen Geräten über das Stromnetz in der eigenen Wohnung bzw. im eigenen Haus. Die versprochenen Übertragungsraten von teilweise mehr als 1 Gbit/s werden dabei jedoch nicht in jedem Fall erreicht. Häufig liegen diese sogar deutlich unter den angegebenen Maximalwerten. Daher ist ein Test der Übertragungsgeschwindigkeit in jedem Fall empfehlenswert.

Bevor man jedoch mit der Messung beginnt, sollte man die eingesetzten Messmittel auf ihre Tauglichkeit und Leistungsfähigkeit hin überprüfen. Denn sonst gilt wieder: „Wer viel misst, misst viel Mist.“

Was sind die maximalen und minimalen Werte für UID und GID in den verschiedenen Linux-Distributionen?

In verschiedenen Kreisen kam wiederholt die Frage auf, aus welchem Bereich unter Linux die Werte für UID und GID stammen. Diese Frage möchte ich in diesem Beitrag beantworten.

Der maximal mögliche Wert, den eine UID oder GID annehmen kann, wird vom Typ der Variablen bestimmt, in der dieser Wert gespeichert wird. Bei den im Folgenden betrachteten Distributionen besitzen diese Integer-Variablen eine Größe von 32 Bit. Der maximal mögliche Wert für UID bzw. GID liegt in diesen Distributionen also bei 4.294.967.295. Wie die Größe dieser Variablen ermittelt werden kann, wird in der Red Hat Wissensdatenbank beschrieben.

Darüber hinaus definieren die Distributionen in der Datei /etc/login.defs einen Bereich, aus dem eine automatische Vergabe bei der Verwendung der Kommandos useradd bzw. groupadd erfolgt.

Min- und Maximal-Werte für UID und GID

Min/Max-WerteUbuntu 16.04 LTSRHEL/CentOS 7SLES 12 SP1
UID_MIN100010001000
UID_MAX600006000060000
SYS_UID_MIN100201100
SYS_UID_MAX999999499
GID_MIN100010001000
GID_MAX600006000060000
SYS_GID_MIN100201100
SYS_GID_MAX999999499
Voreingestellte Minima und Maxima für UID und GID verschiedener Distributionen

UID und GID gelten für „normale“ Benutzer, während SYS_UID und SYS_GID die Grenzen für Systembenutzer angeben.

Quellen und weiterführende Links