From bw21 at lab.openslx.org Mon Feb 1 19:57:03 2010 From: bw21 at lab.openslx.org (bw21 at lab.openslx.org) Date: Mon, 1 Feb 2010 19:57:03 +0100 Subject: [OpenSLX-commit] r3227 - contrib/OekPoolFX/trunk/doc/report Message-ID: <20100201185703.AA206323F2F7@openslx-web.vm.uni-freiburg.de> Author: bw21 Date: 2010-02-01 19:57:03 +0100 (Mon, 01 Feb 2010) New Revision: 3227 Modified: contrib/OekPoolFX/trunk/doc/report/lsfks_team.tex Log: latest changes Modified: contrib/OekPoolFX/trunk/doc/report/lsfks_team.tex =================================================================== --- contrib/OekPoolFX/trunk/doc/report/lsfks_team.tex 2010-02-01 18:38:46 UTC (rev 3226) +++ contrib/OekPoolFX/trunk/doc/report/lsfks_team.tex 2010-02-01 18:57:03 UTC (rev 3227) @@ -241,7 +241,7 @@ \begin{figure} \centering - \includegraphics[width=0.8\textwidth,bb=0 0 1024 490]{Images/Interfaces.png} + \includegraphics[width=\textwidth,bb=0 0 1451 694]{Images/Interfaces.png} % Interfaces.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 1056 537 \caption{Die OekPool-Anwendung eingebettet in eine typische Netzwerkumgebung: Es wird davon ausgegangen, dass ein LDAP-Verzeichnis existiert, welches Client-, PXE- und DHCP-Informationen in der beschriebenen Form bereitstellt. Auch ein entsprechend geartetes PXE-Generate-Skript sowie eine funktionierende DHCP/TFTP-Umgebung wird vorausgesetzt.} \label{fig:interface} @@ -336,7 +336,7 @@ \begin{figure}[htb] \centering - \includegraphics[width=0.9\textwidth,bb=0 0 598 261]{./Images/objects.png} + \includegraphics[width=\textwidth,bb=0 0 598 261]{./Images/objects.png} % objects.png: 1266x552 pixel, 152dpi, 21.10x9.20 cm, bb=0 0 598 261 \caption{Im neuen Modell werden die Eigenschaften eines Clients im Clientobjekt gespeichert. Die Methoden des Objektes k?nnen direkt darauf arbeiten. Au?erdem werden die Zust?nde implizit durch die \textit{State Machine} repr?sentiert.} \label{fig:model_new} @@ -631,7 +631,7 @@ Zur Speicherung der Daten wurde eine AJAX-Funktionalit?t implementiert, die wiederum ein PHP-Skript aufruft, das die Daten in die vorhandene LDAP-Datenbank schreibt. -In der Abbildung \ref{webif_screen1} ist der Wochenkalender mit ein paar eingetragenen Zeitfenstern abgebildet und in Abbildung \ref{webif_screen2} sieht man den Dialog, mit dem man Einzelheiten eines Zeitfensters bearbeiten kann, wie zum Beispiel das Aktivieren des automatischen Aufweckens. +In der Abbildung \ref{webif_screen1} ist der Wochenkalender mit einigen eingetragenen Zeitfenstern abgebildet und in Abbildung \ref{webif_screen2} sieht man den Dialog, mit dem man Einzelheiten eines Zeitfensters bearbeiten kann, wie zum Beispiel das Aktivieren des automatischen Aufweckens. Hierbei ist zu Bemerken, dass die vorgegebenen Zeitfenster rechts je von einer niedrigeren Hierarchieebene ?berschrieben werden k?nnen. Somit kann zum Beispiel ?ber das Webinterface f?r die gesamte Organisation eine Standard-Men?auswahl vorgegeben werden, die jeweils die daf?r zust?ndigen Administrators verwenden k?nnen. Andererseits k?nnen die lokalen Administratoren auch f?r einzelne R?ume andere Men?s generieren und bei Bedarf zur Verf?gung stellen. From jb at lab.openslx.org Mon Feb 1 19:38:47 2010 From: jb at lab.openslx.org (jb at lab.openslx.org) Date: Mon, 1 Feb 2010 19:38:47 +0100 Subject: [OpenSLX-commit] r3226 - contrib/OekPoolFX/trunk/doc/report Message-ID: <20100201183847.10E96323F2F6@openslx-web.vm.uni-freiburg.de> Author: jb Date: 2010-02-01 19:38:46 +0100 (Mon, 01 Feb 2010) New Revision: 3226 Modified: contrib/OekPoolFX/trunk/doc/report/lsfks_team.tex Log: * Chapters "Diskussion" and "Ausblick" finished. Modified: contrib/OekPoolFX/trunk/doc/report/lsfks_team.tex =================================================================== --- contrib/OekPoolFX/trunk/doc/report/lsfks_team.tex 2010-01-31 16:20:26 UTC (rev 3225) +++ contrib/OekPoolFX/trunk/doc/report/lsfks_team.tex 2010-02-01 18:38:46 UTC (rev 3226) @@ -90,7 +90,7 @@ \begin{abstract} Eine gro?e Anzahl von Rechnern kann einen hohen Energieverbrauch sowie einen hohen Administrationsaufwand mit sich f?hren. F?r verteilte Systeme -gibt es bereits Terminal-Emulatoren, Wake-On-Lan-Programme +gibt es bereits Terminal-Emulatoren, Wake-On-LAN-Programme und OpenSSH-Server f?r die Rechnersteuerung. Diese getrennten Programme haben einen immer wiederkehrenden hohen Arbeitsaufwand. @@ -117,9 +117,9 @@ Allerdings wird in diesem Dokument die weiterentwickelte Anwendung eher als Teil eines Ganzen betrachtet. So werden z.B. Anforderungen an Netzwerkdienste gestellt, die in der vorangegangen Arbeit nur am Rande erw?hnt wurden. -Auch die meisten Verbesserungen der Anwedungen zielten auf einen einfache Integration in eine bestehende Infrastruktur. +Auch die meisten Verbesserungen der Anwendungen zielten auf einen einfache Integration in eine bestehende Infrastruktur. -Auf eine detailierte Beschreibung s?mtlicher Komponenten und interner Funktionalit?ten wird in dieser Ausarbeitung weitestgehend verzichtet. +Auf eine detaillierte Beschreibung s?mtlicher Komponenten und interner Funktionalit?ten wird in dieser Ausarbeitung weitestgehend verzichtet. \section{Gliederung} In \textbf{Kapitel \ref{chap:anf}} werden die Anforderungen an die Betriebsumgebung diskutiert. @@ -135,7 +135,7 @@ Die St?rken und Schw?chen der Anwendung werden in \textbf{Kapitel \ref{chap:dis}} diskutiert. Dabei wird auch er?rtert, welche Designziele sich mit der Anwendung umsetzen lie?en bzw. welche Probleme auftreten k?nnen. -\textbf{Kapitel \ref{chap:aus}} wird einen Ausblick in die Zukunft der Anwendung geben. Es wird vor allem diskutiert in welchem Umfeld sich die Anwendung einsetzten l?sst und um welche Module man die Anwedung erweitern kann um zus?tzliche Funktionalit?t hinzuzuf?gen. +\textbf{Kapitel \ref{chap:aus}} wird einen Ausblick in die Zukunft der Anwendung geben. Es wird vor allem diskutiert in welchem Umfeld sich die Anwendung einsetzten l?sst und um welche Module man die Anwendung erweitern kann um zus?tzliche Funktionalit?t hinzuzuf?gen. %=============================================================================== \chapter{Anforderung an die Betriebsumgebung} @@ -154,7 +154,7 @@ Im LDAP-Verzeichnis m?ssen drei Arten von Informationen enthalten sein. F?r Verwaltungs- und Identifikationszwecke ben?tigt die Anwendung clientbezogene Eigenschaften. Um eine Zeitsteuerung zu erm?glichen werden f?r jeden Client Informationen bzgl. assoziierter PXE-Konfigurationen verwendet. -Damit die Wake-on-LAN auch in anderen IP-Netzen m?glich ist, sind Informationen ?ber die vom DHCP-Server verwalteten Netzwerke eforderlich. +Damit die Wake-on-LAN auch in anderen IP-Netzen m?glich ist, sind Informationen ?ber die vom DHCP-Server verwalteten Netzwerke erforderlich. \subsubsection{Clientbezogene Eigenschaften} \label{chap:anf:ldap:cln} @@ -163,14 +163,14 @@ Nun wird dieser Baum mittels einer Breitensuche nach Clients durchforstet. Hierbei wird das Objekt \textit{computers} durchsucht, welches unterhalb jeder OU vorhanden sein muss. -Der Filter auf die Ergebnissmenge ist gegeben durch: \textit{(HostName=*)} - also alle Objekte mit einem beliebigen Wert als Hostnamen. Verschiedene Attribute werden hieraus gelesen und f?r die Verwendung in \textit{OekpoolFX} verwendet:: +Der Filter auf die Ergebnismenge ist gegeben durch: \textit{(HostName=*)} - also alle Objekte mit einem beliebigen Wert als Hostnamen. Verschiedene Attribute werden hieraus gelesen und f?r die Verwendung in \textit{OekpoolFX} verwendet:: \begin{description} \item[HostName] Dieses Attribut wird als String ausgelesen und als Filter eingesetzt. -\item[IPAddress] Bei diesem Filter wird das Format \textit{255.255.255.255\_255.255.255.255} f?r ein Adressbereich vorrausgesetzt, wobei \textit{255.255.255.255} eine beliebige IP-Adresse darstellt. Da es noch keine sinnvolle Verwendung f?r den Adressbereich gibt, wird hier einfach der erste Teil als IP-Adresse gespeichert. +\item[IPAddress] Bei diesem Filter wird das Format \textit{255.255.255.255\_255.255.255.255} f?r ein Adressbereich vorausgesetzt, wobei \textit{255.255.255.255} eine beliebige IP-Adresse darstellt. Da es noch keine sinnvolle Verwendung f?r den Adressbereich gibt, wird hier einfach der erste Teil als IP-Adresse gespeichert. \item[Pool] Wir je nach Pool zu jedem Klienten gespeichert. Taucht in der Basis der obigen Abfrage auf (als \textit{ou}). \item[PXEConfig] Ist dieses Attribut gesetzt, wird die Zeitsteuerung ausgeschaltet. Der Wert dieses Attributs ist ein String, der dem Namen des zu ladenden PXE-Men?s entsprechen muss. \item[ForceBoot] Dieses Attribut arbeitet zusammen mit \textit{PXEConfig} und zeigt an, dass der Rechner bei der ?berlagerung der Zeitsteuerung automatisch hochfahren soll. -\item[HlpRBService] Zeigt an, welcher \textit{Remote Boot Serveic} (RBS) gerade mit dem Client assoziiert ist. Men?s, die nicht in diesem RBS definiert sind, werden nicht ?bernommen. +\item[HlpRBService] Zeigt an, welcher \textit{Remote Boot Service} (RBS) gerade mit dem Client assoziiert ist. Men?s, die nicht in diesem RBS definiert sind, werden nicht ?bernommen. \end{description} \subsubsection{Zeit- und PXE-Konfiguration} @@ -186,20 +186,20 @@ \item[PXEConfigDN] Verweist auf das eigentliche Men?, f?r das die Zeit-Konfiguration definiert ist. Ist das Men? nicht im RBS enthalten, mit dem der Client assoziiert ist, wird diese Konfiguration ignoriert. \end{description} -Hierbei gibt es bei der Generierung dieser Liste prizipiell zwei unterschiedliche M?glichkeiten. +Hierbei gibt es bei der Generierung dieser Liste prinzipiell zwei unterschiedliche M?glichkeiten. Zum einen ist es m?glich, dass s?mtliche PXE-Konfigurationen, die in den h?heren Ebenen definiert wurden verworfen werden, sobald in einer unteren Ebene eine Konfiguration definiert ist. Dadurch m?sste man allerdings bei einer kleinen ?nderung gegen?ber einer h?heren Ebene die gesamte Konfiguration neu anlegen. Andererseits kann man die Konfigurationen der einzelnen Ebenen auch zusammenfassen, wobei man bei einer zeitlichen ?berlagerung die Konfiguration aus der niedrigeren Ebene ?bernimmt. Hierbei ist es aber nicht trivial eine bestimmte Konfiguration aus einer h?heren Ebene zu entfernen, ohne sie mit anderweitig zu ?berlagern. \subsubsection{DHCP-Informationen} \label{chap:anf:ldap:dhcp} -Die DHCP-Informationen werden verwendet um zum Beispiel das \textit{Wake-On-Lan}-Paket zu versenden. Dabei werden verschiedene Netzwerk-Informationen ben?tigt. Das Verzeichnis wird hierbei ebenfalls rekursiv durchsucht, wobei unterhalb jeder \textit{OU} das DHCP-Objekt (\textit{cn=dhcp}) durchsucht wird. +Die DHCP-Informationen werden verwendet um zum Beispiel das \textit{Wake-On-LAN}-Paket zu versenden. Dabei werden verschiedene Netzwerk-Informationen ben?tigt. Das Verzeichnis wird hierbei ebenfalls rekursiv durchsucht, wobei unterhalb jeder \textit{OU} das DHCP-Objekt (\textit{cn=dhcp}) durchsucht wird. Als Filter kommt \textit{(dhcpoptNetmask=*)} zum Einsatz. Dabei wird von \textit{dhcpoptNetmask} erwartet, einen beliebigen Wert eingetragen zu haben. Hier werden wieder verschiedene Attribute gelesen und gespeichert: \begin{description} \item[dhcpoptNetmask] Die Netzmaske des Netzwerks ist hier als String gespeichert. -\item[dhcpoptBroadcast-address] Wird als Zieladresse des \textit{Wake-On-Lan}-Pakets verwendet. +\item[dhcpoptBroadcast-address] Wird als Zieladresse des \textit{Wake-On-LAN}-Pakets verwendet. \item[cn] Der \textit{Common Name} wird verwendet, um den Netzwerk-Teil der IP-Adressen zu bekommen und vergleichen zu k?nnen. \end{description} @@ -248,7 +248,7 @@ \end{figure} \section{Clients} -%\textit{Hier kommt der SSH-Teil der Interface-Definition rein. Hier sollten auch allgemeine Angaben ?ber den Client gemacht werden, wie z.B. Betriebsystem, ben?tigte Hardware, Softwarekonfiguration, etc.} +%\textit{Hier kommt der SSH-Teil der Interface-Definition rein. Hier sollten auch allgemeine Angaben ?ber den Client gemacht werden, wie z.B. Betriebssystem, ben?tigte Hardware, Softwarekonfiguration, etc.} Ein Client stellt einen realen Computer im Netzwerk dar. Ein Standard-PC mit Netzwerkkarte, optimalerweise PXE-f?hig, ist v?llig ausreichend. @@ -258,11 +258,11 @@ Bei einzelnen PCs k?nnen somit Treiber beziehungsweise spezielle Konfigurationsdateien eingebunden werden. Wir gehen hier davon aus, das ein Linux-System mit SSH-Server l?uft beziehungsweise ?ber -\textit{Wake-on-lan} gestartet werden kann. Bei der \textit{Wake-On-Lan}-Funktion sollte das System +\textit{Wake-on-LAN} gestartet werden kann. Bei der \textit{Wake-On-LAN}-Funktion sollte das System geeignet automatisch starten. \subsection{SSH} -SSH ist ein Protokoll namens \textit{Secure SHell} mit verschiedenen +SSH ist ein Protokoll namens \textit{Secure Shell} mit verschiedenen kryptografischen Eigenschaften zum Schutz von Integrit?t und Vertraulichkeit. Es erlaubt es durch asymmetrische Verschl?sselung Befehle und Daten abzusenden und zu empfangen. Hier wird es beispielsweise verwendet, um eine Befehlsliste auf der Server-Anwendung abzuarbeiten @@ -294,7 +294,7 @@ Dabei wurden komplizierte if-B?ume gebaut, um die verschiedenen Status-?nderungsbedingungen zu erfassen. Diese wurden schnell sehr gro? und un?bersichtlich in Anbetracht der Attribute, die f?r einen -Client regelm?ssig aktualisiert werden m?ssen. +Client regelm??ig aktualisiert werden m?ssen. Ein besseres Modell f?r diese Aufgabe bietet eine Statemachine\footnote{\textit{engl.}: Zustandsmaschine}, bei der man f?r jeden Client sofort sehen kann, in welchem Zustand er sich befindet. @@ -326,7 +326,7 @@ \label{fig:model_old} \end{figure} -Da jedes Modul Zugriff auf unterschiedliche Client-Eigeschaften haben musste, wurden diese ebenfalls in der globale Liste gespeichert, was diese sehr gro? machte. +Da jedes Modul Zugriff auf unterschiedliche Client-Eigenschaften haben musste, wurden diese ebenfalls in der globale Liste gespeichert, was diese sehr gro? machte. Mit steigender Anzahl von Threads und einer gr??eren Menge von Clients dauerte es immer l?nger alle Zust?nde komplett abzufragen, was dann letztendlich dazu gef?hrt hat die Software-Architektur anzupassen (vgl. Abschnitt \ref{chap:verb:anw}). Da im neuen Software-Modell jeder Client als eigenst?ndige \textit{State Machine} arbeitet, m?ssen die Zust?nde nicht mehr gespeichert werden. @@ -346,7 +346,7 @@ \section{Neues Zustandsdiagramm} Das Zustandsdiagramm wurde in der neuen Anwendung um zwei Zust?nde erweitert. Es wird nun unterschieden, ob ein Client automatisch Hochgefahren werden und die ganze Zeit laufen soll oder nur bei Bedarf manuell eingeschaltet wird. -F?r jede option gibt somit jeweils einen Ping- und SSH-Zustand. +F?r jede Option gibt somit jeweils einen Ping- und SSH-Zustand. Au?erdem wurde der Warn-Zustand in der aktuellen Anwendung entfernt. Seine Funktionalit?t wird nun in den SSH-Zust?nden abgewickelt. @@ -355,13 +355,13 @@ \centering \includegraphics[width=0.9\textwidth,bb=0 0 1064 549]{./Images/fsm_client_new.png} % fsm_client_new.png: 1502x774 pixel, 102dpi, 37.55x19.35 cm, bb=0 0 1064 549 - \caption{Die Zust?nde und ihre ?berg?nge, sowie sie in der Implementierung verwendet werden. Im Vergleich zur urspr?nglichen Anwendung werden die Ping- und SSH-Zust?nde unterschieden, jenachdem ob der Client zwingend laufen muss oder nur bei Bedarf eingeschaltet wird. Der Warn-Zustand wurde entfernt. \textit{ssh} und \textit{ping} bedeuten SSH- bzw. Ping-?berpr?fung. Ein Pluszeichen (+) bedeutet \textit{erfolgreich}, ein Minuszeichen bedeutet \textit{nicht erfolgreich}, zwei Minuszeichen bedeuten \textit{maximale Versuchsanzahl ?berschritten}.} + \caption{Die Zust?nde und ihre ?berg?nge, sowie sie in der Implementierung verwendet werden. Im Vergleich zur urspr?nglichen Anwendung werden die Ping- und SSH-Zust?nde unterschieden, je nachdem ob der Client zwingend laufen muss oder nur bei Bedarf eingeschaltet wird. Der Warn-Zustand wurde entfernt. \textit{ssh} und \textit{ping} bedeuten SSH- bzw. Ping-?berpr?fung. Ein Pluszeichen (+) bedeutet \textit{erfolgreich}, ein Minuszeichen bedeutet \textit{nicht erfolgreich}, zwei Minuszeichen bedeuten \textit{maximale Versuchsanzahl ?berschritten}.} \label{fig:fsm} \end{figure} Somit ergeben sich folgende Zust?nde (vgl Abb. \ref{fig:fsm}): \begin{description} - \item[Offline] Dem Client ist momentan kein PXE-Menu zugeordnet. Er wird nicht durch die Anwendung verwaltet. + \item[Offline] Dem Client ist momentan kein PXE-Men? zugeordnet. Er wird nicht durch die Anwendung verwaltet. \item[PXE Changed] Das aktuell g?ltige PXE-Men? f?r den Client wurde ge?ndert. Er kann nun (automatisch oder manuell) gestartet werden. \item[Wake Up] Ein \textit{Wake on LAN}-Signal wurde an den Rechner ?bermittelt. \item[Ping ``offline''] Der Rechner wurde manuell gestartet und hat auf ein Ping-Signal reagiert. @@ -377,7 +377,7 @@ \section{Programmiersprache} %\textit{Von schwacher/dynamischer Typisierung (Ruby) zu starker/statischer Typisierung, Notwendigkeit f?r den Umstieg} Die verbesserte Anwendung wurde im Gegensatz zum urspr?nglichen Prototypen (der in \textit{Ruby} programmiert war) vollst?ndig in \textit{C++} entwickelt. -Zu diesem Schritt hatten wir uns entwickelt, als wir w?rend der Entwicklung des Programms auf einige Probleme gesto?en sind. +Zu diesem Schritt hatten wir uns entwickelt, als wir w?hrend der Entwicklung des Programms auf einige Probleme gesto?en sind. Eines der Hauptprobleme waren das unzureichende Datenmodell und die Architektur, welche schon in den Abschnitten \ref{chap:verb:anw} und \ref{chap:verb:data} erw?hnt wurden. @@ -408,7 +408,7 @@ Zun?chst wird das Programm initialisiert mit allen daf?r notwendigen Parametern. Die Konfiguration wird geladen, die Verbindung zum LDAP wird aufgebaut und die verf?gbaren Netzwerk gelesen. Dabei wird zum Beispiel auch das Loglevel gesetzt, was in der Beschreibung der Konfiguration nachzulesen ist. -Desweiteren initialisiert sich der SSH Thread und wartet eine Zeitlang (Konfiguration: \textit{ssh\_init\_time}) bis er alle verf?gbaren Clients durchgeht. +Des weiteren initialisiert sich der SSH Thread und wartet eine Zeit lang (Konfiguration: \textit{ssh\_init\_time}) bis er alle verf?gbaren Clients durchgeht. In der Hauptschleife werden nach jeder halben Minute die Clients aktualisiert beziehungsweise neu geladen, sofern sie vorher nicht schon geladen worden sind. Dies geschieht durch Setzen eines Mutex, der die Daten der Clients sch?tzt. Damit wird das Lesen der Daten solange verhindert, bis die neuen Daten noch nicht geschrieben worden sind. @@ -448,13 +448,13 @@ Danach wird nach weiteren Untereinheiten (\textit{Organizational Units (OU)}) im Teilbau gesucht. F?r jede gefundene \textit{OU} wird die Methode erneut aufgerufen. Neben der \textit{OU} und der Client-Liste werden der Methode die gefundenen PXE-Konfigurationen ?bergeben. -Diese werden auf die gefundenen Clients in der unteren Ebene angwendet, sofern dort keine PXE-Konfigurationen hinterlegt sind. +Diese werden auf die gefundenen Clients in der unteren Ebene angewendet, sofern dort keine PXE-Konfigurationen hinterlegt sind. Dadurch wird die Vererbung der Einstellungen in die unteren Ebenen realisiert (siehe Abb. \ref{fig:ldap_pxe}). \begin{figure} \centering \includegraphics[width=0.8\textwidth,bb=0 0 935 480]{Images/ldap_pxe.png} - \caption{Im \textit{PXE}-Objekt unterhalb des Wurzelknotens ist das Men? \textit{default} definiert. Dadurch erhalten standardm??ig alle Clients dieses Men?. Unterhalb des Chemieknotens sind keine PXE-Men?s definiert. Daher wird das \textit{default}-Men? auf diese Ebene vererbt. Unterhalb des Rechners \textit{chServ} befindet sich das Men? \textit{SuSE\_Enterprise}, welches das Standard-Men? ?berschreibt. Unterhalb des Rechenzentrumknotens befindet sich das Men? \textit{Ubuntu-9.04}. Alle Rechner auf dieser Ebene und unterhalb starten dadurch dieses Men?.} + \caption{Im \textit{PXE}-Objekt unterhalb des Wurzelknotens ist das Men? \textit{default} definiert. Dadurch erhalten standardm??ig alle Clients dieses Men?. Unterhalb des Chemieknotens sind keine PXE-Men?s definiert. Daher wird das \textit{default}-Men? auf diese Ebene vererbt. Unterhalb des Rechners \textit{chServ} befindet sich das Men? \textit{SuSE\_Enterprise}, welches das Standard-Men? ?berschreibt. Unterhalb des Rechenzentrumsknoten befindet sich das Men? \textit{Ubuntu-9.04}. Alle Rechner auf dieser Ebene und unterhalb starten dadurch dieses Men?.} \label{fig:ldap_pxe} \end{figure} @@ -465,14 +465,14 @@ \begin{figure} \centering \includegraphics[width=0.8\textwidth,bb=0 0 931 422]{Images/ldap_dhcp.png} - \caption{Im \textit{DHCP}-Objekt unterhalb des Wurzelknotens ist kein Netzwerk definiert. Im Chemieknoten wurden zwei Netzwerke und im Rechenzentrumknoten ein Netzwerk gespeichert.} + \caption{Im \textit{DHCP}-Objekt unterhalb des Wurzelknotens ist kein Netzwerk definiert. Im Chemieknoten wurden zwei Netzwerke und im Rechenzentrumsknoten ein Netzwerk gespeichert.} \label{fig:ldap_dhcp} \end{figure} \section{SSH-Modul} %\textit{Beschreibung der SSH-Klasse: z.B. welcher Datenfluss (in/out), Beschreibung Hauptschleifen, wichtige Funktionen, evtl. kurze Diskussion} -Das SSH-Modul ist ein wichtiger Bestandteil der Anwendung. Hier werden die Befehle abgesetzt sowie die Clients auf den lauff?higen Zustand ?berpr?ft. Da die Authorisierung und die Befehlsausgabe relativ lange dauern, sahen wir die einzige M?glichkeit darin, diesen Bestandteil in einen eigenen Thread auszulagern. Da dieser unter Umst?nden mehrere hundert Rechner zu versorgen hat, konnte dieser nicht Bestandteil der Hauptschleife sein. +Das SSH-Modul ist ein wichtiger Bestandteil der Anwendung. Hier werden die Befehle abgesetzt sowie die Clients auf den lauff?higen Zustand ?berpr?ft. Da die Autorisierung und die Befehlsausgabe relativ lange dauern, sahen wir die einzige M?glichkeit darin, diesen Bestandteil in einen eigenen Thread auszulagern. Da dieser unter Umst?nden mehrere hundert Rechner zu versorgen hat, konnte dieser nicht Bestandteil der Hauptschleife sein. Der SSH Thread arbeitet mit der Bibliothek \textit{libssh2}, eine C-Bibliothek, die in diesem Bereich zu den best-entwickelten Bibliotheken geh?rt. Verschiedene andere SSH Bibliotheken, die wir evaluierten, hatten entweder nicht diesen Funktionsumfang oder waren zu umst?ndlich anzusprechen. Nachdem dieser Thread zuerst die Liste der Clients abarbeitet um sich zu verbinden, werden jeweils alle zugeordneten Befehle abgearbeitet. Das wird wiederholt bis sie alle erfolgreich verarbeitet werden konnten. Weiterhin wird ein automatischer \texttt{echo ''ping``}-Befehl alle 5 Sekunden abgesetzt um die Reaktion des Clients zu pr?fen. Die Arbeitsweise der Klasse kann in Abbildung \ref{sshthread_msc} einfach veranschaulicht werden. Die Wahl auf diese Architektur wird durch die folgende Argumentation gerechtfertigt. @@ -483,11 +483,11 @@ \caption{Die Arbeitsweise des SSHThreads-Moduls. Das Modul ist als eine Klasse implementiert und unterst?tzt das \textit{Singleton} Design Pattern. Es kann somit von jeder Stelle aus aufgerufen werden, um Befehle abzusetzen. Intern werden \textit{Mutexe} verwendet, um kritische Datenstrukturen zu sch?tzen.} \end{figure} -Bei der Abarbeitung von Befehlen stellte sich schnell heraus, dass der SSH Thread schnell in einen Halte-Status steckenbleiben konnte, wenn zum Beispiel ein Benutzer das Netzwerkkabel zog oder der Rechner von dem Benutzer \textit{kalt} gestartet wurde. Dabei bleibt die Verbindung bestehen und die SSH-Bibliothek wartet auf die Gegenstelle. Dieses verhalten l?sst sich auch leicht im heimischen Netzwerk reproduzieren indem man eine SSH-Verbindung aufh?lt, w?hrend man den entfernten Computer ausschaltet. Dabei h?ngt Eingabeaufforderung und der SSH Klient bleibt in einem \textit{Deadlock}-Zustand h?ngen. Um dieses Verhalten in unserem Programm zu unterbinden, w?hlten wir den Ansatz eines weiteren Threads, der pr?ft, ob die maximale Zeitdauer einer Kommando-Absetzung erreicht wurde. Die Stoppuhr wird jeweils durch den SSH Hauptthread zur?ckgesetzt, so dass der Stoppuhr-Thread immer die richtigen Daten verf?gbar hat. Sollte es zu einer Zeit?berschreitung der Verbindung ko mmen, wird ein \textit{SIGHUP}-Signal an den Verbindungsthread geschickt und die aktive Verbindung gel?scht. In Kombination mit der \textit{pthreads} Threading-Bibliothek konnte man keine anderen Befehle wie \textit{SIGTERM} oder \textit{SIGKILL} verwenden, weil diese einen Speicherzugriffsfehler provozierten. +Bei der Abarbeitung von Befehlen stellte sich schnell heraus, dass der SSH Thread schnell in einen Halte-Status stecken bleiben konnte, wenn zum Beispiel ein Benutzer das Netzwerkkabel zog oder der Rechner von dem Benutzer \textit{kalt} gestartet wurde. Dabei bleibt die Verbindung bestehen und die SSH-Bibliothek wartet auf die Gegenstelle. Dieses verhalten l?sst sich auch leicht im heimischen Netzwerk reproduzieren indem man eine SSH-Verbindung aufh?lt, w?hrend man den entfernten Computer ausschaltet. Dabei h?ngt Eingabeaufforderung und der SSH Klient bleibt in einem \textit{Deadlock}-Zustand h?ngen. Um dieses Verhalten in unserem Programm zu unterbinden, w?hlten wir den Ansatz eines weiteren Threads, der pr?ft, ob die maximale Zeitdauer einer Kommando-Absetzung erreicht wurde. Die Stoppuhr wird jeweils durch den SSH Hauptthread zur?ckgesetzt, so dass der Stoppuhr-Thread immer die richtigen Daten verf?gbar hat. Sollte es zu einer Zeit?berschreitung der Verbindung k ommen, wird ein \textit{SIGHUP}-Signal an den Verbindungsthread geschickt und die aktive Verbindung gel?scht. In Kombination mit der \textit{pthreads} Threading-Bibliothek konnte man keine anderen Befehle wie \textit{SIGTERM} oder \textit{SIGKILL} verwenden, weil diese einen Speicherzugriffsfehler provozierten. Speziell sinnvoll bei SIGHUP erschien uns die Tatsache, dass es historisch als Verbindungstrennung-Signal verwendet wurde, speziell in Terminals, die mit einem Modem zum Mainframe verbunden waren. -Besonderer Augenmerk wurde in dieser Implementierung auf die Generierung von Mutexen f?r viele Eigenschaften und Methoden dieser Klasse gelegt. So konnte ein Reibungsloser Ablauf von verschiedenen parallel laufenden threads gesichert werden. -Vor allem bei Prozessoren mit mehreren ausf?hrenden Threads bringt dies zus?tztlich einen Geschwindigkeitsvorteil mit sich. +Besonderer Augenmerk wurde in dieser Implementierung auf die Generierung von Mutexen f?r viele Eigenschaften und Methoden dieser Klasse gelegt. So konnte ein Reibungsloser Ablauf von verschiedenen parallel laufenden Threads gesichert werden. +Vor allem bei Prozessoren mit mehreren ausf?hrenden Threads bringt dies zus?tzlich einen Geschwindigkeitsvorteil mit sich. \section{Netzwerk-Modul} \label{chap:imp:nw} @@ -537,10 +537,10 @@ \item[] \verb+wake client { ip | mac | hostname [, ... ] }+ \\ \verb+wake pool poolname+\\ -Sendet ein \textit{Wake on LAN}-Siganl an die angegebenen Rechner oder an alle Rechner im Pool \textit{poolname}. +Sendet ein \textit{Wake on LAN}-Signal an die angegebenen Rechner oder an alle Rechner im Pool \textit{poolname}. \item[] \verb+takeover { ip | mac | hostname [, ... ] }+ \\ -Reserviert die angegebene Liste von Clients exklisive f?r den Socket, ?ber den das \textit{CLI} aufgerufen wird. +Reserviert die angegebene Liste von Clients exklusiv f?r den Socket, ?ber den das \textit{CLI} aufgerufen wird. Dieser Schritt ist n?tig um die Clients von der Zeitsteuerung auszugliedern, wenn sie manuell gestartet werden sollen. Ist die Option \textit{safe\_mode} in der Konfigurationsdatei aktiviert, muss sich ein Client im \textit{Offline}- oder \textit{PXE}-Status befinden, damit er reserviert werden kann. @@ -574,7 +574,7 @@ \item[ldap\_password] Das LDAP Passwort f?r den Benutzer \textit{ldap\_user}. \item[ldap\_base\_dn] Die Wurzel des LDAP-Baums unter der die Daten gesucht werden und die Benutzer eingerichtet sind. z.B. \textit{dc=uni-freiburg,dc=de} an der hiesigen Universit?t. \item[ldap\_pxe\_container] In welchem Container befinden sich die \textit{ActivePXEConfig}-Objekte f?r gr??ere Geltungsbereiche als die lokalen Definitionen. z.B. \textit{cn=pxe}, wenn im Rechnerpool-Knoten jeweils ein \textit{cn=pxe}-Knoten existiert. -\item[ssh\_auth\_method] Welche Authentifizierungsmethode wird von dem SSH Thread verwendet? Daf?r sind 2 Methoden implementiert: \textit{publickey} f?r die Pre-Shared-Key-Variante mit privatem Schl?ssel auf jedem Client und \textit{password} f?r eine nicht-interaktive Passwort-Authentifizierung. Diese Option bedingt oder schliesst jeweils die folgenden Optionen aus. +\item[ssh\_auth\_method] Welche Authentifizierungsmethode wird von dem SSH Thread verwendet? Daf?r sind 2 Methoden implementiert: \textit{publickey} f?r die Pre-Shared-Key-Variante mit privatem Schl?ssel auf jedem Client und \textit{password} f?r eine nicht-interaktive Passwort-Authentifizierung. Diese Option bedingt oder schlie?t jeweils die folgenden Optionen aus. \item[ssh\_private\_key] Nur g?ltig mit \textit{publickey} bei \textit{ssh\_auth\_method}! \\ Der Pfad zum geheimen Schl?ssel (private key), z.B.: \textit{/home/user/.ssh/id\_rsa} \item[ssh\_public\_key] Nur g?ltig mit \textit{publickey} bei \textit{ssh\_auth\_method}! \\ @@ -584,20 +584,20 @@ \item[ssh\_password] Nur g?ltig mit \textit{password} bei \textit{ssh\_auth\_method}! \\ Das Passwort zur Authentifizierung. -\item[tftp\_active] TFTP Unterst?tzung wird eingeschaltet (noch nicht vollst?ndig implemetiert). M?gliche Werte: \textit{true} oder \textit{false} +\item[tftp\_active] TFTP Unterst?tzung wird eingeschaltet (noch nicht vollst?ndig implementiert). M?gliche Werte: \textit{true} oder \textit{false} \item[tftp\_root\_dir] Welcher Pfad soll als TFTP-Pfad verwendet werden? z.B.: \textit{/var/lib/tftpboot/} \item[log\_level] Hier kann man das generelle Loglevel einstellen. M?gliche Werte sind hier: \textit{fatal}, \textit{error}, \textit{warning}, \textit{info} (von sehr schweigsam bis gespr?chig) \item[ssh\_init\_time] Wartezeit, wie lange der SSH-Thread warten soll, bis er zum ersten aktiven Client verbinden darf, z.B.: 60. \item[wakeup\_time] Wartezeit nach dem \textit{Wakeup}-Versuch. (wird noch nicht verwendet), z.B.: 60. -\item[ping\_timeout]Wartezeit nach einem Pinversuch (wird nicht noch verwendet), z.B.: 5 -\item[shutdown\_time] Shutdownzeit, nach wieviel Sekunden nach Ablauf des PXE-Zeitintervall der Rechner heruntergefahren wird, z.B.: 60 +\item[ping\_timeout]Wartezeit nach einem Pingversuch (wird nicht noch verwendet), z.B.: 5 +\item[shutdown\_time] Shutdownzeit, nach wie viel Sekunden nach Ablauf des PXE-Zeitintervall der Rechner heruntergefahren wird, z.B.: 60 \item[warn\_time] Warnzeit, die einem Benutzer noch bleibt, bis der Rechner ausgeschaltet wird, z.B.: 600 -\item[warn\_interval] Intervallzeit, nach wieviel Sekunden der Benutzer wiederholt gewarnt werden soll, wenn der Rechner heruntergefahren werden soll, z.B.: 5 -\item[ping\_interval] Intervallzeit, nach wieviel Sekunden der Rechner nochmals ange\textit{ping}t wird, z.B.: 30 -\item[ssh\_interval] Intervallzeit, nach wieviel Sekunden ein \textit{SSH-Ping} gesendet werden soll, z.B.: 30 +\item[warn\_interval] Intervallzeit, nach wie viel Sekunden der Benutzer wiederholt gewarnt werden soll, wenn der Rechner heruntergefahren werden soll, z.B.: 5 +\item[ping\_interval] Intervallzeit, nach wievielt Sekunden der Rechner nochmals ange\textit{ping}t wird, z.B.: 30 +\item[ssh\_interval] Intervallzeit, nach wie viel Sekunden ein \textit{SSH-Ping} gesendet werden soll, z.B.: 30 -\item[takeover\_safe\_mode] Legt fest, ob die Reservierung eines Clients ?ber das \textit{CLI} nur geschehen darf, wenn er ausgeschaltet ist. Kann \textit{false} oder \textit{true} annhemen. +\item[takeover\_safe\_mode] Legt fest, ob die Reservierung eines Clients ?ber das \textit{CLI} nur geschehen darf, wenn er ausgeschaltet ist. Kann \textit{false} oder \textit{true} annehmen. \item[cli\_accept\_ip] Komma-getrennte Liste von IP-Adressen, die angeben, welche Rechner sich mit dem Steuerungs-Interface verbinden k?nnen. \item[cli\_port] Port f?r das Telnet-Steuerungsinterface, z.B.: 4440 \end{description} @@ -605,7 +605,7 @@ \section{Das Web-Interface} Um die Zeitsteuerung der Clients zu automatisieren, bietet sich an, f?r eine Gruppe von Clients oder sogar f?r einzelne Computer Zeitinformationen zu speichern. -Dabei wird unter anderem die Start- und Endzeit sowie ein boolescher Wert gespeichert, der bestimmt, ob der Client ?ber Wake-On-Lan aufgeweckt werden soll oder ob das Programm passiv warten soll, bis dieser manuell eingeschaltet wird. +Dabei wird unter anderem die Start- und Endzeit sowie ein boolescher Wert gespeichert, der bestimmt, ob der Client ?ber Wake-On-LAN aufgeweckt werden soll oder ob das Programm passiv warten soll, bis dieser manuell eingeschaltet wird. \subsection{Geschichte} Das Web-Interface basiert auf einer PHP-Anwendung, die schon 2 Jahre in dem hiesigen Rechenzentrum benutzt worden ist. @@ -621,7 +621,7 @@ \subsection{Die Erweiterung} Wie schon oben erw?hnt, brauchten wir eine leicht zu bedienende Art der Zeitsteuerung f?r die einzelnen Clients, aber auch f?r ganze Gruppen. -Daf?r bot sich an, die bestehende Anwendung zu erweitern. Ein statischer Wochenkalender war f?r die aktiven PXE-Zeiten schon implementiert, jedoch war die zugrundeliegende Struktur f?r uns nicht praktisch und der PHP-Code schlecht zu erweitern. +Daf?r bot sich an, die bestehende Anwendung zu erweitern. Ein statischer Wochenkalender war f?r die aktiven PXE-Zeiten schon implementiert, jedoch war die zugrunde liegende Struktur f?r uns nicht praktisch und der PHP-Code schlecht zu erweitern. Daher beschlossen wir, eine AJAX-Anwendung einzubinden, durch die wir mehr Interaktivit?t und eine gr??ere Benutzerfreundlichkeit erreichen w?rden. Die L?sung durch die JavaScript-Bibliothek \textit{jquery} \footnote{\url{http://jquery.com}} erschien uns am praktischsten, da schon ein Wochenkalender als Plugin %\footnote{weekcalendar url}% bereits vorhanden war. @@ -632,7 +632,7 @@ das die Daten in die vorhandene LDAP-Datenbank schreibt. In der Abbildung \ref{webif_screen1} ist der Wochenkalender mit ein paar eingetragenen Zeitfenstern abgebildet und in Abbildung \ref{webif_screen2} sieht man den Dialog, mit dem man Einzelheiten eines Zeitfensters bearbeiten kann, wie zum Beispiel das Aktivieren des automatischen Aufweckens. -Hierbei ist zu Bemerken, dass die vorgegebenen Zeitfenster rechts je von einer niedrigeren Hierarchieebene ?berschrieben werden k?nnen. Somit kann zum Beispiel ?ber das Webinterface f?r die gesamte Organisation eine Standard-Menuauswahl vorgegeben werden, die jeweils die daf?r zust?ndigen Admins verwenden k?nnen. +Hierbei ist zu Bemerken, dass die vorgegebenen Zeitfenster rechts je von einer niedrigeren Hierarchieebene ?berschrieben werden k?nnen. Somit kann zum Beispiel ?ber das Webinterface f?r die gesamte Organisation eine Standard-Men?auswahl vorgegeben werden, die jeweils die daf?r zust?ndigen Administrators verwenden k?nnen. Andererseits k?nnen die lokalen Administratoren auch f?r einzelne R?ume andere Men?s generieren und bei Bedarf zur Verf?gung stellen. \begin{figure}[ht] @@ -653,23 +653,23 @@ %=============================================================================== \chapter{Diskussion} \label{chap:dis} -%\textit{Diskussion useres Ansatzes hinsichtlich auftretender Probleme und wie sie gel?st werden k?nnen} -Eines der Design-Ziele der Anwedung war eine niedrigere Reaktionszeit auf Status?nderungen gegen?ber der urspr?nglichen Anwendung. -So wurde das aufgabenzentrierte Modell (jede Aktion wurde als eigenst?ndiger Thread modelliert) zu Gunsten eines objektzentrierten Modells (siehe Abschnitt \ref{chap:verb:anw}) aufgegeben. +%\textit{Diskussion unseres Ansatzes hinsichtlich auftretender Probleme und wie sie gel?st werden k?nnen} +Eines der Design-Ziele der Anwendung war eine niedrigere Reaktionszeit auf Status?nderungen gegen?ber der urspr?nglichen Anwendung. +So wurde das aufgaben zentrierte Modell (jede Aktion wurde als eigenst?ndiger Thread modelliert) zu Gunsten eines objektzentrierten Modells (siehe Abschnitt \ref{chap:verb:anw}) aufgegeben. Dadurch konnte die maximale Wartezeit, bis ein Client nach Zustands?nderung aktualisiert wurde, auf 5 Sekunden verringert werden, gegen?ber 30 Sekunden im Prototypen. In den Tests der Anwendung wurde f?r die Aktualisierung von 144 Clients im Schnitt ca. 300 Millisekunden ben?tigt. Geht man davon aus, dass die Verarbeitungszeit proportional zur Anzahl der Clients ist, k?nnen ?ber 2000 Rechner innerhalb der 5 Sekundenintervalle verwaltet werden. -Ein weiteres Ziel war die Auslagerung aller Aktionen in Threads, die die Anwendung unvorhersagbar verz?gern k?nnen. +Ein weiteres Ziel war die Auslagerung aller Aktionen in Threads, die die Anwendung unvorhersehbar verz?gern k?nnen. Dies betrifft s?mtliche Ein/Ausgabe-Operationen, wie Pings und SSH-Verbindungen. -Wenn ein Ping abgesetzt werden soll, wird ein Thread gestartet, welcher unmittelbar nach feststehen des Ergebisses das Client-Objekt informiert (vgl. Abschnitt \ref{chap:imp:nw}). +Wenn ein Ping abgesetzt werden soll, wird ein Thread gestartet, welcher unmittelbar nach feststehen des Ergebnisses das Client-Objekt informiert (vgl. Abschnitt \ref{chap:imp:nw}). Bis zur Verarbeitung des Ping-Ergebnisses vergehen also maximal 5 Sekunden, welchen dem Aktualisierungsinterval entsprechen. Auch SSH-Befehle werden asynchron abgesetzt. Soll ein Befehl ausgef?hrt werden, landet er zuerst in einer Liste, welche st?ndig vom SSH-Thread abgefragt wird. -Da SSH-Verbindungen nach der ersten Verwendung offen geahlten werden bis der Client herunterf?hrt, wird die Zeit zum Absetzen des Befehls minimiert. +Da SSH-Verbindungen nach der ersten Verwendung offen gehalten werden bis der Client herunter f?hrt, wird die Zeit zum Absetzen des Befehls minimiert. Problematisch wird es allerdings, wenn Clients nicht mehr erreichbar sind. Dadurch, dass der Thread 5 Sekunden blockieren kann, bis er zur?ckgesetzt wird, kann die Ausf?hrung weiterer Befehle verz?gert werden. @@ -678,17 +678,30 @@ In unseren Tests f?hrte allenfalls ein gezogenes Netzwerkkabel oder ein \textit{Kernel Break} (ALT+Druck+B) zu diesem Verhalten. Wird ein Rechner unerwartet heruntergefahren, schlie?t der SSH-Server die Verbindung ordnungsgem??. +Viel schwerwiegendere Probleme verursachten unvorhergesehene Nutzerinteraktionen in den kritischen Phasen im Lebenszyklus eines Clients. +So kann es zum Beispiel dazu kommen, dass ein falsches Betriebssystem gebootet wird, wenn der Rechner nach dem automatischen \textit{Shutdown} wieder hochgefahren wird, bevor ein neues PXE-Men? verlinkt ist. +Je nachdem wie viel Zeit man den Clients per Konfigurationsdatei zum herunterfahren l?sst, kann dieses Risiko aber minimiert werden. + +Generell kann man sagen, dass es m?glich ist vorhandene Tools, wie SSH, LDAP und PXE, durch eine entsprechende Anwendung zu vereinen und so eine Zeitsteuerung erh?lt, die eine gr??ere Anzahl von Rechnern verwalten kann. +Allerdings sollte man sich sehr genau Gedanken dar?ber machen, wie sich die Benutzer in einer solchen Umgebung verhalten und ggf. Vorkehrungen treffen, wie zum Beispiel \textit{Kernel Break} deaktivieren. + %=============================================================================== \chapter{Ausblick} \label{chap:aus} %\textit{Beschreibung in welche Richtung zuk?nftige Entwicklungsarbeiten gehen k?nnen: z.B. Agent f?r CLI, Webfrontend, etc.} Eine der m?glichen Entwicklungen die im Bezug auf die vorliegende Anwendung weiterverfolgt werden k?nnte, sind intelligente Agents, die an das \textit{Command Line Interface} andocken k?nnen. -Da die Clients ?ber das \textit{CLI} unabh?ngig von (oder im Kombination mit) der Zeitsteuerung kontrolliert werden k?nnen bzw. man entsprechende Statusinformationen bekommt, kann dies verwendet um weiters Verhalten zu implementieren. -Die zus?tzlichen Features m?sste nicht in die eigentliche Anwendung integriert werden, sondern k?nnten als eigenst?ndige Module entwicklet werden. +Da die Clients ?ber das \textit{CLI} unabh?ngig von (oder im Kombination mit) der Zeitsteuerung kontrolliert werden k?nnen bzw. man entsprechende Statusinformationen bekommt, kann dies verwendet um weiteres Verhalten zu implementieren. +Die zus?tzlichen Features m?sste nicht in die eigentliche Anwendung integriert werden, sondern k?nnten als eigenst?ndige Module entwickelt werden. Die k?nnen dann bei Bedarf aktiviert werden. So kann z.B. ein Agent alles Clients eines Pools ?berwachen (\textit{query pool}) und eine Nutzungsstatistik ?ber definierte Zeitr?ume zu erstellen. Hierbei kann feingranular nach jedem Zustand, der in der Anwendung definiert wurde, unterschieden werden. Ein weiterer Agent k?nnte dann aufgrund dieser Nutzungsstatistik autonom Rechner hochfahren (\textit{wake client}), wenn der ermittelte Bedarf steigt, oder diese ausschalten (\textit{shutdown client} oder \textit{execute client \glqq shutdown -h now``}), sobald der Bedarf sinkt. +Dar?ber hinaus w?re es m?glich die eigentliche Anwendung dahingehend zu erweitern, dass erkannt wird, wenn nicht das gew?nschte System gebootet wird. +So k?nnte man in jeder Betriebssystemversion eine bestimmte eindeutige Umgebungsvariable setzen. +Der Wert dieser Variable wird ebenfalls im LDAP hinterlegt. +Ist nun eine SSH-Verbindung zum Client m?glich, k?nnte diese Variable abgefragt werden. +Stimmt diese nicht mit dem hinterlegten Wert ?berein, wird das System neu gestartet. + \end{document}