Im Kapitel Arch Linux - (manuelle) Minimalinstallation sind wir schon Kurz auf den Umstand eingegangen, dass in der künftigen Ausprägung unserer Infrastruktur auf Basis von Arch Linux mit Hilfe von Ansible automatisiert unsere Hosts und Anwendungen installieren, konfigurieren und auf dem Laufenden halten wollen.

Hierzu benötigen wir natürlich ein auf unsere Anforderungen hin zugeschnittenes Boot-Image, welches unter anderem einem speziellen User der Zugriff via SSH gestattet. In folgendem Kapitel wollen wir uns nun solch ein initiales Custom Boot Image erstellen.

Basis für den Bau eines individuellen Boot-Image ist die der Artikel Build a Killer Customized Arch Linux Installation (and Learn All About Linux in the Process) bzw. die Dokumentation aus dem Arch Linux WIKI.

Basis für den Bau dieses Custom Boot Image ist unsere Arch Linux - (manuelle) Minimalinstallation aus dem Kapitel zuvor, auf der wir nun weiter aufsetzen werden.

Bevor wir zur Installation der benötigten Werkzeuge, Installation und Bau unseres ISO-Images schreiten, aktualisieren wir noch unser bestehendes System.

Zunächst initialisieren wir den Keyring, damit die PGP-singnierten Pakete auch mit dem aktuellen Schlüsselmaterial validiert werden können.

 # pacman-key --init

Im nächsten Schritt laden wir die Default Schlüssel neu.

 # pacman-key --populate archlinux

==> Appending keys from archlinux.gpg...
==> Updating trust database...
gpg: next trustdb check due at 2023-04-21

Abschliessend aktualisieren wir unser vorhandenes System.

 # pacman -Syu

==> Appending keys from archlinux.gpg...
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
:: Starting full system upgrade...
 there is nothing to do

Nun haben wir die Basis geschaffen für die weitere Installation der benötigten Komponenten für den Bau unseres ISO-Images.

Für die Erstellung von Arch Linux Live-CD/USB-ISO-Images greifen wir auf Werkzeug/Paket archiso zurück, welches auch für den Bau der offiziellen Images von Arch Linux verwendet wird.

Mit Hilfe das Paketmanagers pacman installieren wir nun dieses Werkzeug.

 # pacman -S --noconfirm archiso

Was uns diese Paket alles mitbrachte, können wir bei Bedarf und Interesse mit folgendem Befehl uns anzeigen lassen.

 # pacman -Qil archiso

Im Paket archsio werden zwei Benutzerprofile mitgeliefert:

• baseline
  Im baseline Profil enthalten sind lediglich die aller nötigsten Pakete, welche zum Booten eines Live-ISO-Images und zur anschliessenden Grundinstallation von Arch Linux benötigt werden.
• releng
  Das releng Profil hingegen, enthält alle tagesaktuellen Pakete und entspricht dem monatlich veröffentlichten Installationsmedium und ist im Gegensatz des baseline Profils etwa dreimal so gross, aber mit einer Gesamtgrösse von nicht einmal 800 MB doch überschaubar.

Für unser eigenes individuell angepasstes Boot-ISO-Image wollen als Basis das releng Profil verwenden und darauf aufbauen. Zunächst kopieren wir uns also den Inhalt dieses Verzeichnisses.

 # cp -ar /usr/share/archiso/configs/releng /usr/local/src/customiso

Wie Eingangs erwähnt wollen wir später Ansible benutzen, um unsere Infrastruktur automatisiert zu installieren, konfigurieren und verwalten. Hierzu benötigen wir natürlich auf den Ziel neben einem lauffähigen SSH-Daemon auch entsprechendes Schlüsselmaterial, damit sich unser berechtigter Ansible-Benutzer auch mit Hilfe der SSH dorthin verbinden kann.

Wir stellen also zunächst sicher, dass der SSH-Daemon auf dem Zielsystem gestartet wird.

 # mkdir -p /usr/local/src/customiso/airootfs/etc/systemd/system/multi-user.target.wants/

Anschliessend setzen wir für den Autostart des SSH-Daemon einen symbolischen link im zuvor angelegten Verzeichnis.

 # ln -s /usr/lib/systemd/system/sshd.service /usr/local/src/customiso/airootfs/etc/systemd/system/multi-user.target.wants/

Der initiale Verbindungsaufbau von Ansible wird dann über den Benutzer root initial erfolgen. Wir werden also diesem System-Account sowohl ein Passwort wie auch entsprechendes SSH-Schlüsselmaterial in den zugehörigen Verzeichnissen bereit stellen.

Das Passwort unseres Benutzers root wird verschlüsselt in der Datei /etc/shadow vorgehalten, welche neben der /etc/passwd und /etc/group zum Benutzerverwaltungssystem eines jeden Linux-Systems gehört.

Wie und wo das Passwort eines Benutzers hinterlegt ist, sehen wir uns kurz an Hand des folgenden Beispiels kurz etwas genauer an:

ansible:$6$7d6OVSAcprhrUHrX$YJUg2rUQwRfJ3UdvQjSOR3cmS0xwoRRKMNCjLNsjAuleuZKCHvOh9ZXWPze.1CQ9Y2uwAS59SsMIwYKJ1lgBr.:18434:0:99999:7:::

Die einzelnen Werte sind mit einem Doppelpunkt : sowie der verwendete Algorithmus, das verwendete Salt und der Passworthash werden mit einem Dollar-Zeichen $ getrennt und haben folgende Bedeutung:

• ansible : Entspricht dem Account-/Username.
• $6$ : Entspricht dem Algorithmus, welcher bei der Erstellung des Hashwertes verwendet wurde. Weiterführende Informationen zu Passwort-Hashing-Algorithmen finden sich hier in diesem Artikel zu finden!
  $1 steht dabei für md5
  $2$ für Blowfish,
  $5$ für SHA-256 und
  $6$ für SHA-512 als verwendeten Algorithmus.
• 7d6OVSAcprhrUHrX : Dies ist das Salt welches als zufällige Komponente verwendet wird, um so bei der Erstellung eines Passworthashes einen Zufallswert an die Hand zu reichen. Ohne diesen Wert würde bei der Erzeugung des Passworthashes bei gleichem Passwort auch immer den gleichen Hash Wert erzeugt, was aus dem Blickwinkel Security als Problem erkannt werden würde.
• YJUg2rUQwRfJ3UdvQjSOR3cmS0xwoRRKMNCjLNsjAuleuZKCHvOh9ZXWPze.1CQ9Y2uwAS59SsMIwYKJ1lgBr. : Der eigentliche Hashwert des Benutzerpasswortes.
• 18434 : Das Datum, an dem das Passwort das letzte Mal geändert wurde. Dies ist die Anzahl der Tage seit dem 01.01.1970 an dem das Passwort zu Letzt gesetzt bzw. abgeändert wurde.
• 0 : Die Anzahl der Tage bevor das Passwort geändert werden kann - die 0 definiert, dass das Passwort jederzeit geändert werden könnte.
• 99999 : Entspricht die Anzahl der Tage nachdem das Passwort geändert werden muss - die 9999 definiert, dass das Passwort nie abläuft und daher auch zwangsweise nie geändert werden muss.
• 7 : Die Anzahl der Tage nachdem der Benutzeraccount ggf. deaktiviert wird, sollte der eingestellte Zeitraum für den Passwortwechsel nicht eingehalten worden sein.
• :: : Die Anzahl der Tage, seit dem der Account bereits gesperrt worden ist. In diesem Beispiel ist dies ein leeres Feld mit dem signalisiert wird, dass der Account aktuell in Verwendung also aktiv ist.
• :: : Dies ist ein leeres Reserve-Feld, welches für künftige Benutzung/Definition reserviert ist.

Wir brauchen also demnach zwei Dinge:

1. Die Tage die seit dem 01.01.1970 vergangen sind und
2. das gehashte Passwort unseres Benutzers root.

Den ersten Wert berechnen wir einfach wie folgt:

 # echo $(( ($(date -d $(date +%F)  +%s) - $(date -d 1970-01-01 +%s)) / 86400 ))

19344

