Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- arch:boot_iso [18.12.2022 09:46. ] – angelegt django
+++ arch:boot_iso [31.10.2023 18:52. ] (aktuell) – Externe Bearbeitung 127.0.0.1
@@ Zeile 1: / Zeile 1: @@
 ====== Custom Boot Image als Grundlage für Orchstrierung ======
+{{:arch:archlinux-logo.png?nolink&200 |Bild: Archlinux Logo}}
+Im Kapitel [[install|Arch Linux - (manuelle) Minimalinstallation]] sind wir schon Kurz auf den Umstand eingegangen, dass in der künftigen Ausprägung unserer Infrastruktur auf Basis von **[[https://archlinux.org/|Arch Linux]]** mit Hilfe von **[[linux:ansible:start|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 [[linux:ansible:playbook_example_08|speziellen User]] der Zugriff via **[[linux:ansible:playbook_example_08#aufgabenstellung_2_-_erweiterte_grund-_basis-installation_fuer_ansible-vault|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 **[[https://lifehacker.com/build-a-killer-customized-arch-linux-installation-and-5680453|Build a Killer Customized Arch Linux Installation (and Learn All About Linux in the Process)]]** bzw. die Dokumentation aus dem **[[https://wiki.archlinux.de/title/Archiso|Arch Linux WIKI]]**.
+===== Voraussetzung =====
+Basis für den Bau dieses Custom Boot Image ist unsere [[install|Arch Linux - (manuelle) Minimalinstallation]] aus dem Kapitel zuvor, auf der wir nun weiter aufsetzen werden.
+===== Konfiguration und Bau des ISO-Images =====
+==== Update der vorhandenen Installation ====
+Bevor wir zur Installation der benötigten Werkzeuge, Installation und Bau unseres ISO-Images schreiten, aktualisieren wir noch unser bestehendes System.
+=== Keyring Initialisieren ===
+Zunächst initialisieren wir den Keyring, damit die PGP-singnierten Pakete auch mit dem aktuellen Schlüsselmaterial validiert werden können.
+   # pacman-key --init
+=== Default Schlüssel neu laden ===
+Im nächsten Schritt laden wir die Default Schlüssel neu.
+   # pacman-key --populate archlinux
+<code>==> Appending keys from archlinux.gpg...
+==> Updating trust database...
+gpg: next trustdb check due at 2023-04-21</code>
+=== System aktualisieren ===
+Abschliessend aktualisieren wir unser vorhandenes System.
+   # pacman -Syu
+<code>==> 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</code>
+Nun haben wir die Basis geschaffen für die weitere Installation der benötigten Komponenten für den Bau unseres ISO-Images.
+==== Installation von archiso ====
+Für die Erstellung von Arch Linux Live-CD/USB-ISO-Images greifen wir auf Werkzeug/Paket **[[https://wiki.archlinux.org/title/Archiso|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
+==== Benutzerprofile baseline und releng ====
+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
+==== SSH Daemon ====
+Wie Eingangs erwähnt wollen wir später **[[linux:ansible:start|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.
+=== Verzeichnis für den systemd autostart des sshd anlegen ===
+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/
+=== symbolic-link für den Autostart des SSHD setzen ===
+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/
+==== Benutzer root ====
+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.
+=== Passwort ===
+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 [[https://dusted.codes/sha-256-is-not-a-secure-password-hashing-algorithm|Artikel]] zu finden! \\ **''$1''** steht dabei für **[[https://de.wikipedia.org/wiki/Message-Digest_Algorithm_5|md5]]** \\ **''$2$''** für **[[https://de.wikipedia.org/wiki/Blowfish|Blowfish]]**, \\ **''$5$''** für **[[https://de.wikipedia.org/wiki/SHA-2|SHA-256]]** und \\ **''$6$''** für **[[https://de.wikipedia.org/wiki/SHA-2|SHA-512]]** als verwendeten Algorithmus.
+  * **''7d6OVSAcprhrUHrX''** : Dies ist das **[[https://de.wikipedia.org/wiki/Salt_(Kryptologie)|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:
+  - Die Tage die seit dem 01.01.1970 vergangen sind und
+  - 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 ))
+Den Passwort-Hash mit einem **SHA-512**-Salt erzeugen wir wie folgt:
+   # openssl passwd -6
+<code>Password:
+Verifying - Password:
+$6$owZuNz359oeC8VSg$ba5HdCCuShYt4YcQ5HKp.N37LH1YIjFOb3ZgYgYfDqUnIHGv18B3sPmVgbzhdn7dwdWKY5PFd2/3TrHgxjwEc1</code>
+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
+<file /usr/local/src/customiso/airootfs/etc/shadow>root:$6$owZuNz359oeC8VSg$ba5HdCCuShYt4YcQ5HKp.N37LH1YIjFOb3ZgYgYfDqUnIHGv18B3sPmVgbzhdn7dwdWKY5PFd2/3TrHgxjwEc1:19344::::::</file>
+=== SSH-Key ===
+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
+<file /usr/local/src/customiso/airootfs/root/.ssh/authorized_keys>ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILti67aZOSetfvNFxVVqkJAfSKXjyvemB3kRZEQ5q/kf Ansible Systemuser</file>
+Auch hier passen wir noch die Rechte an der Datei an.
+   # cmod 600 /usr/local/src/customiso/airootfs/root/.ssh
+=== Autologin deaktivieren ===
+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
+==== Bau des ISO-Images ====
+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.
+<code>...
+Writing to 'stdio:/usr/local/src/out/archlinux-2022.12.18-x86_64.iso' completed successfully.
+[mkarchiso] INFO: Done!
+M	/usr/local/src/out/archlinux-2022.12.18-x86_64.iso</code>
+<WRAP center round tip 65%>
+Will man erneut die Erstellung des ISO-Images anstossen, löscht man vor einem erenuten Aufruf von **''mkarchiso''** die beiden Verzeichnisse: \\
+ **''/usr/local/src/work/''** und **''/usr/local/src/out''**.
+   # rm -rf /usr/local/src/work/ /usr/local/src/out
+</WRAP>
+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/.
+===== Zwischenergebnis =====
+<WRAP center round important 80%>
+**Wichtig**: \\
+Wir werden natürlich nicht jedes mal den Bau eines aktuellen auf unsere Bedürfnisse zugeschnittenes **//Custom Boot Image//** per Hand auf Basis dieser Musterlösung aus dem WIKI via **//cut 'n' paste//** manuell erstellen, sondern dies mit Hilfe eines Ansible-Playbooks automatisiert erledigen lassen. Hierzu demnächst mehr => FIXME :!:
+</WRAP>
+===== Muster-Test-VM zurückbauen =====
+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
+<code>Domain vml000200 has been undefined
+Volume 'vda'(/var/lib/libvirt/images/vml000200.img) removed.</code>
+====== Links ======
+  * **[[start|Zurück zur "Arch-Linux"-Übersicht]]**
+  * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]**
+  * **[[https://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**