Commit 3e8ae168 authored by mainja67707's avatar mainja67707

Add first approach to Salt and image Documentation

parent c4871a10
......@@ -26,25 +26,90 @@
In Anbetracht der Entwicklungsgeschwindigkeit heutiger Software stellt ein Automatisches Deployment deshalb eine wichtige Hilfestellung für Administratoren dar.
\newpage
\section{Ist-Analyse}
Momentan ist das Linux-Labor mit Ubuntu eingerichtet. Die Systeme wurden manuell installiert und konfiguriert. Die Authentifizierung mit dem Active Directory wurde mit Kerberos manuell eingepflegt. Der Drucker wurde mit Cups überall eingerichtet und hinterher so konfiguriert, dass das Druck-Budget über Kerberos-Tickets bei den entsprechenden Studenten abgebucht wird.
Momentan ist das Linux-Labor mit Ubuntu eingerichtet. Die Systeme wurden manuell installiert und konfiguriert. Die Authentifizierung mit dem Active Directory wurde mit Kerberos manuell eingepflegt. Der Drucker wurde mit Cups überall eingerichtet und hinterher so konfiguriert, dass das Druck-Budget über Kerberos-Tickets bei den entsprechenden Studenten abgebucht wird.
\newpage
\section{Projektziel}
Die Installation und Konfiguration soll automatisch mit PXE und Salt eingerichtet werden, so dass auch Upgrades automatisch durchgeführt werden können. Dafür muss dann zum Schluss nur noch die Versionsnummer angepasst werden. Somit soll auch die Pflege/ Wartung der Systeme erleichtert werden.
Die Installation und Konfiguration soll automatisch mit PXE und Salt eingerichtet werden, so dass auch Upgrades automatisch durchgeführt werden können. Dafür muss dann zum Schluss nur noch die Versionsnummer angepasst werden. Somit soll auch die Pflege/ Wartung der Systeme erleichtert werden.
\newpage
\section{Salt}
\subsection{Einführung}
Die von der Firma SaltStack geschriebene Software Salt besteht im wesentlichen aus zwei Teilen: dem Salt-Master und den Salt-Minions.\\
\subsubsection{Salt-Master}
Der Salt-Master beinhaltet die Konfigurationen, er gibt Instruktionen an die Minions weiter, die diese umsetzen.
Salt ist eine OpenSource Konfigurations-Management Software und Remote Code Execution Engine, welche uns ein automatisches Deployment der vorgesehenen Pakete ermöglicht.
Die von der Firma SaltStack geschriebene Software besteht im wesentlichen aus zwei Teilen: dem Salt-Master und den Salt-Minions. Beide besitzen einen (??)-Schlüssel, über den sie sich den anderen gegenüber authentifizieren können.\\
\subsection{Salt-Master}
Der Salt-Master gibt Instruktionen an die Minions weiter. Um dies zu ermöglichen, ist bei ihm eine Liste der aktuell verbundenen Minions hinterlegt. Diese können, entweder in Summe oder einzeln, mittels der hinterlegten Konfiguration oder für direkte Shell-Befehlsausführung angewiesen werden.\\
Die auf drei Verzeichnisse aufgeteilte Konfigurationen beinhaltet die Liste der Pakete und deren Installationsanleitung, sowie zusätzliche Konfiguration selbiger. Auch können hier Betriebssystem-, oder im Linux-Fall Distributionsspezifische, sowie Umgebungsabhängige Installationskonfigurationen hinterlegt werden(Von hier an nur noch als Distibutionsspezifischen Konfigurationen bezeichnet). Dies ist z.b. bei variierenden Paketnamen ungemein hilfreich.\\
Die Dateiendung ist, soweit nicht genauer spezifiziert, .sls.
Die drei verwendeten Verzeichnisse heißen standardmäßig salt, pillar, formulas.
\subsubsection{salt}
Im salt-Verzeichnis werden die distributionsspezifischen Profile angelegt. Wichtig ist hier insbesondere die top.sls-Datei, welche bei einem simplen state.apply abgearbeitet wird. Folgt diesem noch ein Dateiname, so wird diese im salt-Verzeichnis erwartet.\\
Das Verzeichnis ist für normale Paketinstallationen über die standard-Paketinstaller gedacht, wodurch eine simple Paketliste ohne weitere Konfigurationen hinreichend ist.
\subsubsection{pillar}
Für Variablen, Sensitive Daten, Konfigurationen und sonstige, zu übertragende Daten.
\subsubsection{formulas}
Konfigurations-/Installationsschnittstelle für aufwendigere Pakete, welche meist nicht über einen Paketmanager installierbar sind.
\newpage
\section{Kerberos}
\section{Kerberos}
\newpage
\section{PXE-Boot}
\section{openSUSE Image}
Damit ein möglichst aufwandsarmer Update-Vorgang durchgeführt werden kann, sollen die Linux-Rechner ein openSUSE image von einem PXE-Server während des Bootvorgangs laden. Dies soll die Rechner auf dem neuesten Stand halten und auch das hinzufügen neuer Rechner vereinfachen.
\subsection{SUSE Studio}
Zum Zeitpunkt des Projektantrages war für die Imageerstellung die Software SUSE Studio geplant. Diese stellt ein graphisches Frontend für das Kommandozeileninterface kiwi dar, welches für die Erstellung von images verwendet wird. Leider mussten wir feststellen, das SUSE Studio nicht mehr verfügbar ist und nun besagte images über kiwi in Kombination mit dem OpenBuildService gebaut werden.
\subsection{kiwi}
Kiwi ist der Name des Kommandozeileninterfaces, welches hinter SUSE Studio stand. Es unterstützt die Erstellung diverser image-Typen.\\
Die relevanten Dateien bestehen aus: einer Konfigurationsdatei(.xml), einem (optionalen) Quellarchiv(p.gz??), sowie optionalen Shellskripten.\\
Das Bauen von kiwi-images lässt sich in drei Phasen aufteilen: Das Generieren des Verzeichnisbaums und des images.
\subsubsection{Konfigurationsdatei}
Die Konfiguration des images erfolgt in einer XML-Syntax. Sie ist in verschiedene Sektoren gegliedert:\\
\textbf{description}\\
Dieser Abschnitt enthält Informationen über den Autor des Paketes.\\
\textbf{preferences}\\
Hier wird kiwi konfiguriert. Optionen wie der eigentliche Image-Typ, Firmwareart, Dateisystem oder zusätzliche Funktionen können hier angegeben werden.\\
In unserem Fall wird in preferences weiterhin angegeben:\\
\begin{itemize}
\item version: Die fortlaufende Versionsnummer, welche zu Releasezwecken oder kleineren Patches inkrementiert wird.
\item packagemanager: Enthält den für die Distribution zu verwendenden Paketmanager.(zypper unter openSUSE, apt unter debian etc.)
\item locale/keytable/timezone: Enthält Sprach-/Layout-/Zeiteinstellungen, um das System den Preferenzen des Nutzers anzupassen.
\end{itemize}
\textbf{user}: enthält zu erstellende Nutzer.\\
\textbf{repository}:\\
Hier werden die Paketquellen, aus welchen der OpenBuildService die zu installierenden Pakete beziehen soll, angegeben. Alternativ können diese auch als Archiv im Projekt mitgeliefert werden.
Ebenfalls möglich wäre das Kopieren und Modifizieren eines bereits existierenden Paketes innerhalb des Projekts.\\
\textbf{packages}:\\
Enthält die in das image zu integrierenden Pakete. Neben den für die Distribution zwingend benötigten Paketen liefern wir an dieser Stelle noch einen konfigurierten Salt-Minion mit, mittels dessen wir, wie in Sektion Salt erwähnt(Link??), die weitere Installation/Konfiguration vornehmen können.
\textbf{}
\subsubsection{Quellarchiv}
\subsubsection{Shellskripte}
\subsubsection{Generieren des Verzeichnisbaums}
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}
(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...(???)\\
\subsection{OpenBuildService}
Der OpenBuildService ist ein OpenSource-Projekt, welches von SUSE(erstellt(wann)??). Es ermöglicht Paketieren das automatische Bauen von Paketen oder images und hat einen Fokus auf Continuos Integration.
\subsubsection{Paketieren}
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.\\
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:
\begin{itemize}
\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.
\section{PXE-Boot}
\newpage
\section{automatisches Deployment}
\section{automatisches Deployment}
\newpage
\section{Fazit}
\section{Fazit}
Der ursprünglich für die Active Directory geplante invis-Server musste aufgrund von Konfigurationsproblemen und schwerwiegenden Differenzen zwischen unserem und dem für ihm geplanten Einsatzzweck leider entfernt werden.
Stattdessen wird nun direkt ein Kerberos-Client und sssd verwendet.
\newpage
\section{Verweise}
%Quellen
......
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