Commit 054997aa authored by Sarah Kriesch's avatar Sarah Kriesch 🏆

Expand the PXE part

parent 4311f756
......@@ -83,7 +83,7 @@
Zu Beginn erstellt kiwi aus der gegebenen Konfigurationsdatei einen Verzeichnisbaum. Dieser lässt sich über ein change-root-Tool wir chroot beliebig navigieren und erkunden. Bis auf das kiwi-Verzeichnis, welches eine Kopie der Konfiguration, sowie wichtige Bauelemente beinhaltet(Details??), spiegelt das Verzeichnis das spätere Innenleben des images wieder.\\
Zum Ende dieses Erstellungsprozesses wird noch das config.sh-Skript, sofern vorhanden, ausgeführt. Dieses dient dem Zweck(???).\\
Achtung: Manuelle Änderungen innerhalb des Verzeichnis werden bei der nächsten Ausführung des Befehls überschrieben und können im zweiten Schritt zu schwer verfolgbaren Fehlern führen. Deshalb ist dies nicht zu empfehlen!
\subsubsection{Generieren des images}
\subsubsection{Generieren des Images}
(Um diesen Schritt durchlaufen zu können, ist das erfolgreiche Abschließen des Vorherigen zwingend erforderlich.) Zu Beginn des zweiten Schrittes wird das images.sh Shellskript ausgeführt, sofern vorhanden.\\
Aus dem Verzeichnisbaum können nun unterschiedliche Imagetypen generiert werden. Möglich sind:\\
USB-Live-Images, PXEBoot, Amazon EC2, Docker, KVM/Qemu, VirtualBox, VMWare, Vagrant...(???)\\
......@@ -93,8 +93,8 @@
Das Prinzip ist hierbei einfach, statt seine erstellten Pakete selbst lokal zu bauen, übernimmt diese Aufgabe der OpenBuildService. Sollten sich innerhalb des Paketes oder einer seiner Dependencies etwas ändern, so wird das Paket automatisch neu gebaut.
\subsubsection{rpmlint}
rpmlint überprüft bauende Pakete auf bekannte Schwachstellen und Probleme. Falls diese kritisch sein sollten, wird hierdurch der Buildvorgang unterbrochen.
\subsubsection{images auf dem OBS}
Seit der Einstellung des SUSE Studio-Projekts werden images über den OpenBuildService erstellt. Auch SUSE-eigene Images wie Live-CDs/-USB-Sticks, images für diverse Hypervisor(KVM, VirtualBox, VMWare usw.) und Container(z.b. Docker) optimiert und andere Dienstleister wie AWS werden über den OpenBuildService gebaut. Hierfür werden dem Entwickler einige Templates zur Verfügung gestellt, jedoch sind diese, zumindest zum Projektzeitpunkt, veraltet und deshalb für uns nicht weiter zu gebrauchen.\\
\subsubsection{Images auf dem OBS}
Seit der Einstellung des SUSE Studio-Projekts werden images über den Open Build Service erstellt. Auch SUSE-eigene Images wie Live-CDs/-USB-Sticks, images für diverse Hypervisor(KVM, VirtualBox, VMWare usw.) und Container(z.b. Docker) optimiert und andere Dienstleister wie AWS werden über den OpenBuildService gebaut. Hierfür werden dem Entwickler einige Templates zur Verfügung gestellt, jedoch sind diese, zumindest zum Projektzeitpunkt, veraltet und deshalb für uns nicht weiter zu gebrauchen.\\
Hilfreicher waren hier schon die templates aus dem kiwi-desc-netboot-Paket, jedoch hat auch dieses unter der derzeitigen OBS-Version nicht korrekt gebaut.\\
Problematisch scheint derzeit in erster Linie das Auffinden eines korrekten Quellrepositories zu sein, da zum Projektzeitpunkt ein Bug für -mini-Pakete, welche standardmäßig in den images dabei sind, für Paketkonflikte sorgt.\\
Im Gegensatz zum lokalen Bauvorgang hat der OpenBuildService im Umgang mit kiwi einige Eigenheiten. Diese wären:
......@@ -102,14 +102,14 @@
\item Die Konfigurationsdatei muss eine *.kiwi-Datei sein(config.xml ist als Dateiname nicht möglich)
\end{itemize}
\subsubsection{OBS mit anderen Distributionen}
der OpenBuildService unterstützt neben SUSE-Distributionen auch Debian, Arch Linux, Gentoo Linux (??, überprüfen) beim Paketbau.
Der Open Build Service unterstützt neben SUSE-Distributionen auch Debian, Arch Linux, Gentoo Linux (??, überprüfen) beim Paketbau.
\section{PXE-Boot}
Für die Installation von openSUSE mit dem PXE-Server wird ein PXE-Server gebraucht. Weil es im Subnetz nur einen DHCP-Server geben darf, \\
wird der DHCP-Server der Fakultät Informatik verwendet. Dafür wurden die MAC-Adressen der Clients herausgesucht und diesen mit BOOTP der PXE-Server auf\\
invis.informatik.fh-nuernberg.de zugewiesen, dass die Clients per PXE aus /pxelinux.0 starten sollen.
\\
\\
Auf dem PXE-Server wurden die Pakete atftpd, xinetd und vsftpd installiert. Zum automatischen Start muessen diese mir 'systemctl enable' aktiviert und \\
Auf dem PXE-Server wurden die Pakete atftpd, xinetd, syslinux und vsftpd installiert. Zum automatischen Start müssen diese mir 'systemctl enable' aktiviert und \\
'systemctl start' gestartet werden.\\
Die Firewall-Ports sind nicht automatisch freigeschaltet. Deshalb braucht man folgende firewalld-Befehle:
\fbox{firewall-cmd --add-service=tftp --permanent\\
......@@ -118,6 +118,9 @@
firewall-cmd --add-port=67/tcp --permanent #BOOTP\\
firewall-cmd --add-port=4011/udp --permanent\\
firewall-cmd --reload} \\
Weil das PXE-Image einiges an Platz braucht und alles mit dem Backup abgesichert werden soll, wurde der TFTP-Server so konfiguriert, dass die Daten alle unter /opt/ abgelegt werden können. \\
Nachdem die oben genannten Pakete installiert wurden, mussten die beiden Dateien pxelinux.0 und menu.c32 aus /usr/share/syslinux/ nach /opt/tftpboot/ kopiert werden. Weil im DHCP-Server der Eintrag fuer /pxelinux.0 bei allen Hosts zum Booten steht, wurde noch ein Symlink von /opt/tftpboot/pxelinux.0 nach /pxelinux.0 generiert. Damit nicht nur root die Dateien unter tftpboot lesen kann, mussten die Benutzerrechte rekursiv auf nobody:nobody mit 755 angepasst werden.
\newpage
\section{automatisches Deployment}
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment