Bericht.tex 49.9 KB
Newer Older
1 2
\documentclass[12pt, a4paper, oneside, ngerman]{report}

3
%Import Packages
4 5 6 7
%set document layout
\usepackage[a4paper, left=3cm, right=2cm, top=2cm, dvipdfm]{geometry}
\usepackage[german,main=ngerman]{babel}
%format font
8
\usepackage[utf8]{inputenc}
9
\usepackage[T1]{fontenc}
10
\usepackage{titlesec}
11
\usepackage{url}
Sarah Kriesch's avatar
Sarah Kriesch committed
12 13
%box around verbatim
\usepackage{fancyvrb}
mainja67707's avatar
mainja67707 committed
14 15
% Use Links
\usepackage{hyperref}
16

17 18 19 20 21 22 23 24 25 26 27 28
% for code sections
\usepackage{listings}
\usepackage{color}

% configuring code sections
% change default language in Document with \lstset{language=Python}
% Code in \begin{lstlisting} Code \end{lstlisting}
\definecolor{dkgreen}{rgb}{0,0.6,0}
\definecolor{gray}{rgb}{0.5,0.5,0.5}
\definecolor{mauve}{rgb}{0.58,0,0.82}

\lstset{frame=tb,
Sarah Kriesch's avatar
Sarah Kriesch committed
29
  language=bash
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
  aboveskip=3mm,
  belowskip=3mm,
  showstringspaces=false,
  columns=flexible,
  basicstyle={\small\ttfamily},
  numbers=none,
  numberstyle=\tiny\color{gray},
  keywordstyle=\color{blue},
  commentstyle=\color{dkgreen},
  stringstyle=\color{mauve},
  breaklines=true,
  breakatwhitespace=true,
  tabsize=3
}

%BibTeX for References
\usepackage[
backend=biber,
style=alphabetic,
citestyle=alphabetic
]{biblatex}

\bibliography{libbib.bib} 
53 54

\title{Automatisches Deployment von openSUSE Leap\\
55 56 57 58
	    mit Salt und PXE\\
	    Projektarbeit}
\author{Jannik Main, Sarah Julia Kriesch}

59 60
\begin{document}
	\maketitle
61 62
    %Inhaltsverzeichniss generieren
    \tableofcontents
63
	\newpage
64 65 66 67 68 69 70
	\chapter{Vorwort}
		Die Wartung und Instandhaltung von Laboren ist ein oft komplexes und
        sehr zeit-konsumierendes Unterfangen.\\
		Hierbei ist es wichtig, eine Balance zwischen neuesten Features und
        Softwareupdates für die Nutzer, hier vorwiegend Studierende,
        bereitzustellen und nichtsdestotrotz eine grundsätzliche Stabilität und
        Sicherheit zu gewährleisten.\\
mainja67707's avatar
mainja67707 committed
71
		Bei der Wahl des Betriebssystems werden deshalb meist LTS- Long Term
72 73 74 75 76 77 78 79 80 81 82 83 84
        Support Versionen eingesetzt, die über einen langen Zeitraum auf
        Stabilität getestet wurden und sich insbesondere für Serversysteme
        eignen.\\
		Auch die Konfiguration und Anpassung auf die Hochschulinterne
        Infrastruktur, etwa der Zugriff auf das Active Directory und die
        Möglichkeit den Labor-eigenen Druckdienst über ein Ticket zu verwenden
        stellt hinsichtlich der Einrichtung eine Herausforderung dar.\\
		Zuletzt sollte auch die auf den Rechnern verfügbare Software, etwaige
        IDE's wie die Jetbrains-Produkte oder eine TeX Live IDE der Software
        entsprechen, die die Studierenden bereits einsetzen können und mit der
        sie oft in Kontakt kommen. \\
		In Anbetracht der Entwicklungsgeschwindigkeit heutiger Software stellt
        ein Automatisches Deployment deshalb eine wichtige Hilfestellung für
mainja67707's avatar
mainja67707 committed
85 86 87 88 89 90
        Administratoren dar.\\
        Mit unserem Projekt möchten wir genau hier ansetzen, und den
        Adminstrationsaufwand für unser fakultätseigenes Linux-Labor auf ein
        Minimum reduzieren. Hierdurch soll auch der Aufwand für den
        Updatevorgang aller Rechner so weit reduziert werden, das dies
        problemlos unter dem Semester möglich wäre.
91 92 93
	\chapter{Ist-Analyse}
		Momentan ist das Linux-Labor mit Ubuntu eingerichtet.
        Die Systeme wurden manuell installiert und konfiguriert.
Sarah Kriesch's avatar
Sarah Kriesch committed
94 95 96 97
        Die Authentifizierung mit dem Active Directory mit Kerberos und
        die Einbindung der Windows-Laufwerke wurden manuell eingepflegt. Die
        Home-Verzeichnisse wurden dort nicht mit eingebunden, so dass so gut
        wie nie ein Student dort seine Daten vom Linux-Labor aus abgelegt hat.\\
98 99 100 101
        Der Drucker wurde mit Cups überall eingerichtet und hinterher so
        konfiguriert, dass das Druck-Budget über Kerberos-Tickets bei den
        entsprechenden Studenten abgebucht wird.
	\chapter{Projektziel}
Sarah Kriesch's avatar
Sarah Kriesch committed
102 103 104 105 106 107 108 109 110 111 112 113
	    Alle Linux-Systeme müssen ans Active Directory angebunden werden, 
	    damit sich jeder Informatik-Student dort anmelden kann. Für die 
	    automatische Erstinstallation ist ein PXE-Server mit iso-Image notwendig. 
	    Dann wird über das Netzwerk gebootet und die Installation durchgeführt. \\
	    Die Installation und Konfiguration soll automatisch mit 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. \\
        Alle Studenten arbeiten auf den Windows-Rechnern auf ihrem Windows-Laufwerk, 
        wo alle Daten abgespeichert werden. Das soll auch unter Linux mit cifs 
        möglich sein, so dass die Studenten alle wichtigen Daten dort ablegen 
        können und nicht an einen Rechner gebunden sind.
114 115
	\chapter{Salt}
		\section{Einführung}
Sarah Kriesch's avatar
Sarah Kriesch committed
116
            Salt ist eine Open-Source-Konfigurationsmanagement-Software und
117 118 119 120
            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.
mainja67707's avatar
mainja67707 committed
121 122 123
            Beide besitzen zwei asymetrische Schlüssel, über den sie sich den
            anderen gegenüber authentifizieren und mit ihnen kommunzieren
            können.\\
124 125 126 127 128 129 130 131 132 133 134
		\section{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
Sarah Kriesch's avatar
Sarah Kriesch committed
135
            distributionsspezifische, sowie umgebungsabhängige
136
            Installationskonfigurationen hinterlegt werden (Von hier an nur noch 
Sarah Kriesch's avatar
Sarah Kriesch committed
137 138
            als distibutionsspezifische Konfigurationen bezeichnet). Dies ist
            z.B.\ bei variierenden Paketnamen ungemein hilfreich.\\
139
            Die Dateiendung ist, soweit nicht genauer spezifiziert, eine
mainja67707's avatar
mainja67707 committed
140
            \text{*}.sls.
141 142
            Die drei verwendeten Verzeichnisse heißen standardmäßig salt,
            pillar, formulas.
143 144 145 146 147 148 149 150 151
            \subsection{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
152 153
                ohne weitere Konfigurationen hinreichend ist. \\
                Genauso weren mit include die Formulas mit eingebunden und 
154
                entsprechende Installationen von dort aus ausgeführt.
155 156 157
            \subsection{pillar}
                Das Pillar-Verzeichnis steht für Variablen, Sensitive Daten,
                Konfigurationen und sonstige zu übertragende Daten zur
Sarah Kriesch's avatar
Sarah Kriesch committed
158 159
                Verfügung. Jedes von SaltStack akzeptierte Formula enthält 
                eine Datei mit dem Namen pillar.example.sls, die man als Vorlage
160 161 162 163
                ins Pillar-Verzeichnis kopieren und in die top.sls mit einbinden
                kann. Anschließend werden dann die Beispiel-Einträge mit den
                eigenen Systemkonfigurationen angepasst, so dass über das 
                entsprechende Salt-Formula die angepassten Konfigurations-Dateien
Sarah Kriesch's avatar
Sarah Kriesch committed
164
                automatisch hinzugefügt werden.
165
            \subsection{formulas}
166 167 168 169 170
                Formulas sind eine Konfigurations-/Installationsschnittstelle für 
                aufwendigere Pakete, welche meist nicht über einen Paketmanager 
                installierbar oder konnfigurierbar sind. Mit Hilfe von Formulas
                lassen sich aufwändige Installationsroutinen mit automatischen
                Konfigurationen auf Deployments in wenigen Minuten reduzieren. \\
mainja67707's avatar
mainja67707 committed
171 172
                Es wurden folgende Formulas aus verschiedenen
                github-Repositories verwendet:
173
                \begin{itemize}
Sarah Kriesch's avatar
Sarah Kriesch committed
174 175 176 177 178 179 180 181 182 183 184 185 186 187
                    \item Java: \\
                        \url{https://github.com/salt-formulas/salt-formula-java}
                    \item Jetbrains CLion: \\
                        \url{https://github.com/saltstack-formulas/jetbrains-clion-formula}
                    \item Jetbrains Intellij-IDEA:\\
                        \url{https://github.com/saltstack-formulas/jetbrains-intellij-formula}
                    \item Jetbrains PHPStorm: \\
                        \url{https://github.com/saltstack-formulas/jetbrains-phpstorm-formula}
                    \item Kerberos: \\
                        \url{https://github.com/saltstack-formulas/kerberos-formula}
                    \item Samba mit winbind-AD:\\
                        \url{https://github.com/saltstack-formulas/samba-formula}
                    \item SSSD:\\
                        \url{https://github.com/colin-stubbs/salt-formula-sssd}
188
                \end{itemize}
Sarah Kriesch's avatar
Sarah Kriesch committed
189
                \\
mainja67707's avatar
mainja67707 committed
190 191 192 193 194
                Diese Formulas werden in der Master-Konfiguration
                /etc/salt/master unter der Kategorie
                file\textunderscore{}roots alle
                aufgelistet, so dass alle Installationen und Konfigurationen aus
                dem Verzeichnis /srv/formulas/
195 196 197 198 199
                aufgerufen werden können. Jedes Forumula hat eine README-Datei,
                wo die Verwendung der Optionen (states) für die sls-Datei im 
                salt-Verzeichnis mit aufgelistet ist. Zum Beispiel hat sssd die
                States sssd und sssd.sysauth. Weil sssd zusammen mit dem 
                Kerberos-Formula zur Kerberos-Initialisierung gebraucht wird,
mainja67707's avatar
mainja67707 committed
200
                wurde die kerberosIn.sls unter /srv/salt/ angelegt und für
mainja67707's avatar
mainja67707 committed
201
                sssd folgender Eintrag mit angelegt:\\
Sarah Kriesch's avatar
Sarah Kriesch committed
202
                \begin{Verbatim}[frame=single]
Sarah Kriesch's avatar
Sarah Kriesch committed
203
                    include: 
mainja67707's avatar
mainja67707 committed
204 205
                      -\ sssd 
                      -\ sssd.sysauth
Sarah Kriesch's avatar
Sarah Kriesch committed
206
                \end{Verbatim}
mainja67707's avatar
mainja67707 committed
207
                      \\
208 209
                Mit dem include wird sicher gestellt, dass diese Optionen zur
                Installation und Konfiguration ausgeführt werden.
210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229
            \subsection{Passwort-Verschlüsselung}
                Bisher wurde die Erst-Authentifizierung am Kerberos-Server manuell
                durchgeführt. Viele Salt-Formulas haben auch die Option der 
                Benutzer-Authentifizierung. Allerdings werden in den Beispielen
                dann die Passwörter als Klartext mit angegeben. Auf der Konferenz
                FrOSCon haben wir den Tipp bekommen die Passwörter mit gpg zu
                verschlüsseln. Das wird auch an der TU Chemnitz so gehandhabt.\\
                Nach diesem Vorschlag wurde uns von Herrn Fischer ein Benutzer
                erstellt.\\
                Salt hat eine Option mit gpg Passwörter zu entschlüsseln.
                Dafür generiert man mit gpg auf dem Salt-Master ein Schlüsselpaar,
                worauf Salt ohne Passwort zugreifen kann. Hier gab es das Problem,
                dass mit der Aktualisierung auf gpg2 der Befehl geändert hat,
                weil es aus Sicherheitsgründen besser ist immer ein Passwort
                mit zu übergeben. \\
                Dann kann mit Hilfe des Schlüssels das entsprechende Passwort
                verschlüsselt werden. Die daraus resultierende PGP-Message wird in
                Base64 kodiert ausgegeben und kann dann so als Multiline-String
                unterhalb einer Pipe in eine sls-Datei eingefügt werden. \\
                Damit Salt weiß, dass hier gpg zur Entschlüsselung verwendet werden soll,
mainja67707's avatar
mainja67707 committed
230 231 232
                wird in der master-Konfiguration gpg\textunderscore{}keydir und
                decrypt\textunderscore{}pillar entkommentiert.
                Dort werden dann das Verzeichnis vom Schlüssel
233 234
                und der entsprechende Pillar-Eintrag mit angegeben. So kann dann
                der Salt-Master mit Hilfe von gpg das Passwort aus der PGP-Message lesen.\\
mainja67707's avatar
mainja67707 committed
235 236
                Eine ausführliche Anleitung wurde dazu als Blog-Artikel
                veröffentlicht\cite{sarah:gpg_salt}.
237
        \section{Salt-Minion}
mainja67707's avatar
mainja67707 committed
238
            \label{sec:salt_min}
239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257
            Der Salt-Minion ist die Clientseitige Software, welche auf den
            automatisch zu konfigurierenden Linux-Rechnern installiert werden
            muss. Er führt die vom Salt-Master erhaltenen Befehle aus und
            konfiguriert somit das System nach der hinterlegten Anleitung.\\
            Für die Konfiguration des Salt-Minions muss die IP des Salt-Masters
            und dessen Fingerabdruck in der Konfigurationsdatei /etc/salt/minion
            hinterlegt werden. Anschließend muss der Minion noch vom Master
            hinzugefügt werden. Ersteres soll über das OpenBuildService
            PXE-image bereits automatisiert geschehen.
        \section{Software-Stack}
            Die durch Salt verwaltete und konfigurierte Software ist im
            folgenden mit einem kurzen Erfahrungsbericht und weiterführenden,
            wichtigen Hinweisen kurz aufgezählt.
            \subsection{Java}
                Die Java Runtime Environment und das Java Software Development
                Kit sind zwei grundlegende Anforderungen für Universitätsrechner
                für Studierende mit Programmierkenntnissen.
                Leider mussten wir jedoch feststellen, das Java und openSUSE
                sich nach wie vor nur schwer zur Zusammenarbeit überreden
Sarah Kriesch's avatar
Sarah Kriesch committed
258 259 260 261
                lassen. Bis jetzt gibt es einige Anleitungen, wie man Java
                manuell mit Aufwand installieren kann. \\
                Deshalb wurde hier ein Salt-Formula für Java mit ausgewählt, so dass
                es mit der aktuellsten Version installiert und konfiguriert wird.
262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285
            \subsection{JetBrains}
                Um die Softwareentwicklung den Studierenden möglicht einfach zu
                machen, installierten wir einige IDEs. Die JetBrains-Produkte
                erfreuen sich hierbei unter den Studenten an zunehmender
                Beliebtheit, da diese ihnen über eine Studentenlizen auch auf
                ihren Privatrechnern kostenlos zur Verfügung steht.
                Neben dem Standartumfang sind sie besonders für ihre
                CodeCompletion-Funktionen bekannt.\\
                Wir haben uns hierbei für drei IDEs entschieden:
                \begin{itemize}
                    \item Intellij für Java-Entwicklung
                    \item PhpStorm für Webentwicklung
                    \item CLion für C/C++ Entwicklung
                \end{itemize}
                \subsubsection{Installation}
                    Die IDEs werden über die zugehörigen Formulare automatisch
                    installiert und stehen den Studierenden zur Verfügung.\\
                    Für Intellij IDEA musste weiterhin Java installiert werden.
                \subsubsection{Lizensierung}
                    Um die IDEs nutzen zu können, muss der Hochschuleigene
                    Lizenzserver verwendet werden.\\
                    Um die Webaddresse des Lizenzservers automatisiert zu
                    hinterlegen, muss im HOME-Verzeichnis der Studierenden ein
                    Folgende Dateistruktur für jede IDE angelegt werden:
mainja67707's avatar
mainja67707 committed
286
                    \textquotedblleft.\textless{}IDE\textgreater{}\textless{}Versionsnummer\textgreater{}/config/\textless{}IDE\textunderscore{}in\textunderscore{}Kleinbuchstaben\textgreater{}.key\textqoutedblright{}
287 288 289 290 291 292 293 294 295 296 297
                    erstellt werden.\\
                    Hierfür werden diese unter /etc/jetbrains erstellt und beim
                    Login in das HOME-Verzeichnis der Studierenden kopiert.
                \subsubsection{Erfahrungsbericht}
                    Problematisch war hier insbesondere das erstellen der
                    Verzeichnisse, da hierfür die Versionsnummer ausgelesen
                    werden musste.\\
                    Nach einigen anfänglich erfolglosen Versuchen diese aus
                    Konfigurationsdateien zu extrahieren entwickelten
                    wir ein Shellskript, welches diese Information aus den
                    Ordnernamen unter /usr/local/jetbrains extrahiert.
Sarah Kriesch's avatar
Sarah Kriesch committed
298
            \subsection{Visual Studio Code}
299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317
                Neben den JetBrains IDEs erfreut sich auch VisualStudio Code
                immer größerer Beliebtheit. Da dieses, im Gegensatz zu
                VisualStudio, OpenSource-Softare ist, wollten wir auch dieses
                Tool zur Verfügung stellen.
                \subsubsection{Installation}
                    Für VisualStudio Code existiert ein Formula.\\
                    Bis auf den im Erfahrungsbericht angesprochenen Bug verlief
                    die Installation hiermit problemlos.
                \subsubsection{Erfahrungsbericht}
                    Da für die Installation ein zusätzliches Repository zum
                    Paketmanager zypper hinzugefügt werden sollte, fanden wir
                    hier einen Bug.\\
                    Entgegen der Annahme importiert rpm den GPG-Schlüssel nicht
                    automatisch mit in seinen Schlüsselspeicher. Die Folge war
                    dementsprechend, das das Paket von einem für rpm unbekannten
                    GPG-Schlüssel signiert und somit zurückgewiesen wurde.\\
                    Unser Workaround besteht darin, mittels Salt den rpm-Befehl
                    seperat auszuführen und somit den Schlüssel
                    hinzuzufügen.\cite{github:zypper}
Sarah Kriesch's avatar
Sarah Kriesch committed
318 319 320 321 322 323 324 325
            \subsection{Latex}
                Latex ist die Grundlage für wissenschaftliches Arbeiten und
                Dokumentationen an der Hochschule. Deshalb sollte auf jedem Linux-Client
                ein Latex-Editor mit allen notwendigen Features von Latex mit
                installiert werden.
                \subsubsection{texlive}
                    Es gibt unterschiedliche Pakete von texlive für Latex zur Auswahl.
                    Diese bringen jeweils einen unterschiedlichen Umfang an 
Sarah Kriesch's avatar
Sarah Kriesch committed
326 327
                    Funktionalitäten mit.\\
                    Damit es zu keinen Problemen beim Kompilieren
Sarah Kriesch's avatar
Sarah Kriesch committed
328 329 330 331 332 333
                    kommt und weil der Festplattenplatz der Clients im Labor mehr
                    als ausreicht, wird hier das Paket texlive-scheme-full verwendet.
                \subsubsection{Texmaker}
                    Während des Studiums wurden schon Erfahrungen mit Latex gesammelt 
                    und Texmaker hat sich als hilfreicher Lieblings-Editor herausgestellt.
                    Deshalb wird im latex.sls Texmaker als Editor mit installiert.
Sarah Kriesch's avatar
Sarah Kriesch committed
334 335
                    Somit kann in der Zukunft auch im Linux-Labor mit Latex 
                    gearbeitet werden.
336
	\chapter{Kerberos}
Sarah Kriesch's avatar
Sarah Kriesch committed
337 338 339 340 341 342 343 344 345 346 347 348 349 350 351
	Kerberos wird zur Authentifizierung mit dem Active Directory gebraucht.
	Genauso ist dieser Dienst zur Ticket-Generierung beim Drucken und zur
	Geldabbuchung bei den Studenten-Accounts benötigt. \\
	Weil zur Benutzer-Authentifizierung nicht nur die Datei krb5.conf 
	konfiguriert werden und zusätzlich der SSSD-Client eingerichtet werden muss,
	werden neben dem Kerberos-Formula noch das SSSD-Formula, das Samba-Formula
	und das PAM-Formula gebraucht.
	 \section{SSSD-Formula}
	    Der SSSD-Client ist die Grundlage des Usermanagements und der 
	    Systemauthentifizierung am Active Directory auf den Linux-Clients.
	    Das sssd-Formula wurde bisher nur mit Debian, Ubuntu und Red Hat getestet.
	    Deshalb musste in der Datei map.jinja Suse als Betriebssystemkategorie
	    hinzugefügt werden. Genauso wurde dort sssd als notwendiges Paket mit 
	    seinem Daemon als service mit angegeben. \\
	    Leider wurde dieses Formula bisher auch nur mit LDAP verwendet und dafür 
Sarah Kriesch's avatar
Sarah Kriesch committed
352 353 354 355 356 357 358 359 360
	    bereitgestellt. Auch hier mussten die Konfigurationen dann erweitert werden. \\
	    Hinzu kommt eine spät genannte Anforderung, dass sich an den Rechnern
	    nur Informatik-Studenten anmelden können sollen. Dafür muss neben der
	    Anmeldung mit dem Active Directory der LDAP-Baum mit angegeben und 
	    überprüft werden, ob der Benutzer in der Gruppe ou=Students ist. \\
	    Bei diesem Formula kann man die Möglichkeit der einfachen Erweiterbarkeit 
	    der sssd.conf mit eigenen Parametern positiv hervorheben. Somit war es 
	    möglich den Eintrag ldap durch ad zu ersetzen und weitere Optionen mit 
	    anzugeben, die dann mit übernommen wurden. \\
Sarah Kriesch's avatar
Sarah Kriesch committed
361 362 363 364 365 366 367 368 369 370 371 372
	    Damit der SSSD-Daemon  funktioniert, werden keytab-Dateien gebraucht, die
	    mit dem Kerberos-Formula mit eingebunden werden können.
	 \section{Kerberos-Formula}
	    Das Kerberos-Formula wird schon für openSUSE angeboten. Allerdings wird
	    mit der Option kerberos.keytab nur die Einbindung schon existierender
	    keytab-Dateien mit angeboten, so dass sich der Benutzer für die 
	    unterschiedlichen Dienste im Netzwerk, wie z.B. ssh und cifs mit unseren 
	    Windows-Laufwerken, automatisch direkt anmelden kann. Als Minimum wird die
	    Standard-Datei krb5.keytab gebraucht. Leider haben unsere Administratoren 
	    die Anforderung, dass diese keytab-Dateien automatisch mit der ersten 
	    Anmeldung unseres Benutzers mit angelegt werden. \\
	    Dafür wird noch eine Konfiguration des samba-clients und folgende Befehle
mainja67707's avatar
mainja67707 committed
373
	    automatisiert gebraucht:
Sarah Kriesch's avatar
Sarah Kriesch committed
374
	    \lstset{language=bash}
Sarah Kriesch's avatar
Sarah Kriesch committed
375
	      \begin{lstlisting}[frame=single]
Sarah Kriesch's avatar
Sarah Kriesch committed
376 377 378 379 380 381 382 383
	         net ads join -U ${Benutzer}%${Passwort} 
	         net ads keytab list 
	         klist -k 
	         net ads list 
	         net ads kerberos 
	         net ads keytab add cifs ipp nfs ftp ssh http -U ${Benutzer} 
	         klist -k
	      \end{lstlisting}
Sarah Kriesch's avatar
Sarah Kriesch committed
384 385 386 387 388 389
	    Nach dem Joinen des Principals wird die Keytab-Liste generiert und
	    mit klist bestätigt. Dann wird diese zu Kerberos hinzugefügt. 
	    Genauso werden noch alle notwendigen Dienste in diese Datei geladen und
	    mit klist gemerged. 
	    \\
	    \\
Sarah Kriesch's avatar
Sarah Kriesch committed
390 391 392 393 394 395 396 397 398 399
	    Weil man so eine automatische Generierung der keytab-Dateien mit dem 
	    Kerberos-Formula als ToDo in der Zukunft geplant hatte, wurde dieses
	    Feature von uns implementiert und mit in die keytab.sls integriert. \\
	    Außerdem ist wie das SSSD-Formula dieses Formula auf LDAP statt Active Directory
	    ausgelegt, weshalb ein Kerberos-Paket für Active Directory mit in der Liste
	    für Suse-Systeme aufgenommen wurde. Genauso konnte hier die Liste der 
	    Parameter für die Konfigurationen ohne Probleme angepasst und erweitert
	    werden. Die notwendigen Daten wurden von den Admins bereit gestellt.
	  \section{Samba-Formula}
	    Der Benutzer vom Kerberos kann ohne Samba-Konfiguration nicht 
Sarah Kriesch's avatar
Sarah Kriesch committed
400 401 402 403 404 405 406 407 408 409 410
	    funktionieren. Deshalb wurde noch das Samba-Formula mit hinzugefügt. \\
	    Das Samba-Formula installiert  nicht nur den samba-client, sondern konfiguriert die smb.conf und
	    nsswitch.conf so, dass die Kerberos-Authentifizierung mit aktiviert wird.
	    Genauso bietet dieses Formula die Funktionalität, dass der erste
	    Hauptbenutzer einer Domain joinen kann und entsprechend den Windows-Laufwerken
	    die Home-Verzeichnisse mit angelegt werden. \\
	    Somit ist das Samba-Formula nicht nur für Kerberos hilfreich, sondern 
	    erfüllt schon zusätzliche Anforderungen mit, die eigentlich separat von
	    der Kerberos-Authentifizierung angegangen werden sollten. Außerdem
	    beinhaltet die smb.conf die Konfiguration, dass zum Drucken cups verwendet werden
	    soll, was schon zum Anfang des Projekts mit beschlossen wurde.
Sarah Kriesch's avatar
Sarah Kriesch committed
411
	  \section{PAM-Formula}
mainja67707's avatar
mainja67707 committed
412 413
	    Das Windows-Laufwerk wurde bisher mit PAM und der Datei
        pam\textunderscore{}mount\textunderscore{}conf.xml
Sarah Kriesch's avatar
Sarah Kriesch committed
414 415
	    mit Hilfe von cifs gemountet. Diese Datei wird mit dem PAM-Formula mit
	    eingebunden und konfiguriert.
Sarah Kriesch's avatar
Sarah Kriesch committed
416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434
	  \section{Fazit zu Kerberos}
	    Eigentlich erfordert ein anständiger Softwareentwicklungsprozess,
	    dass man ein Modul nach dem anderen einbindet und zuerst dessen Funktionalität
	    testet, bevor man die nächste Aufgabe angeht. Das sollte auuch hier
	    umgesetzt werden. Leider haben sich dann immer mehr Abhängigkeiten zwischen
	    den Formulas ergeben, weil eine manuelle Eingabe oder automatische Generierung
	    der keytab-Dateien gewünscht wurde. \\
	    Zuerst war nur geplant das sssd-Formula und das Kerberos-Formula zu verwenden,
	    weil diese die Grundlagen zur Kerberos-Authentifizierung bieten und alles
	    notwendige dafür bereitstellen. Dann stellte sich heraus, dass zum
	    Joinen die smb.conf und nsswitch.conf gebraucht werden und deshalb die
	    Integration der notwendigen Befehle im Kerberos-Formula fehlschlugen.
	    Deshalb kam dann noch das Samba-Formula dazu, womit die Kette der 
	    Abhängigkeiten länger wurde. Allerdings wurden damit mehrere Anforderungen,
	    wie z.B. die Einbindung der Windows-Laufwerke und die Authentifizierung mit
	    der Generierung der Benutzer-Verzeichnisse, auf einmal erfüllt. \\
	    Allerdings hat das eine nicht vorhersehbare Komplexität mitgebracht,
	    die dann wieder einiges an Zeit der Umsetzung und Lösungsfindung gebraucht hat.
	    
435 436 437 438 439 440 441
	\chapter{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.
		\section{SUSE Studio}
442 443 444 445 446 447
            SUSE Studio stellte ein graphisches Frontend für das
            Kommandozeileninterface kiwi dar, welches für die Erstellung von
            images verwendet wird.
            Leider war SUSE Studio zum Projektzeitpunkt nicht mehr öffentlich
            verfügbar, weshalb besagte images nun über kiwi in Kombination mit
            dem OpenBuildService gebaut werden müssen.
448
		\section{kiwi}
mainja67707's avatar
mainja67707 committed
449
            Kiwi ist der Name des Kommandozeilentools, welches hinter SUSE
450 451 452
            Studio stand.
            Es unterstützt die Erstellung diverser image-Typen.\\
            Die relevanten Dateien bestehen aus: einer Konfigurationsdatei 
mainja67707's avatar
mainja67707 committed
453
            (.xml), einem (optionalen) Quellarchiv (meist tar.bz2), sowie
mainja67707's avatar
mainja67707 committed
454 455 456
            optionalen Shellskripten. Die hier gefundene Zusammenfassung kann
            hier ausführlicher gefunden werden\cite{suse:kiwi}\\
            Das Bauen von kiwi-images lässt sich in zwei Phasen aufteilen: Das
457 458 459
            Generieren des Verzeichnisbaums und des images.
		\subsection{Konfigurationsdatei}
            Die Konfiguration des images erfolgt in einer XML-Syntax.
mainja67707's avatar
mainja67707 committed
460 461 462
            Für das Bauen auf dem Open Build Service muss jedoch die Datei auf
            \text{*}.kiwi enden.
            Sie ist in verschiedene Abschnitte gegliedert:\\
463 464
            \subsubsection{description}
                Dieser Abschnitt enthält Informationen über den Autor des
mainja67707's avatar
mainja67707 committed
465
                Paketes (Name, Kontakt), sowie weitere Informationen über das
466 467 468 469 470 471 472 473 474 475 476
                Image.\\
                In unserem Fall also:
                \begin{Verbatim}[frame=single]
<description type="boot">
    <author>Jannik Main</author>
    <contact>jannik.main@gmail.com</contact>
    <specification>
        openSUSE Leap 15.0 PXE boot with salt-minion
    </specification>
</description>
                \end{Verbatim}
477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492
            \subsubsection{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}
493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536
                \begin{Verbatim}[frame=single]
 <preferences>
    <type image="oem" boot="oemboot/suse-leap15.0" bootloader="grub2"
    bootpartition="true" installpxe="true" bootprofile="default"
    bootkernel="std" filesystem="ext4" firmware="efi"
    kernelcmdline="splash"/>
    <version>2.8.0</version>
    <packagemanager>zypper</packagemanager>
    <locale>en_US</locale>
    <keytable>de</keytable>
    <timezone>Europe/Berlin</timezone>
    <rpm-excludedocs>true</rpm-excludedocs>
    <rpm-check-signatures>false</rpm-check-signatures>
    <bootsplash-theme>openSUSE</bootsplash-theme>
    <bootloader-theme>openSUSE</bootloader-theme>
  </preferences>
                \end{Verbatim}
                Besonders interessant sind hierbei die types-Attribute, deren
                korrekte Konfiguration und Verständnis uns die meiste Zeit
                gekostet haben. Deshalb sind diese noch einmal extra aufgeführt:
            \subsubsection{perferences/type}
                Die von uns derzeit verwendeten Parameter zielen auf ein
                pxe-bootbares oem-image ab, welches den Kontent des Daten-images
                auf die Festplatte kopiert.
                \begin{itemize}
                    \item image: Dies definiert den Typ des images. Neben oem
                        kann hier beispielsweise auch iso eingetragen werden, um
                        eine iso-Datei zu erstellen (Was jedoch nicht mit den
                        restlichen Parametern kompatibel wäre).
                    \item boot, bootloader, bootpartition, bootkernel,
                        bootprofile: Hier wird die zu wählende Konfiguration
                        für den Bootvorgang bestimmt.
                    \item installpxe: Dieser essentiell wichtige Parameter teilt
                        kiwi mit, das wir ein oem-basiertes PXE-Image und kein
                        standart oem-Image haben möchten.
                    \item filesystem: Gibt das Dateisystem für das Datenimage
                        an.
                    \item firmware: Gibt an, ob ein BIOS/Legacy-bootbares oder
                        ein UEFI-bootbares Image erstellt wird.
                    \item kernelcmdline: Enthält Bootparameter für den Kernel.
                \end{itemize}
                Für weitere Informationen zu den verschiedenen, möglichen
                Parametern, siehe\cite{suse:kiwi_schema} und
                teilweise\cite{suse:kiwi}.
537
            \subsubsection{user}
538 539 540 541
                Enthält zu erstellende Nutzer.\\
                An dieser Stelle haben wir den Root-Nutzer mit einem
                Beispielpasswort eingefügt, welches, da es öffentlich sichtbar
                ist, zwingend geändert werden sollte.
542 543 544 545 546 547 548 549 550 551 552
            \subsubsection{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.
            \subsubsection{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
mainja67707's avatar
mainja67707 committed
553 554 555
                Salt-Minion mit, mittels dessen wir, wie in
                \hyperref[sec:salt_min]{Sektion Salt} erwähnt, die weitere
                Installation/Konfiguration vornehmen können.
556
		\subsection{Quellarchiv}
mainja67707's avatar
mainja67707 committed
557 558
            Die Quellrepositories müssen alle Pakete beinhalten, die das image
            beinhalten soll. Im Normalfall ist dies der Open Build Service.
559
		\subsection{Shellskripte}
mainja67707's avatar
mainja67707 committed
560 561 562 563 564 565 566 567 568 569 570
            Währende des Erstellprozesses werden bis zu zwei optionale
            Shellskripte ausgeführt: images.sh und config.sh
            \subsubsection{images.sh}
                Wird zu Beginn des zweiten Teilbereiches (Nach Ende der
                Erstellung des Verzeichnisbaums) ausgeführt, sofern vorhanden.\\
                Soll das System durch das Entfernen von Daten, die nur für das
                Generieren des Verzeichnisbaumes erforderlich sind, das Image
                aufräumen.
            \subsubsection{config.sh}
                Wird am Ende der Installation, aber vor den Paketskripten im
                Generieren des Verzeichnisbaums-Abschnitt ausgeführt.
571 572 573 574 575 576
		\subsection{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,
mainja67707's avatar
mainja67707 committed
577
            sowie wichtige Bauelemente beinhaltet, spiegelt das
578 579
            Verzeichnis das spätere Innenleben des images wieder.\\
            Zum Ende dieses Erstellungsprozesses wird noch das config.sh-Skript,
mainja67707's avatar
mainja67707 committed
580
            sofern vorhanden, ausgeführt.
581 582 583 584 585 586 587 588 589 590 591
            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!
		\subsection{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
            generiertwerden.
mainja67707's avatar
mainja67707 committed
592 593
            Möglich sind beispielsweise USB-Live-Images, PXEBoot, Amazon EC2,
            Docker, KVM/Qemu, VirtualBox, VMWare oder auch Vagrant-Images.\\
594
		\section{OpenBuildService}
mainja67707's avatar
mainja67707 committed
595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627
            Der OpenBuildService ist ein OpenSource-Projekt, welches von
            SUSE-Entwicklern erstellt und seitdem aktiv gemaintaint wird.
            Es ermöglicht Paketierern das automatische Bauen von Paketen
            oder images und hat einen Fokus auf Continuos Integration.\\
            Auch wenn der größte Fokus auf SUSE-Produkten liegt, können auch
            andere Linux-Distributionen wie Debian oder Fedora hier Pakete
            und images für ihre Distribution bauen.
            Jeder Nutzer erhält ein mit seinem Account verknüpftes
            Home-Projekt, in dem er zunächst
            \textquotedblleft{}experimentieren\textquotedblright{} (neue
            Pakete anlegen) kann.
            Weiterhin kann der Nutzer Zugriff auf Nicht-Home-Projekte
            anfragen (beispielsweise als Paketmaintainer) oder ein eigenes,
            weiteres Projekt beantragen.
            \subsubsection{Pakete auf dem OBS}
                Paketierer haben beim erstellen von Paketen zwei
                grundsätzliche Probleme:
                \begin{enumerate}
                    \item muss das Paket für die Distribution/-en gebaut
                        werden, was auf dem lokalen Rechner je nach Leistung
                        ein wenig dauern kann.
                    \item müssen eventuelle Abhängigkeiten zu anderen
                        Paketen stets aktuell gehalten werden (das heißt,
                        der Paketautor muss sich immer alle aktuellen Pakete
                        herunterladen und sein Paket gegen diese bauen).
                \end{enumerate}
                Diesen beiden Problemen möchte der OpenBuildService
                vorbeugen.\\
                Das Prinzip ist hierbei einfach, statt seine erstellten
                Pakete selbst lokal zu bauen, übernimmt diese Aufgabe der
                OpenBuildService. Diesem stehen hierfür verschiedene Worker
                zur Verfügung, die die Aufträge nach einer Warteschlange
                abarbeiten.\\
628
                Sollten sich innerhalb des Paketes oder einer seiner
mainja67707's avatar
mainja67707 committed
629 630 631 632 633 634 635 636 637 638 639
                Abhängigkeiten etwas ändern, so wird dies vom
                OpenBuildService automatisch registriert und das Paket zum
                erneuten Bauen eingereiht.
            \subsubsection{osc}
                osc ist das Kommandozeilentool, um mit dem OpenBuildService
                zu interagieren. Zwar gibt es auch ein Webinterface, jedoch
                ist das osc-tool meiner Erfahrung nach trotz Einlernungszeit
                binnen kürzester Zeit effektiver und einfacher zu
                handhaben.\\
                Eingestellt ist das Tool auf build.opensuse.org, wobei auch
                andere, selbstgehostete Versionen eingestellt werden können.
640
            \subsection{rpmlint}
mainja67707's avatar
mainja67707 committed
641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658
                Der OpenBuildService verwendet eine speziell konfigurierte
                Version des rpmlint-tools.
                Dieses überprüft bauende Pakete auf bekannte Schwachstellen
                und Probleme.
                Neben normalen Problemen wie:
                \begin{itemize}
                    \item Fehlende Angaben wie Author
                    \item Ungültige oder unbekannte Lizenz
                    \item Ungültigen oder fehlenden Definitionen in der
                        Konfigurationsdatei
                \end{itemize}
                weden insbesondere potentielle Sicherheitsrisiken
                herausgefiltert. Dazu zählen beispielsweise:
                \begin{itemize}
                    \item modifizierte oder neue polkit-Regeln
                    \item setuid-binaries
                    \item binaries mit speziellen Capabilities
                \end{itemize}
659 660
                Falls diese kritisch sein sollten, wird hierdurch der
                Buildvorgang unterbrochen.
mainja67707's avatar
mainja67707 committed
661 662 663 664 665
                Um das Paket nun doch noch erfolgreich nach Factory zu
                bringen, muss nun ein manueller Audit des Paketes durch ein
                Mitglied der proaktiven Seite des security-teams durchgeführt
                werden. Dieser kann bei Bedarf die Änderungen auf ein
                Whitelist setzen und hierdurch das Bauen ermöglichen.
666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688
            \subsection{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}
mainja67707's avatar
mainja67707 committed
689
            \subsection{OBS auf anderen Systemen}
690
                Der OpenBuildService unterstützt neben SUSE-Distributionen auch
mainja67707's avatar
mainja67707 committed
691 692 693 694
                beispielsweise Debian, Ubuntu, Red Hat, sowie sogar Windows
                beim Paketbau.
                Auch andere Architekturen sind neben x86 (z.b. AMD64, z Systems,
                POWER) möglich\cite{suse:obs}
mainja67707's avatar
mainja67707 committed
695 696 697
        \section{Fazit zur Imageerstellung}
            Der Werdegang der Image-Erstellung hat sich rückblickend leider als
            kritisch herausgestellt. Problematisch war hier in erster Linie die
698 699 700
            Dokumentation, welche den Hinweis auf neuere Versionen und Verfahren
            nicht eindeutig plaziert hatte.\\
            Beispielsweise ist die ausführlichste Dokumentation\cite{suse:kiwi},
mainja67707's avatar
mainja67707 committed
701
            auf der ein Großteil dieses Abschnittes basiert, zwar prinzipiell
702 703 704 705 706
            richtig, die verwendeten Pakete mit enthaltenen Templates und Teile
            der erklärten Mechanismen existieren leider nach SLE 12 nicht mehr.
            Konkret lag das Problem hier daran, das wir das image mit
            image\text{=„pxe“} anstelle des empfohlenen image\text{=„oem“} und
            installpxe\text{=}true in den preferences unter type bauen wollten.
mainja67707's avatar
mainja67707 committed
707 708 709
            Dies war höchst bedauerlich, da wir nun mehrere Monate erfolgloser
            Versuche, anhand der hier erläuterten Mechanismen ein
            funktionstüchtiges Image zusammenzustellen für einen Abschnitt
710 711
            aufgewendet haben, der im Projektplan für wenige Tage vorgesehen
            war.\\
mainja67707's avatar
mainja67707 committed
712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730
            Über die korrekte Herangehensweise erfuhren wir erst nach langer
            Kommunikation mit verschiedenen Community-Mitgliedern, wenige Tage
            vor Ende der Projektfrist. Statt, wie lange vermutet ein Image vom
            Typ pxe zu bauen, ist die Verwendung eines oem-Images mit gesetztem
            pxeboot-Parameter die empfohlene Verwendungsweise.\\
            Nun angeführt sind einige Links zu aktuellen Seiten, welche
            aktuellere Informationen beinhalten und uns einiges an Arbeit
            erspart hätten:
            \begin{itemize}
                \item
                    \href{https://opensource.suse.com/kiwi/building/build_oem_disk.html}{kiwi-Dokumentation
                    für das Erstellen von OEM-Images (auch für PXE empfohlen)}
                \item
                    \href{https://doc.opensuse.org/projects/kiwi/schema-doc}{Schema-Dokumentation
                    für kiwi (enthält alle existierenden Optionen)}
                \item
                    \href{https://build.opensuse.org/package/show/Virtualization:Appliances:Images/kiwi-image-pxe-ramdisk}{Ein
                    Template für die Erstellung eines PXE-Images mit RAMDisk}
            \end{itemize}
731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747
            \subsection{Versionshergang}
                Die Idee war zu Beginn folgende: Zunächst wollten wir ein
                einfaches, funktionstüchtiges iso-Image bauen, da sich dies
                leichter testen ließe. Leider hat dies auch mit den
                Live-Image-Vorlagen nicht funktioniert, da diese nicht
                erfolgreich bauten.\\
                Nach einigen erfolglosen Versuchen, ein funktionstüchtiges
                iso-Image aufzusetzen, entschlossen wir uns aus Zeitgründen,
                direkt mit dem PXE-Image fortzufahren. Hierbei experimentierten
                wir mit sowohl mit image-type\text{=}pxe, als auch mit
                image-type\text{oem}, bei zweiterem wurde ich hier leider lange
                von der Fehlermeldung \textquotedblleft{}Unknown Image
                Flavor\textquotedblright{} abgelenkt, welche sich aufgrund der
                Parameterkonstellation ergaben.\\
                Da uns leider kein funktionstüchtiges Template für ein pxe-image
                wie in unserem Fall bekannt war,
                taten wir uns hier schwer, diese richtig zu verwenden.
748 749 750 751 752 753 754 755
    \chapter{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.
Sarah Kriesch's avatar
Sarah Kriesch committed
756
        \section{Installation}
Sarah Kriesch's avatar
Sarah Kriesch committed
757 758 759 760
        Auf dem PXE-Server wurden die Pakete atftpd, syslinux und
        vsftpd installiert. Die Konfiguration des atftpd-Daemons liegt unter 
        /etc/sysconfig/atftpd. \\
        Zum automatischen Start müssen diese Dienste mit \textquoteleft{}systemctl
761 762
        enable\textquoteright{}
        aktiviert und \\
Sarah Kriesch's avatar
Sarah Kriesch committed
763 764
        \textquoteleft{}systemctl start\textquoteright{}gestartet werden.
        \section{Firewall}
765
        Die Firewall-Ports sind nicht automatisch freigeschaltet.
Sarah Kriesch's avatar
Sarah Kriesch committed
766 767
        Deshalb braucht man folgende firewalld-Befehle:  \\
        \begin{lstlisting}[frame=single]
Sarah Kriesch's avatar
Sarah Kriesch committed
768 769 770 771 772 773 774
            firewall-cmd --add-service=tftp --permanent
            firewall-cmd --add-port=69/udp --permanent #TFTP
            firewall-cmd --add-port=67/udp --permanent #BOOTP
            firewall-cmd --add-port=67/tcp --permanent #BOOTP
            firewall-cmd --add-port=4011/udp --permanent
            firewall-cmd --reload
        \end{lstlisting}
Sarah Kriesch's avatar
Sarah Kriesch committed
775
        \section{Konfiguration}
776 777 778 779
        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
mainja67707's avatar
mainja67707 committed
780 781 782
        beiden Dateien pxelinux.0 und menu.c32 aus /usr/share/syslinux/
        nach /opt/tftpboot/ kopiert werden.
        Weil im DHCP-Server der Eintrag für /pxelinux.0 bei allen Hosts
783
        zum Booten steht, wurde noch ein Symlink von
mainja67707's avatar
mainja67707 committed
784
        /opt/tftpboot/pxelinux.0 nach /pxelinux.0 generiert.
785 786 787
        Damit nicht nur root die Dateien unter tftpboot lesen kann, mussten
        die Benutzerrechte rekursiv auf nobody:nobody mit 755 angepasst
        werden.
Sarah Kriesch's avatar
Sarah Kriesch committed
788 789 790
        \section{Boot-Konfiguration}
        Damit das Image geladen werden kann, muss in der Datei default unter
        /opt/tftpboot/pxelinux.cfg/ das Image und der Linux-Kernel mit angegeben
Sarah Kriesch's avatar
Sarah Kriesch committed
791
        werden. Bei einem OEM-Image sieht das in unserem Fall so aus: \\
Sarah Kriesch's avatar
Sarah Kriesch committed
792 793 794 795
        \begin{Verbatim}[frame=single]
          label install
          openSUSE mit eigenem Image installieren
          kernel preload/linux
796 797
          append initrd=preload/pxeboot.initrd
          rawimage=ftp://preload/opensuse-leap-15.0-image.x86_64-2.8.0-Build80.1.raw rawdevice=/dev/sda vga=normal pxe=1
Sarah Kriesch's avatar
Sarah Kriesch committed
798
        \end{Verbatim}
Sarah Kriesch's avatar
Sarah Kriesch committed
799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831
        \section{UEFI}
       Die Clients im Linux-Labor sind zwar schon etwas älter, aber bei der
       Projektplanung ging man davon aus, dass diese kein UEFI beim PXE-Bootvorgang
       mehr benötigen würden. Leider ließ sich das BIOS nicht so konfigurieren,
       dass PXE mit Legacy funktioniert. Selbst ein BIOS-Update hat nicht geholfen.
       Deshalb mussten aus dem openSUSE-Repository 
       http://download.opensuse.org/distribution/leap/15.0/repo/oss/boot/x86_64/loader/
       und http://download.opensuse.org/distribution/leap/15.0/repo/oss/EFI/BOOT/
       die Dateien message, memtest, bootx64.efi, grub.efi und grub.cfg ins Verzeichnis
       /opt/tftpboot/ kopiert werden. In der grub.cfg musste dann der menuentry
       von Installation auf das PXE-Verzeichnis unseres Images angepasst werden.
       Die Kennzeichnung mit linuxefi vor dem Installations-Verzeichnis sagt aus,
       dass hier UEFI verwendet werden soll.  \\
       Im DHCP-Server musste dann noch der Boot-Eintrag von pxelinux.0 auf 
       bootx64.efi umgeändert werden. \\
       Weil die Systeme kein Legacy unterstützen, ist damit auch die Konfiguration
       vom PXE-Server komplexer geworden.
       \section{UEFI und Legacy bei unterschiedlichen Systemen}
       Die Virtuellen Maschinen von Herrn Prof. Stappert verwenden kein UEFI.
       Somit sind die notwendigen Dateien (unter UEFI) hier nicht notwendig.
       Weil die Datei pxelinux.0 im selben Verzeichnis liegt, kann man ohne Probleme
       auch Legacy-Systeme installieren, indem man den Eintrag pxelinux.0 statt
       bootx64.efi verwendet. 
       \section{Fazit zum PXE-Server}
       Es wurde viel zu wenig Zeit für den PXE-Server mit eingeplant. Die Konfiguration
       wurde schon wegen UEFI komplexer. Hinzu kommt, dass bei der Verwendung von
       KIWI beim Imagebau in der default-Datei zusätzliche Paramiter wie kiwiserver
       mit der IP-Adresse des PXE-Servers notwendig sind und im tftpboot-Verzeichnis
       ein KIWI-Verzeichnis mit einer speziellen KIWI-Konfiguration für den Bootvorgang
       mit angelegt werden muss. Der TFTP-Server hat einige dieser Optionen in der
       default-Datei nicht erkennen können, was das Debuggen deutlich erschwert hat.\\
       Nach diesen Problemen wurde noch nachträglich (nach dem Hinweis des 
       KIWI-Entwicklers Marcus Schäfer) auf das OEM-Image gewechselt.
832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852
    \chapter{automatisches Deployment}
	\chapter{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.
        Das bringt einiges an Komplexität mit sich, weil sämtliche
        LDAP-Spezifikationen mit Verbindung zum Active Directory als
        Konfigurationen zusätzlich mit angegeben werden müssen.\\
        Eines der Dinge, welche uns leider große Schwierigkeiten bereitet hat,
        war die Erstellung des PXE images mit kiwi. Um so ärgerlicher war nun zu
        erfahren, das es für die Erstellung eines solchen bereits eine
        einfacherer, modernere Lösung geben soll. Dies erfuhren wir am
        27.Februar, kurz vor der Fertigstellung unserer Variante.\\
        An dieser Stelle muss auf jeden Fall die Dokumentation angepasst werden,
        welche leider allgemein im Falle von kiwi mit dem OpenBuildService sehr
        schwer nachzuvollziehen (und teilweise nicht mehr auf dem neuesten
        Stand) war.
    \printbibliography{}
\end{document}