Den Passwort-Hash mit einem SHA-512-Salt erzeugen wir wie folgt:

 # openssl passwd -6

Password: 
Verifying - Password: 
$6$owZuNz359oeC8VSg$ba5HdCCuShYt4YcQ5HKp.N37LH1YIjFOb3ZgYgYfDqUnIHGv18B3sPmVgbzhdn7dwdWKY5PFd2/3TrHgxjwEc1

Beide ermittelten Werte hinterlegen wir nun in unserer/etc/shadow-Datei, die später in unserem eigenen benutzerindividuellen Custom Boot Image beinhaltet sein wird.

 # vim /usr/local/src/customiso/airootfs/etc/shadow

root:$6$owZuNz359oeC8VSg$ba5HdCCuShYt4YcQ5HKp.N37LH1YIjFOb3ZgYgYfDqUnIHGv18B3sPmVgbzhdn7dwdWKY5PFd2/3TrHgxjwEc1:19344::::::

Nun benötigen wir noch den Public-Key unseres Ansible-Accounts.

 $ cat .ssh/id_ed25519_ansible.pub 

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILti67aZOSetfvNFxVVqkJAfSKXjyvemB3kRZEQ5q/kf Ansible Systemuser

Für diesen Schlüssel benötigen wir auf dem Zielsystem das betreffende Verzeichnis, welches wir nun anlegen.

 # mkdir /usr/local/src/customiso/airootfs/root/.ssh

mkdir: created directory '/usr/local/src/customiso/airootfs/root/.ssh'

Anschliessend passen wir noch die Rechte an dem Verzeichnis an.

 # chmod 700 /usr/local/src/customiso/airootfs/root/.ssh

Im nächsten Schritt hinterlegen wir unseren public-key in der Datei authorized_keys.

 # vim /usr/local/src/customiso/airootfs/root/.ssh/authorized_keys

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILti67aZOSetfvNFxVVqkJAfSKXjyvemB3kRZEQ5q/kf Ansible Systemuser

Auch hier passen wir noch die Rechte an der Datei an.

 # cmod 600 /usr/local/src/customiso/airootfs/root/.ssh

Da wir nicht möchten, dass der Benutzer root automatisch auf der Konsole angemeldet werden soll, löschen wir die zugehörige Konfigurationsdatei in unserer Umgebung.

 # rm /usr/local/src/customiso/airootfs/etc/systemd/system/getty\@tty1.service.d/autologin.conf

Nach Abschluss der Vorarbeiten können wir nun unser eigenes Arch Linux Boot-ISO-Image wir folgt erstellen:

 # mkarchiso -v -w /usr/local/src/work/ -o /usr/local/src/out /usr/local/src/customiso/

Je nach Performance unserer Test-Umgebung steht und nach ca. 10 - 15 Minuten im gewählten Verzeichnis /usr/local/src/out unser Boot-Image zur Verfügung.

...
Writing to 'stdio:/usr/local/src/out/archlinux-2022.12.18-x86_64.iso' completed successfully.

[mkarchiso] INFO: Done!
819M	/usr/local/src/out/archlinux-2022.12.18-x86_64.iso

 # rm -rf /usr/local/src/work/ /usr/local/src/out

Nun müssen wir unser erstelltes ISO-Image nur noch auf dem Virtualisierungsknoten in das zugehörige Verzeichnis verschieben, in dem sich unsere Boot-Images befinden: /var/lib/libvirt/boot/.

Nach getaner Arbeit benötigen wir zur gegebenen Zeit unsere Test-Maschine nicht mehr. Wir können diese daher wie gewohnt herunterfahren …

 # virsh shutdown vml000200

… oder natürlich auch auf die „harte Tour“:

 # virsh destroy vml000200

Anschliessend löschen wir die VM samt ihrem zugehörigen Image vom System.

 # virsh undefine vml000200 --remove-all-storage

Domain vml000200 has been undefined
Volume 'vda'(/var/lib/libvirt/images/vml000200.img) removed.

• Zurück zur "Arch-Linux"-Übersicht
• Zurück zu >>Projekte und Themenkapitel<<
• Zurück zur Startseite