Guten Morgen. Ja, es freut mich sehr, dass an einem Sonntagvormittag zu der Uhrzeit doch einige den Weg hierher gefunden haben und ja, willkommen zu meinem Vortrag der lauten Systemverwaltung mit Spacewalk.

Insbesondere geht es hier um Praxistipps zur Verwaltung von Linux und Solaris-Systeme und finde ich interessant, dass es Leute gibt, die sich für den Solaris-Part interessieren. Ich hätte jetzt eher die gegenteilige Aussage erwartet, aber schauen wir mal. Wer bin ich überhaupt? Mein Name ist Christian Stangwitsch. Ich arbeite für das Unternehmen Mass-Information-Services. Wir sind ein firmengruppeninterner ALT-Dienstleister und ich bin dort

angestellt als VMware, Unix und Linux-Administrator. Und meine Interessen sind so Spacewalk, Red Hat Satellite, den ich auch massgebisch betreue, SUSE Manager, bisschen Monitoring und Enterprise Linux insbesondere eben SUSE, Red Hat und VMware v4. Worum geht es heute

überhaupt? Hier mal einen Überblick über die Agenda. Zuerst schauen wir uns erstmal grundlegend das Thema an. Warum brauche ich überhaupt ein zentrales Configuration Management? Wie können wir die Produkte überhaupt helfen? Wo ist da die Notwendigkeit? Was für Versionen oder Varianten gibt es? Was hat sich da getan in der Entwicklung in den letzten Wochen?

Dann schauen wir uns an, wie man so ein System grundlegend erst einmal installiert und administriert. Da gehe ich schon auch auf Solaris ein, wenn das interessant ist. Und letztendlich möchte ich einfach ein paar Tipps und Tricks aus dem Admin-Daily-Business zeigen, wie man sich die Arbeit ein bisschen erleichtern kann. Also ich selbst verwende auch Red Hat Satellite und Spacewalk und habe da ein paar Dinge gebastelt,

die einem die Arbeit erleichtern können, die würde ich gerne vorstellen. Dann beginnen wir mal mit Anforderungen und Notwendigkeit. Normalerweise ist es so und ich denke da werden mir auch viele zustimmen, dass wenige Administratoren viele Systeme betreuen. Und sehr häufig hat man eben viele kurzfristige Projekte und Anfragen

und ich bin sicher, wir alle kennen Sätze wie, wir brauchen kurzfristig mal eben 10 Server. Wir brauchen das bis Ende der Woche, also morgen. Und kannst du das mal eben schon machen, ich habe gleich eine Demo mit der Geschäftsführung. Haben wir alle denke ich mal schon gehört. Das sind so die Qualen eines IT-Administrators und hier kann eben ein Configuration Management

helfen, damit man nicht das Problem hat, dass Standards und Dokumentation vergessen werden, was leider häufig vorkommt. Und das Problem kann man damit hoffentlich lösen. Also, Aussage eins, Zentrales Configuration Management ist unabdingbar. Bloß, was nehme ich denn überhaupt? Also es gibt eine extrem große Auswahl. Es gibt zum Beispiel Puppet, es gibt Chef, es gibt Ansible. Verwendet

irgendeiner von euch eines der Tools? Kurz Handzeichen. Ansible, Chef? Okay, wer verwendet noch Puppet? Chef? Ansible? Ja, das wollte ich noch kurz eben einbauen, aber das hat dann doch im Rahmen der Zeit nicht funktioniert.

Deswegen, aber ich nehme an, du verwendest Salt? Nicht? Okay. Okay, verwendet denn überhaupt jemand vielleicht schon rein zufällig Spacewalk, Susan Manager oder Redhead Satellite? Solala, okay. Ich hoffe, nach dem Vortrag gehen dann mehr Hände hoch. Die ganzen Tools, die ich jetzt hier

exemplarisch mal dargestellt habe, das sind Tools, die eine Teilmenge der Spacewalk-Features abdecken, denn Spacewalk ist mehr als eben nur Configuration und System-Management, also es sind Alternativen. Also Spacewalk, Satellite und Susan Manager sind Alternativen, die unter anderem Software, Configuration und Content-Management liefern.

Also wenn ich alles in einem irgendwie haben will, so als eierlegende Wollmilchsau, dann sollte ich mir vielleicht mal dieses wieder angucken, denn dann kann das interessant sein. Kommen wir zum nächsten Punkt. Was gibt es überhaupt für Variationen? Warum gibt es eigentlich drei verschiedene Produkte? Ganz einfach, 2002 gab es die erste Version des Redhead Network Satellite-Servers.

Das war ein rein kommerzielles Produkt von Redhead. Das wurde 2008 durch der Quellcode als Spacewalk veröffentlicht und seitdem ist Spacewalk quasi das Upstream-Projekt für die kommerziellen Ableger. Das bedeutet, dass eben Susan Manager und Redhead Satellite einen Wachungsvertrag erfordern, denn das sind Lizenzen, die man eben einfach kaufen muss mit dem Support und Spacewalk ist eben kostenlos und ist

im Prinzip so die technische Spielwiese von Redhead. Da werden dann eben Dinge getestet und Susan arbeitet da übrigens auch mit und steuert auch viele Features bei und wenn diese Funktionen eben gut ankommen, wenn sie funktionieren, dann übernimmt man die eben in die Enterprise-Produkte. Und um das Ganze mal grafisch darzustellen, ein Bild sagt mehr als 1000 Worte, habe ich hier mal einen

Screenshot von Spacewalk 2.2. Ich hoffe, man kann das so grob erkennen. Man hat hier irgendwo eine Übersicht, hat hier Systeme, die man sieht. Man bekommt aufgelistet, welche Updates zur Verfügung stehen und das ist also jetzt der freie Ableger. Wenn man denn dann den Redhead Network Satellite Server kauft, dann hat man

das in Rot, ist aber im Prinzip, sieht das genauso aus und wenn man den Susan Manager kauft, dann hat man dasselbe in Grün, denn Grün ist ja die Farbe von Susan. Es ist eigentlich von der Optik her exakt dieselbe Software und das erkennt man auch an den Features. Da möchte ich nämlich auch mal noch mal drauf eingehen, was können die

Tools überhaupt? Also prinzipiell sind die ganzen Tools mandantenfähig. Das bedeutet, ich kann Subcompanies einlegen. Ich habe zum Beispiel eine Hauptfirma, dann habe ich eine Tochterfirma und dann hat die ihren eigenen Bereich und kann in diesem Bereich ihre Systeme verwalten und provisionieren. Ich habe ein zentrales Configuration Management, das ich mehrstufig anlegen kann. Das heißt, ich

baue mir meine Konfigurationsdateien pro Netzwerk, pro Anwendungen und kann die eben zentral verwalten und auch ausrollen. Wir haben ein Software und Update Management. Das heißt, ich habe meine Software- Pakete, die ich auf die einzelnen Systeme provisioniere, aktualisiere und was auch interessant ist, insbesondere wenn man eben im Rechenzentrum arbeitet, ich habe einen Content Provisioning oder

Caching. Das heißt, ich habe keine Clients, die irgendwie eine Fireball- Regel und eine Proxy-Freigabe brauchen, damit sie ihre RPM-Pakete runterladen können. Ich habe das zentral an einer Stelle und das wird von dem System auf die Client-Systeme übertragen bzw. die Clients holen sich es ab und ich muss keine kostbare Bandbreite in irgendeiner

Art und Weise verschwenden. Und ein weiteres Feature ist System- Provisioning. Das heißt, ich kann irgendwie einen neuen Server aus dem Netzwerk booten lassen und dann wird die ganze Installation eben komplett über das Netzwerk getätigt. Was ich auch noch machen kann, ist, ich kann Sicherheits- und Lizenz-

Audits machen. Frage ist jetzt, was versteht man unter einem Sicherheits-Audit? Ich weiß nicht, ob jemand von euch schon etwas von OpenSCAP gehört hat. Das sind eben so Sicherheitskataloge, die aufgebaut werden, wo so Regeln drin sind, wie dass die in die Dateien nicht die in die Berechtigung haben dürfen. Also ich habe einen Katalog, wo ich

Sicherheitsregeln definiert habe und die kann ich eben auf den System überprüfen und somit kann ich dann eine Aussage treffen, meine Infrastruktur befolgt einen gewissen Regelsatz. Da gibt es auch, ich glaube sogar von der NSA, einen Sicherheitsstandards- Katalogsatz, den man sich dann herunterladen kann und überprüfen kann, ob das System, das man hat,

jetzt einem amerikanischen Sicherheitsstandard eben entsprechen würde, ob man das jetzt möchte, sei dahingestellt. Wenn ich mit mehreren Mandanten arbeite, kann ich zum Beispiel auch einzelne Software- Kataloge in Einheiten einteilen. Ich kann zum Beispiel sagen, ich habe einen Kunden X, der darf 500 Systeme, darf der

provisionieren und der darf auch nur für 500 Systeme Pakete runterladen und das kann ich dann damit auch ganz fein manuell regeln, dass eben dann nur bis zu 500 Einheiten verbraucht werden können. Das ist auch ganz interessant. Was es auch noch gibt, ist ein zentrales Crash Reporting, das heißt, ich kann meine Systeme so konfigurieren, dass wenn jetzt eine Anwendung aus welchem

Grund auch immer abstürzt, dann muss ich mich nicht auf den System einloggen, muss gucken, warum ist das Tool jetzt abgestürzt, muss ich nochmal neu starten, sondern wenn ein Programm abstürzt, dann wird der Absturz automatisch an Spacewalk gemeldet und auch dort in der Datenbank gespeichert und von dort kann ich es eben ganz komfortabel über die Webguide runterladen und kann mir angucken, warum das Programm abgestürzt ist und was es auch

noch gibt, aber das finde ich eigentlich nicht so hilfreich, ist es, es gibt ein Monitoring, aber auch hier die Randnotiz, vielleicht doch mal Nagios und Isingas angucken, weil es ist wirklich sehr, sehr rudimentär. Da erfolgt dann eben ein Login auf den kleinen Systemen und dann wird eben geguckt, ob mein Demon da ist und ist relativ

unflexibel und deswegen würde ich hier definitiv was anderes verwenden, CheckMK, Nagios, Isinga oder irgendwie sowas, aber es gibt die Funktionen, wenn man sie denn unbedingt haben möchte, warum auch immer. Ja, das sind eigentlich die Unterschiede zwischen den einzelnen Variationen von

Spacewalk. Wir haben einmal ja die kostenfreie Upstream- Variante und dann die kommerziellen Produkte. Spacewalk wird relativ häufig veröffentlicht, nämlich alle 2-5 Monate, warum? Es ist die technische Spielwiese, dort werden Dinge erprobt und daraus folgt dann eben auch das, was man häufiger Releases hat. Prinzipiell ist das eigentlich nur für klassische

Intel-Architektur gedacht, also eben 32- und 64-Bit- Maschinen und insbesondere geht es hier eigentlich mehr um RPM-Distribution. Das heißt, es wurde eigentlich designed, damit auf RPM- basierende Linux-Distribution zu verwalten. Zum Beispiel Enterprise Linux, also CentOS, Scientific Linux, Fedora, CentOS. Prinzipiell kann

man damit auch Debian verwalten. Wer denkt darüber nach, vielleicht Debian mit Spacewalk zu verwalten? Okay, also es ist prinzipiell möglich, es gibt aber Einschränkungen. Was zum Beispiel nicht geht, da gehe ich aber später nochmal drauf ein, ist eine Echtzeit-Systemverwaltung und ja, Configuration Management. Also eigentlich

einer der Hauptgründe für mich gewesen, sich damit zu beschäftigen, fehlt aktuell unter Debian, ist da die Überlegen, ob das vielleicht dann nicht sinnvoller wäre, was anderes zu verwenden. Prinzipiell Opensuse und Fedora kann ich damit auch verwalten. Als Datenbank dient es im Moment als Backend eben eine PostgreSQL oder, wenn man

das denn möchte, eine Oracle-Datenbank. Das war früher mal der Default, mittlerweile wird PostgreSQL aber auch voll supportet und ich würde auch immer PostgreSQL nehmen, weil es ist einfach ganz simpel zu installieren, es ist ein Befehl und das wird automatisch alles installiert und konfiguriert und bei Oracle muss ich sehr viel manuell machen. Aber prinzipiell geht es. Der

Red Hat Satellite ist eine Enterprise-Produkt, das eben dann nur alle 9 bis 12 Monate released wird, weil man kann dem Kunden ja nicht das antun, dass er alle paar Monate seine Software aktualisieren muss. Was hier noch mit hinzukommt ist, ich habe natürlich auch 32 und 64-bit Intel-Architektur und ich habe da noch, ich glaube,

das dürfte die IBM P-Series sein, wenn ich das richtige Erinnerung habe. Also eben die IBM PowerPC-basierenden Server kann ich damit verwalten, aus dem Grund, weil es eben auch Red Hat für diese Maschinen gibt. Deswegen ist hier der Support mit drin. Prinzipiell ist das eigentlich so gedacht, dass man damit nur Rell-Maschinen

administriert. Also das ist das Einzige, was das Support wirklich abdeckt. Ich kann damit natürlich auch ein CentOS verwalten, aber wenn es nicht funktioniert, dann darf ich natürlich nicht auf die Gedanken kommen, da ein Ticket beim Red Hat Support für aufzumachen, denn das wird einfach nicht unterstützt und da muss ich eben selbst gucken, wie ich damit klarkomme. Der Susan- Manager? Ja, eine Frage. Also

es funktioniert, da ja Spacewalk das kann, aber der Support der, die Frage war übrigens, ob Red Hat Satellite auch Fedora unterstützt. Also funktionieren tut es, aber es ist natürlich supported. Ja, Susan-Manager kann

gegenüber Spacewalk und Satellite auch noch Ethereum-Maschinen verwalten. Verwendet jemand von euch Ethereum-Server? Aus politischen Gründen oder Laufzeitgründen? Okay, alles klar. Aus dem Grund, Slash gibt's eben auch für Ethereum. Deswegen ist der Support damit drin. Was hier ganz interessant ist, prinzipiell

ist auch hier eigentlich liegt der Fokus darauf, dass man mit dem Susan-Manager eben Slash-Maschinen verwaltet. Man kann aber auch Red Hat-Maschinen verwalten. Aber hier ganz wichtig, wenn man das macht, dann erlischt der Support bei Red Hat, weil was man eigentlich macht ist, man kauft ein Zusatzprodukt, das sich eben Susan Expanded Support nennt

und Susan holt sich dann den Quellcode von Red Hat, der Patches, kompiliert den Neu und fertigst du das Update. Und der Support-Anspruch ist dann natürlich weg und ich muss dann eben Susan kontaktieren. Ist eigentlich primär dafür gedacht, wenn Kunden eine Migration anstreben. Also wenn jetzt ein Kunde Red Hat-Systeme hat und er will auf Susan gehen, dann

kann er ja nicht alle Systeme an einem Wochenende migrieren. Das geht ja nicht. Und eigentlich ist das dafür so primär gedacht gewesen, zumindest habe ich das so verstanden. Was sind jetzt die Exklusivfunktion zwischen den verschiedenen Komponenten? Also Spacewalk und Satellite sind die einzigen, die aktuell noch Solaris unterstützen. Susan hat

da bewusst den Support rausgenommen, weil Susan eben für sich entschieden hat, dass das nicht so gefragt ist. Der Red Hat Satellite ist der einzige, der eine direkte Verbindung zum Red Hat Network, also eben dem geschützten Kundenbereich, wo ich als Red Hat-Kunde meine Patches bekomme, herstellen kann. Was jetzt neu hinzugekommen ist bei Susan Manager und Spacewalk ist,

es gibt eine neue Web2.0 JQI Benutzeroberfläche. Also früher sah die relativ alt Backen aus und da hat man jetzt eine schöne JQI Web Oberfläche, die ich auch zum Beispiel auf dem Tablet verwenden kann. Also wenn ich mal eben schnell noch ein System fernwarten will, dann kann ich das jetzt auch bequem mit dem Smartphone machen. Das ist sehr, sehr schick gemacht, war übrigens eine Funktion, die von Susan

vorgeschlagen und implementiert wurde. Also auch hier beteiligt sich Susan maßgeblich an der Weiterentwicklung der Produkte. Was glaube ich auch von Susan kam, war die Stromverwaltung. Da gehe ich später noch mal drauf ein. Es gibt eine Software Komponente, die eben Systeme provisionieren kann. Also ich

baue den Server ein, schiebe den ins Rack rein und der soll dann mit Red Hat betankt werden zum Beispiel und dann kann diese Software Komponente jetzt eben selbst den Server anschalten, indem es sich eben mit dem Remote- Interface verbindet und den Strom einschaltet und so muss man sich also nicht mehr die Arbeit machen, den Server einzuschalten. Das übernimmt da einen Koppler für einen.

Zur Architektur, da gibt es hier ein Bildchen, das habe ich von der Spacewalk Seite, ist nicht mehr ganz so aktuell, aber ja. Die Frage war, welche Solarisysteme genau unterstützt werden. Da habe ich schon nachher noch einen Slide zu. Da gibt es

nämlich auch eine Liste von Versionen, die funktionieren. Da gehe ich gleich schon mal drauf ein. Zur Architektur, der Hauptbestandteil ist eigentlich der Tromke selber, weil Spacewalk ist in Java geschrieben, also ist das so im Prinzip einer der wichtigsten Komponenten, weil die ganze Logik eben in Java programmiert ist. Dann gibt es eben die Datenbank. Hier steht

zum Beispiel noch, dass das Currently Oracle ist. Mittlerweile funktioniert aber eben auch Posca SQL. Und dann gibt es einen Dienst, der im Prinzip entfernt mit einem Cron-Deepen verglichen werden können. Es gibt einen Dienst, der nennt sich Tescomatic. Das ist im Prinzip eine Engine, die Aufgaben ausführt, also so eine Art geplante Tasks-

Funktion. Das heißt, da sind zum Beispiel so Dinge drin, wie dass er nachts immer die neuesten RPM Packages runterlädt, dass ich morgens dann meine Updates sehe und die dann provisionieren könnte. Dann gibt es noch einen Apache- Server, der eben Python und Perl-Händler hat. Der Unterschied ist, dass ich auf mehrere Arten

Weise mich als Client mit dem Spacewalk verbinden kann. Zum einmal kann ich mich als Betriebssystem Client verbinden. Das ist dann quasi die Paketverwaltung des Systems. Das ist ja auch in irgendeiner Art und Weise ein Client. Der verbindet sich dann mit einem Backend über den Python-Händler und kann dann eben sehen, dass es die in die

Updates gibt. Dann habe ich eine Administrationsoberfläche, die wir ja gerade schon gesehen haben, die ich als Admin verwende. Die geht dann eben über die Perl- Händler. Und dann habe ich noch die Funktion, also es gibt eine sehr gute API, die ich verwenden kann. Das ist eine Python, Perl und Ruby- API. Da kann ich mir eben Skripte programmieren. Also wenn ich Dinge automatisieren möchte,

habe ich hier auch die Möglichkeit mit mehreren Programmiersprachen mir eben das Leben leichter zu machen. Was auf der Grafik leider fehlt, aber auch unheimlich wichtig ist, deswegen gehe ich hier nochmal drauf ein. Es gibt einen Demon zur Echtzeit-Systemverwaltung, der sich OSAT nennt. Das steht für Open Source Architecture Demon. Jetzt ist die Frage, was bedeutet Echtzeit an der Stelle? Hintergrund ist, dass Aktionen,

die ich in irgendeiner Art und Weise auswähle, eben über das Jabber-Protokoll gestartet werden. Normalerweise ist es nämlich so, ich klicke mir irgendwo eine Aufgabe zusammen. System A soll denen den Patch installieren. Und dann gibt es einen Demon auf dem Kleinsystem, der alle Stunde zum Beispiel guckt, ob es eine neue Aufgabe gibt. Das würde ja bedeuten, ich müsste jetzt eine

Stunde warten. Und mit OSAT gehe ich eben einen anderen Weg, da wird dann über das Jabber-Protokoll auf dem Client gesagt, es gibt eine neue Aufgabe. Und der Client holt sich die Aufgabe ab und führt sie eben so schnell wie möglich aus, sodass ich keine Stunde warten muss. Dafür muss ich natürlich einen Port öffnen, der hier steht, 5222, und dann funktioniert das eben auch. Dann

gibt es noch einen TFTP-Saber, den benötige ich, wenn ich technische Systeme kickstarten möchte. Also ich habe ein System, das budet aus dem Netzwerk und dafür braucht es eben den TFTP-Saber, damit ich den Kernel und das Basis Image runterladen kann. Dann gibt es den Koppler D, den ich eben schon mal kurz angesprochen habe. Das ist eben ein Dienst, der

mir automatisch FTP, DHCP und DNS konfigurieren kann. Ich kann also in der Webguide sagen, ich habe ein neues System mit der und der MAC und das System soll einen REL6 bekommen und dann wird automatisch eben DNS, DHCP und TFTP konfiguriert und ich muss den Server nur einschalten und dann wird das System wie erwartet installiert. Wenn man jetzt mehrere

Standorte betreut und Systeme verwaltet, die an anderen Standorten stehen, dann ist vielleicht auch der Spacewalk- Boxi interessant. Das ist einfach eine Software-Komponente, die Pakete lokal vorhält. Das heißt, nicht jeder Client, der jetzt vielleicht auf einem anderen Kontinent sitzt, zieht sich dann die Pakete von meinem Hauptserver,

sondern die werden eben nochmal lokal vorgehalten und ich spare mir damit eben Traffic und auch Last. Was hat sich denn überhaupt getan in den letzten Wochen in der Entwicklung? Es gibt eine neue Version, Spacewalk 2.2, die wurde am 16. Juli veröffentlicht und die Haupterneuerung war eigentlich, dass jetzt eben Enterprise Linux 7 Clients unterstützt werden. Betonung liegt auf Clients. Der

Server muss immer noch Enterprise Linux 5 oder 6 sein, aufgrund fehlerhaften Abhängigkeiten. Also wenn jemand jetzt sich einen neuen Spacewalk-Server einrichten will, bitte kann CentOS 7 oder 7 verwenden, das funktioniert wirklich nicht. Dann gibt es neu eine Read-Only-API für Audit-Zwecke, da gehe ich nachher nochmal anhand ein paar Beispiele davon ein.

Also gemeint ist damit, ich habe Benutzer, die ich anlege und denen ich Rollen zuweise. Zum Beispiel einen Admin-Benutzer, einen andere Admin, der nur beschränkte Rechte hat und für Audit-Zwecke, zum Beispiel wenn ich auslesen will, welche Patches es für welche Systeme gibt, kann ich einen Read-Only-User erstellen, der dann wirklich nur lesen darf. Also ich habe da keine theoretische Gefahr, dass er mir eventuell auf grund von einem Fehler irgendwas

zerstört. Dann gibt es eine Funktion, die sich Action-Chaining nennt und da kann ich eben voneinander abhängige Aktionen, zum Beispiel beim System-Update eben voneinander abhängig machen kann und nur wenn Aktion 1 ausgeführt wird, wird auch Aktion 2 ausgeführt. Da gibt es eine sehr interessante Demo auf der SUSE-Webseite, da kann man sich das mal angucken und was auch

überarbeitet wurde, war die Pearl Python und Ruby-API, eben weil es jetzt neue Funktionen gibt. Und es wird vielleicht einiges enttäuschen hier, die Solaris- Unterstützung ist jetzt deprecated, das heißt, man denkt darüber nach, diese Funktion in zukünftigen Versionen nicht mehr

zu implementieren. Meine Frage, wer verwendet denn überhaupt Solaris hier oder andere Unix-Systeme? Solaris? HPOX? Aix? 264? Ja, also ist jetzt also

deprecated. Man sollte nicht damit rechnen, dass in den nächsten zwei, drei Jahren diese Funktion noch integriert ist. Okay, jetzt haben wir ganz viel darüber gehört, wo die Unterschiede sind, aber wie installiere ich das System eigentlich? Also empfohlen wird, dass ich mindestens 2 GB Arbeitsspeicher auf dem System habe, wie schon erwähnt, das

muss eine Enderpräsidung 5 oder 6 sein, kein Enderpräsidung 7. Und wie das eben so üblich ist, habe ich ein Repository für die Spacewalk-Pakete, wenn ich das Ganze auf einem Rails-System installieren möchte, dann muss ich eben ein zusätzliches Repo von Red Hat noch einbinden und auf CentOS, Scientific Linux oder Oracle Linux gibt es eben nochmal

zwei Repositories, nämlich JPackage und Apple, die ich einbinden muss. In dem einen sind irgendwelche Java-Libraries drin und in dem anderen eben Pakete, die von anderen Community-Leuten eben gebaut werden. Wenn ich das Ganze auf Fedora 20 installieren möchte, muss ich ein paar RPM-Libraries installieren und ich muss auch

ein paar downgraden, damit das überhaupt funktioniert. Hier die genaue Version, wer das auf Fedora 20 machen möchte. Ganz wichtig, vom Netzwerk her, FQDNs müssen vollständig auflösbar sein, also unbedingt hostname –s –f überprüfen. Wenn das nicht funktioniert, dann wird auch Spacewalk nicht funktionieren, weil die Kommunikation ausschließlich über FQDNs

implementiert ist. Und es gibt auch ein paar Firewall-Regeln, die ich setzen muss, zum Beispiel für die Web-Überfläche, klar, 80 und 443. Wenn ich Aufgaben auf den System einplanen möchte, gibt es eben hier noch weitere Ports und für Kickstart brauche ich dann natürlich auch nochmal einen UDP-Port, den ich öffnen möchte. Zum Speicherplatz. In aller Regel wird empfohen,

mindestens 12 GB für die Post- SQL-Datenbank zur Verfügung zu stellen. Wenn ich jetzt Oracle verwende, dann muss ich das je nach Edition eben nochmal genau in Erfahrung bringen, weil je nach Edition gibt es da verschiedene Anforderungen. Es wird empfohen, mindestens 6 GB für RPM-Pakete zur Verfügung zu stellen. Allerdings kann man das auch

berechnen und das empfiehlt sich wirklich vorher zu berechnen, denn da gibt es eben Regeln, zum Beispiel pro registrierte System 250 KB, pro Softwarekanal 500 KB und pro Paket in einem Softwarekanal eben 230 KB. Das heißt, wenn wir das jetzt mal ausrechnen, ich habe hier mal zum Beispiel, nehmen wir an, ich habe 10 CENTOS-Systeme, habe da zwei Repositories, nämlich einmal eben den

Base Channel, wo die ganzen Basispakete drin sind und einmal den Update Channel, wo eben die neuen Updates drin sind. Dann habe ich erstens mal 10 Systeme, das macht dann in der Summe 3 MB. Für den Base-Kanal komme ich dann bei etwas über 6000 Paketen auf 1,4 GB und für die Updates dann für die 1000

Pakete auf 248 MB, in der Summe also um die 2 GB. Aber es macht Sinn, da immer mal ein bisschen mehr Speicherplatz mit reinzunehmen, denn insbesondere, wenn man mehrere Architekturen, mehrere Releases hat, dann summiert sich das eben dann doch. Die Installation selbst ist relativ einfach, wenn man die Repos eingebunden hat, sind das

einfach ein paar Pakete, die man installiert. Für Posca SQL einfach nur diesen Befehl absetzen. Wenn ich Oracle verwende, dann gibt es da andere Pakete und ganz wichtig, verwendet einer von euch die Oracle Express Edition, die kostenlose Variante der Datenbank. Nein? Gut. Falls das jemand vorhat, unbedingt den Oracle Instant

Client und nicht den Xe Client verwenden, er funktioniert wirklich nicht. Ich habe mich mehrere Stunden damit beschäftigt, es geht nicht. Die ganzen Details, wie das genau funktioniert, findet man auch im Spacehawk Wiki, das hätte jetzt den Rahmen bei weitem gesprengt, darauf einzugehen. Wenn ich die ganzen Pakete installiert habe, dann gibt es ein Setup Tool, das ich eben hier einfach ausführe, mit dem

Schalter minus minus disconnect, weil ich ja den Server jetzt das erste Mal installiere. Da werden so Dinge abgefragt, wie, wie heißt der Admin, was ist die, was ist die E-Mail-Adresse vom Admin. Dann wird auch ein Zertifikat generiert, denn das Ganze wird auch verschlüsselt eben, die Kommunikation erfolgt verschlüsselt. Das heißt, die üblichen Fragen, wenn ich in Open SSL

Zertifikat erstelle, Standort, Bundesland, einfach den Assistenten ausführen und wenn ich das gemacht habe, gibt es eben einen Dienst, Spacehawk Service, den aktiviere ich sinnvollerweise so, dass er beim Boden automatisch gestartet wird und dann starte ich den Dienst, ganz einfach. Und dann habe ich erst einmal die erste Konfiguration

vorgenommen und kann mich dann auch schon einloggen und kann dann weitere Konfigurationen vornehmen. Zum Beispiel diesen Haken, nicht verbundener Spacehawk, den deaktivieren wir, den mussten wir vorhin setzen, weil es eben die erste Installation des Systems war. Und wenn ich das gemacht habe, dann fange ich eigentlich an und passt das System so an, wie es in mein Unternehmen passt. Zum Beispiel muss ich den

Solaris Support explizit aktivieren, wenn ich Solaris verwende. Dann kann ich zusätzliche Konten anlegen, Organisationen und so weiter, und so weiter. So, wenn ich das gemacht habe, dann kann ich mit dem System noch nicht so viel anfangen, denn es fehlen noch Software Channels. Und da kommen wir zum nächsten Thema, Kanäle, Subkanäle und Repositories.

Prinzipiell ist es so, dass jede Distribution, also zum Beispiel CentOS 6, wird unter Spacehawk als Kanal abgebildet. Und jeder Kanal kann eben über mehrere Unterkanäle verfügen. Und jeder Kanal oder Unterkanal hat letztendlich einen Netzwerkspiegel, ein Netzwerk Repository, über den ich eben dann Pakete in diesen Kanal

einpflege. Und den Zugriff pro Kanal kann ich ganz einfach pro System limitieren. Gleich mal ein Beispiel. Das ist jetzt hier ein Screenshot aus meiner Spacehawk-Testumgebung. Das ist eben hier ein sogenannter Hauptkanal, CentOS 5, oder hier eben CentOS 6, und das sind untergeordnete Kanäle. Also zum Beispiel CentOS 6

ist der Hauptkanal, und dann gibt es ein Unterkanal Extras, Updates, und so weiter, und so weiter. Wenn ich das alles angelegt habe, dann muss ich diese Repositories ja in irgendeiner Anweise synchronisieren. Da gibt es mehrere Möglichkeiten. Es gibt einmal eben ein Programm dafür, Spacehawk Repo Sync, oder ich kann das auch ganz

komfortabel über die Webgui mir zusammenklicken und kann dort einstellen, dass er jede Nacht um drei Uhr die Updates eben runterlädt. Wenn man das manuell per Grundjob macht, dann stellt sich die Frage, warum soll ich das denn per Grundjob machen, wenn ich es doch auch über die Webgui machen kann. Der Vorteil für mich ist, wenn ich einen Grundjob habe, ich kann den besser debacken, weil ich da Federmeldungen sehe. Ich habe es nicht geschafft

über diese Tascomatic Engine ein sinnvolles Log zu finden, das mir eben mitteilt, warum das jetzt heute Nacht ausgerechnet nicht funktioniert hat. Deswegen gehe ich immer den Ansatz, das über einen Grundjob zu machen und dann verwende ich eben hier so ein Kommando und schreibe eben rein Spacehawk Repo Sync, Channel sowieso, dann meinen Namen, die URL,

es ist ein Jugendkanal und fertig. Kann man wie gesagt machen, wie man möchte. Ich persönlich bevorzuge eben die Grundjoblösung. Hier nochmal ein Screenshot von der Webgui. Hier haben wir jetzt ein System und ich kann pro System einstellen, worauf zugegriffen werden darf. Also hier haben wir jetzt ein CentOS 6 System, das darf auf Extras, Updates

und so weiter zugreifen, aber auf diese beiden Kanäle nicht. In Klammern sieht man hinten noch Unbegrenzt. Also ich könnte jetzt auch, wenn ich jetzt eine Kundenorganisation habe, könnte ich jetzt sagen, ihr dürft maximal 10 dieser Kanäle abonnieren und dann würde ich jetzt eben sehen, dass ich jetzt von diesen 10 Berechtigungen 8 schon verwendet habe. Das würde ich jetzt

an der Stelle sehen, ist hier allerdings auch unbegrenzt. Deswegen hier der Hinweis. Was kann ich denn überhaupt machen, wenn ich ein System registriert habe? Also es gibt mehrere Möglichkeiten oder mehrere Aufgaben, die ich pro System ausführen kann, um mal ein paar Beispiele zu nennen. Ich kann natürlich Softwarepakete installieren, aktualisieren und entfernen. Das ist ja eine der Hauptfunktionen. Dann kann ich Errata anwenden.

Ist Errata jedem in dem Raum hier ein Begriff? Also Errata ist eigentlich eine Art Update, was mir aber genau sagt, was es denn für ein Update ist. Weil Update ist ja relativ, Update kann heißen, es ist ein Bugfix, es ist ein Feature Enhancement, es ist ein kritischer Bugfix und ein Errata beinhaltet eben ein Update,

aber es sagt mir genau, was behoben wurde. Das heißt zum Beispiel ein Hinweis, es war ein kritischer Bugfix und es gab ein CWI mit der ID sowieso und da wurde das und das gefixt. Das ist vielleicht auch ganz interessant, weil man installiert ja, wenn man einen Rechenzimm betreibt, nicht einfach immer alle Updates, sondern nur die kritischen, teste die erst und zieht dann die anderen nach.

Deswegen ist das an der Stelle auch ganz wichtig, dass man eben auch Errata als solcher erkennen und provisionieren kann. Dann kann ich noch natürlich Shell-Befehle ausführen und kann Systeme neu starten, kann Konfigurationsdateien aktualisieren und so weiter. Eine weitere Funktion,

die ich äußerst hilfreich finde, ist der System Set Manager. Das bedeutet nämlich, dass ich ähnliche Systeme gruppieren kann. Zum Beispiel, ich kann mir eine Gruppe bauen, wo ich alle Web-Server drin habe. Ich kann mir eine Gruppe bauen, wo ich alle Datenbank-Systeme drin habe. Und Vorteil ist dann eben, dass ich diese ganze Gruppe an Systemen, die kann ich so verwalten, wie ein einzelnes Haus. Und das spart mir unheimlich viel Zeit,

wenn ich eine große Systemlandschaft habe. Und was ich da wirklich sehr empfehlen kann, ist pro Applikation und pro Priorität Gruppen erstellen. Also ich verwende das auch bei uns im Rechenzentrum so, dass ich alle Testsysteme in der Gruppe habe, alle Produktivsysteme und alle Entwicklungssysteme. Und wenn jetzt eben Patches rauskommen, dann teste ich die natürlich

erstmal auf den Entwicklungssystem. Wenn das funktioniert, geht es auf die Testsysteme. Und wenn auch das funktioniert, dann eben direkt auf die Produktion. Und da gehe ich dann Applikationsweise vor, erstmal die Web-Server, bevor ich SAP kaputt mache. Und würde ich hier auch wirklich dringend empfehlen, da mit Gruppen zu arbeiten pro Anwendung. Macht definitiv Sinn.

Kommen wir zum Configuration Management. Die Konfigurationsdateien werden und das Basewalk in einem oder mehreren Kanälen gespeichert. Und diese Kanäle kann ich eben hierarchisch anordnen. Das bedeutet, ich kann zum Beispiel für eine Anwendung Oracle kann ich andere Konfigurationsdateien wie für alle anderen Systeme haben. Ich kann einen generischen Kanal haben,

aber für Web-Server gibt es dann doch nochmal andere Konfigurationen. Das kann ich eben hierarchisch anordnen. Und wenn ich jetzt eine Datei habe, die eben in mehreren Kanälen vorkommt, dann wird die, die zuerst quasi passt oder die es erstmal vorkommt, die wird auch ausgewählt. Und die Konfigurationsdateien kann ich ganz komfortabel eben über eine Web-Uberfläche erstellen,

anpassen und hochladen. Die Web-Uberfläche hat also an der Stelle einen integrierten ASCII-Editor, worüber ich eben dann die Dateien erstellen kann. Und was auch ganz hilfreich ist, wenn ich Konfigurationen zentral speichere, komme ich irgendwann an einen Punkt, wo mir Informationen zum System selbst fehlen.

Also, als Beispiel zu Beispiel die Postfix-Konfiguration, wo der Hostname des Systems drin steht. Da müsste ich jetzt ja pro System eine einzelne Konfig-Datei, wo der Name drin steht, erstellen. Das wäre ja Quatsch. Dafür gibt es nämlich Makros. Und mithilfe der Makros kann ich eben einzelne Werte aus dem Systemprofil entnehmen. Ich kann dann zum Beispiel in der Postfix-Konfig an der Stelle, wo jetzt der Hostname stehen würde,

kann ich ein Makro einfügen, das mir dann eben aus dem Systemprofil, aus dem Spacewalk mir den Hostname platziert. Da gibt es in der RedHat Satellite-Dokumentation einige Beispiele. Wenn man da näher reinschauen möchte, unbedingt da mal auch reingucken.

Die haben eigene Ersetzungen. Die Frage war, wie wird das denn dargestellt? Sind das dann Shell-Variablen? Prinzipiell kann ich eigene Makrozeichen definieren. Weil es gibt ja, je nach Anwendungen gibt es andere Syntaxe.

Also eine Postfix-Konfig ist anders aufgebaut als jetzt eine Apache-Konfig zum Beispiel. Da kann ich genau maskieren, wo ein Makro anfängt, wo ein Makro aufhört. Sodass ich mir da nicht den Syntax von der Postfix-Konfig kaputtmache. Noch eine Frage? Wenn ich dann eine Konfigurationsdatei

erstellt habe, dann wird pro Datei eine Revision erstellt. Also ich habe auch eine relativ minimalistische Versionierung mit in dem System. Und es werden MD5-Prüf-Summen verwendet. Somit kann ich dann sicherstellen, dass ich auch die Konfig wirklich auf dem System habe, die ich haben wollte. Und was auch ganz wichtig ist,

Konfigurationsdateien werden nicht automatisch ausgerollt. Das heißt, wenn ich jetzt eine Änderung mache, dann muss ich das schon selbst auf den Systemen platzieren. Und da gehe ich dann auch idealerweise eben so vor, dass ich erst auf einzelnen Systemen das ganze teste, bevor ich es auf alle anderen ausrolle. Vielleicht mein Beispiel, wenn ich eine Konfigurationsdatei anlege,

dann gebe ich eben so Dinge an wie den Dateinamen, den Dateipfad, den Owner, die Berechtigungsmodi. Und hier kann ich dann zum Beispiel eben auch pro Datei andere Makrotrendzeichen verwenden. Also für eine Postfix-Konfig nehme ich dann eben andere wie für eine Apache- oder NGX-Konfig. Und letztendlich ganz wichtig natürlich auch der Inhalt

der Konfigurationsdatei, wobei ich den nicht manuell eingeben muss. Ich habe auch die Möglichkeit, dass eben, wenn ich dann schon auf der Festplatte habe, einfach hochzuladen. Noch mal ein paar Screenshots dazu, um sich das besser vorzustellen. Das ist jetzt ein Screenshot vom System, das ist in zwei Kanälen. Nämlich eben einfach einen generischen, wo ich einfach alles irgendwie ranschmeiße.

Und eben einen LAN-Kanal, wo ich für ein spezielles Netzwerkssegment Konfigurationsdateien drin habe. Und pro Kanal muss ich eben eine Position definieren. Das heißt, hier ist jetzt definiert, wenn eine Datei in mehreren Kanälen vorhanden ist und sie ist zuerst in LAN, dann wird sie genommen.

Wenn sie da nicht vorhanden ist, dann nehme ich eben die aus dem anderen Channel. Also ich muss dann eine Priorität vorgeben, sonst funktioniert dieser Mechanismus einfach nicht. Und wenn ich jetzt eine Datei geändert habe, so wie in diesem Beispiel, da wurde eine Datei editiert. Die ist jetzt eben in Revision 2 vorhanden. Dann kann ich pro System eben sehen, welche Revision ich installiert habe und kann dann selektiv die Systeme auswählen,

auf denen ich das jetzt ausrollen möchte. Also hier zum Beispiel auf den ersten vier Systemen. Wir haben vorhin kurz über Erata gesprochen. Sollten wir sich vielleicht mal im Detail nochmal angucken. Also prinzipiell ist es so, wenn ich ein Rel-Kunde bin, dann erhalte ich die Erata automatisch von Red Hat, weil Red Hat mir ja auch die Updates liefert.

Und ein normaler CentOS Patch ist erstmal nur ein reguläres Update. Wenn ich natürlich parallel Red Hat Systeme habe und ich sehe den Namen des Pakets, dann kann ich mir natürlich herleiten, was da jetzt geändert wurde, ob das jetzt ein Bugfix war oder ein Feature Enhancement. Aber prinzipiell ist es ein normales Update und es ist nicht sehr aussagekräftig. Und da gibt es eben einen ganz tollen Service,

der sich CEFS nennt. Und der Service erstellt automatisch Erata-Informationen für CentOS. Und das funktioniert eben mit einem Server, der eben betrieben wird, der nichts anderes macht als Mailinglisten zu analysieren. Das heißt, wenn Red Hat irgendwo einen Patch rausbringt, dann automatisiert irgendwo eine E-Mail in einer Mailinglist.

Und diese Mailinglist wird halt eben von CEFS abgegriffen und dann werden Erata-Informationen als XML-File generiert. Und diese XML-Informationen kann ich mir natürlich lokal importieren. Und dann habe ich dieselben Informationen, wie sie eben Red Hat für Enterprise-Kunden liefert, auch für mein CentOS. Das kann ich dann auch noch verknüpfen

mit den sogenannten Red Hat Security Announcements. Dann sehe ich auch wirklich in der langen Beschreibung, was jetzt genau geändert wurde. Also auch die CVE-IDs und wer das Problem gemeldet hat. Das zeige ich auch gleich noch einen Screenshot zu. Und so habe ich die ganzen Vorteile auch als CentOS-User.

Das funktioniert auch relativ einfach. Das ist auch wieder ein guter Kandidat für einen Cronjob, den man nachts einfach einmal ausführt. Da gibt es einen XML-File auf dem Server, das lade ich runter. Und dann gibt es einen Skript, Erata-Import.pl, ein kleines Perl-Skript. Und damit importiere ich einfach nur die XML-Dateien. Also ich gebe hier den Abfahrt an,

und gebe einen für welche Kanäle. Also er hat in diesem XML-File eben für ganz viele verschiedene Kanäle Information. Also zum Beispiel auch für das Apple-Repository. Und da sage ich ihm zum Beispiel für die Kanäle CentOS 5 und CentOS 6, bitte die Erata importieren. Und dann geht er durch dieses XML-File

und importiert nur für diese Kanäle eben diese Erata-Information. Hier nochmal einen Screenshot mit einem Beispiel. Das war gerade kürzlich ein Update für Chemo KVM Package. Und hier habe ich jetzt zum Beispiel diese Red Hat Security Announcements importiert. Also das ist das, was eigentlich der Red Hat Kunde von Red Hat bekommt für seine Satellites.

Nur eben hier auf Spacewalk für CentOS. Und da steht jetzt eben drin, also man sieht es auch anhand des Icons, dass es hier ein Security Adversary war, also eben ein Security Fix. Und hier wurde eben KVM noch was aktualisiert und Red Hat bedankt sich für die NSA für dieses Update.

Und so kann ich dann also quasi pro System genau sehen, was für Updates gibt es und ich kann selbst auswählen, welche ich zuerst installieren möchte. Kommen wir zum Solarisupport. Wer verwendet jetzt nochmal genau Solaris? Weil das geht teilweise sehr ins Detail. 1, 2, 3, 4, ok. Läuft auch ein bisschen die Zeit davon,

deswegen gehe ich auf die Grundlagen ein und wenn da noch weitere tiefergehende Fragen sind, dann kann ich einfach einmal zu mir kommen. Ja, also prinzipiell kann ich auch Solaris mit Spacewalk verwalten. Das ist ein Feature, das aber in den nächsten Versionen wohl rausfliegen wird. Prinzipiell haben Spacewalk und Red Hat Satellite Unix-Support. Vielleicht war ja früher mal geplant,

andere Unix auch zu unterstützen. Und Vorteil für mich ist, Solaris-Systeme kann ich ganz normal wie Linux-Hosts eben verwalten und auch registrieren. Vorhin war die Frage nach den Releases. Offiziell in der Red Hat Dogo steht drin Sun oder Oracle Solaris 8-10 eben Intel und Spark. Das wird offiziell von Red Hat Satellite unterstützt.

Inoffiziell, ich habe mir mal die Mühe gemacht das auszuprobieren, geht auch Solaris 11, oben Indiana, oben Solaris und prinzipiell sollten auch alle auf Illumus-basierende Derivate auch funktionieren. Also jetzt NABIT, Smart OS, das sollte auch funktionieren. Also ich habe ein paar davon ausprobiert und hat wunderbar funktioniert.

Smart OS und NABIT habe ich jetzt eben nicht ausprobiert, aber das sollte theoretisch auch gehen. Es gibt aber auch einige Einschränkungen. Zum Beispiel die Software-Pakete, die kann ich nicht über Netzwerke-Pakete posten, weil da einfach ein ganz anderer Mechanismus verwendet wird, wie jetzt bei Jam zum Beispiel oder bei Debian-Paketen. Die Package-Files muss ich auch konvertieren mit einem Tool, das eben Solaris 2MPM heißt

und die Pakete muss ich dann letztendlich auf den Server hochladen. Und Echtzeitverwaltung mittels OSAT, was eigentlich ein sehr tolles Feature ist, funktioniert eben einfach nicht. Und da gibt es dann diesen RHNSD, den habe ich vorhin kurz erwähnt. Das ist eben der Dienst, der zum Beispiel alle 60 Minuten guckt, gibt es was Neues, soll ich es ausführen und dann führ das aus. Das ist also die einzige Art der Komplikation, die funktioniert. Also kein

Pushing, ein reines Polling, das man natürlich auch netzwerkechnisch betrachten muss. Remote-Kommandos funktionieren bei manchen Architekturen einfach nicht oder nur sehr unzuverlässig und teilweise stehen da auch ganze Wirre-Informationen von der Hardware oder Paket-Informationen, was einfach nicht funktioniert. Warum, konnte ich jetzt nicht rausfinden, variiert einfach pro

Release, muss man dann einfach mal ausprobieren, ob das funktioniert. Vorbereitung, wenn ich das System den Spacefork Server einrichte, gibt es da einen Haken in der Admin-Oberfläche, den muss ich setzen und den diets neu starten. Also da wird anscheinend irgendeine Komponente im Hintergrund erstellt oder aktiviert und das erfordert eine Neustart. Dann muss ich natürlich

einen Basiskanal erstellen und eventuell Unterkanäle, wenn ich sie denn habe, und einen Aktivierungsschlüssel, weil prinzipiell kann ich ein Linux- oder Solaris-System eigentlich auf zwei Wegen registrieren. Ich kann nämlich einfach einmal mich als Admin an dem System einloggen, kann sagen, ich möchte dieses System jetzt registrieren. Das funktioniert nicht mit Solaris, da muss ich eben einen

Aktivierungsschlüssel erstellen, der dann eben das System ohne Username und Passwort mit dem System registriert. Für Solaris selbst brauche ich immer noch ein paar Abhängigkeiten, die ich installieren muss und ein Bootstrap-Paket. Das findet man auf der Spacewalk-Seite oder wenn man einen Red Hat Satellite hat, eben auch lokal. Ich brauche oben

SSL, ich brauche Zip-Bibliotheken und ich brauche auch das Gnu-Z-Runtime. Das muss ich eben installieren über die DVD, über das Repo vom Hersteller, wie auch immer. Dann installiere ich eben dieses Paket und passe noch ein paar Pfade an, weil dann eben unter Opt-Red Hat sowieso die ganzen Tools installiert werden und da auch die Libraries liegen und das liegt oftmals nicht im Suchtpfad, dann laufen die Programme

eben nicht und wie vorhin schon erwähnt, kann ich das nicht interaktiv mit Username und Passwort registrieren, sondern ich muss das mit dem Key machen, deswegen dieses Tool verwenden und ich muss dann noch die Berechtigung einräumen, dass ich das System eben remote konfigurieren kann. Gut, der

Ausgang funktioniert nicht, haben wir schon gehört, deswegen der HNSD muss konfiguriert werden. Ich setze also eine Variable, die eben sagt, nach wie vielen Minuten wieder nach neuen Aktionen gesucht werden soll. Wenn ich Solaris 9 verwende, erstelle ich mir einen Init-Skript, so relativ einfach, wenn ich Solaris 10 oder 9 habe, dann muss ich einen SMF-Manifest erstellen,

also so ein XML-basierendes Dokument, was mir sagt, was braucht ihr Dienst, wie wird er gestartet, das kann relativ umfangreich sein, deswegen habe ich da mal was vorbereitet. Auf GitHub gibt es nämlich schon ein fertiges Manifest, das ihr verwenden könnt, das muss man einfach eben nur runterladen, validieren, importieren und dann kann man den Dienst starten, also

man muss nicht selbst die Arbeit machen. Dann am Ende einfach mal gucken, ob der Dienst läuft und dann kann ich prinzipiell das System auch mit Spacewalk verwalten. Gut, Pakete hochladen, wie schon gesagt, ich muss die konvertieren, ich lade also das Binärpaket runter, konvertiere es in ein npm-File und schiebe das mit RHN-Push auf den Satellite

oder Spacewalk-Server und habe dann eben hier zum Beispiel ein Webmin-Paket. Das war das einzige Paket, das ich gefunden habe auf die Schnelle. Gut, wie gesagt, wenn da weiteres Interesse daran besteht, einfach nachher mich mal ansprechen, dann kann ich noch ein paar Detail-Informationen

zur Verfügung stellen. Das letzte Thema, auf das ich zu sprechen kommen möchte, sind Tipps und Tricks, wie man sich die Arbeit mit Spacewalk oder RHN-Satellite ein bisschen schöner machen kann. Insbesondere möchte ich jetzt auch mal über Kickstart-Automatisierung reden. Prinzipiell ist es so, wenn ich ein System kickstarte, dann brauche ich eine Kickstart-Distribution

und ein Profil. Warum? Die Kickstart-Distribution ist letztendlich nur eine sehr minimalistische Boot-Umgebung. Das heißt, da habe ich meine Init-RAM drin, da habe ich meinen Kernel drin, da habe ich ein kleines Image drin, wo eben mein CentOS Red Hat, was auch immer drin ist und das Installationsprogramm. Und die anderen, die befinden sich in aller Regel entweder

auf dem Netzwerk mehr oder irgendwo oder auf der DVD, wenn ich den eine habe. Und damit das überhaupt funktioniert, brauche ich ein Kickstart-Profil, das startet mir diese Distribution, also dieses minimale Image und startet dann auch irgendwann die Installation. Das ist halt viel manuelle Arbeit, die man sich in irgendeiner Art und Weise sparen kann, meiner Meinung nach.

Deswegen habe ich da ein kleines Python-Skript programmiert, das da heißt mke-lfs. Das ist ein kleines Tool, das lädt eben die ganzen Dateien, die ich dafür brauche, um das System zu provisionieren, vom Netzwerk mehr oder automatisch runter. Und legt auch automatisch im Spacewalk oder Setlight, wenn ich das denn möchte, eine Kickstart-Distribution

an, sodass ich dann letztendlich nur, wenn ich das gemacht habe, mein Profil anlegen muss und anfange zu definieren, der Server, der jetzt bootet, der muss einen Apache haben, der muss so und so heißen und so. Automatisiert hier an der Stelle einiges. Unterstützt wird aktuell CentOS, Scientific Linux und Fedora. Und wer das sich mal angucken möchte, das gibt es auf

GitHub, kann man da eben runterladen, gibt eine kleine Dokumentation dazu, auch ein kleines Beispiel auf YouTube, wie man das Tool, den man auch wirklich verwendet. Und um mal ein Beispiel zu zeigen, hier zum Beispiel wird ein CentOS 6.5 64-bit heruntergeladen und auch automatisch eine Kickstart-Distribution erstellt.

Ich hätte jetzt vorher die DVD runterladen müssen, die Dateien extrahieren oder kopieren müssen, und hier gebe ich einen Befehl ein, gehe einen Kaffee trinken und es ist fertig. Die Dateien werden dann übrigens unter var-settler-kickstart gespeichert. Und vielleicht noch ein anderes Beispiel, Scientific Linux 6.2,

also eine etwas ältere Version, 32-bit und keine Kickstart-Distribution, also hier werden nur die Dateien runtergeladen. Vorhandene Dateien werden überschrieben, das ist hier dieses F für Force und keine Ausgabe minus Q. Also es gibt auch Lang- und Kurzoptionen und mit minus H wird man dann mit Informationen überhäuft, wie man das denn

verwenden kann. Gut, dann zum nächsten Thema, Aufräumen. Prinzipiell ist es so, dass jede Aufgabe, die ich über Spacewalk, Satellite oder Social Manager eben ausführe, wird als Aktion dokumentiert, sodass ich genau sehen kann, was habe ich wann, warum gemacht und hat es auch funktioniert. Auch automatisierte Aufgaben gehören dazu.

Das heißt, nachts wird zum Beispiel immer mal geguckt, ob alle Systeme die neuesten Konfigurationsdateien drin haben. Und oftmals sind es Informationen, die mich eigentlich gar nicht interessieren. Also ich muss nicht unbedingt wissen, was war vor zwei Jahren nachts um 3 Uhr am 21.07. Und oftmals wird eben einfach vergessen, hier aufzuräumen.

Hier zum Beispiel, eins meiner Testsysteme, das habe ich nach einem Jahr mal reingeguckt und hatte da auf einmal, ja, 240.000 Einträge. Und ich habe mich vorher gewundert, warum die Datenbank so langsam war. Nachdem ich da reingeguckt habe, wusste ich, warum sie so langsam war. Die war einfach nur riesig, weil viele Informationen drin standen, die ich einfach nicht gebraucht habe.

Auch hier habe ich ein Tool programmiert, das nennt sich ASA. Und das archiviert und löst einfach nur Spacewalk-Aktionen. Und das lasse ich einfach mal einmal als Grundjob in der Woche laufen, weil entweder ich habe ein Problem, das ich innerhalb von der Woche erkenne und löse, oder es ist einfach nicht relevant für mich. Und dann wird einmal in der Woche eben das ausgeführt und alle Aktionen

werden archiviert und dann gelöscht. Auch das gibt es auf GitHub mit ein paar Beispielen, die ich auch ein paar jetzt zeigen möchte. Zum Beispiel ASA.py-L. Das listet mir einfach nur auf, was für Aktionen gibt es denn, die ich jetzt lösen könnte, also so eine Art Dry-Run, was sehr viele Unix-Commandos auch haben.

Anderes Beispiel, ASA-RF. Das löst alle abgeschlossen und auch alle fehlerhaften Aktionen. Also ich kann zum Beispiel auch fehlerhafte Aktionen auslassen, wenn ich nur alles, was fehlerfrei durchgelaufen ist, weglöschen will, aber das was nicht funktioniert hat, lasse ich das F einfach weg. Und das lasse ich jetzt zum Beispiel einmal in der Woche ausführen und habe dann alles archiviert, was für

mich unrelevant ist. Patch Reporting ist noch ein interessantes Thema, auf das ich eingehen möchte. Sehr oftmals so, dass das Management erwartet, dass man für die Systeme, die man betreut, detaillierte Patch Reports hat. Denkmal hat auch der eine oder andere schon gehört, was hast du denn am Wochenende gemacht, warum und wieso und

das ist also eine häufige Anfrage und je nach Zertifizierung des Unternehmens ist es auch unabdingbar. So ein schönes Schlagwort an der Stelle ist ja ISO 27001. Arbeitet einer von euch im Unternehmen, das ISO 27001 zertifiziert ist? Leidiges Thema, oder? Ja. Also da wird zum Beispiel einfach vom TÜV gefordert,

dass es eine Liste gibt, wo eben drin steht, System A wurde an dem Tag um die und die Uhrzeit gepatcht. Wir haben das und das gepatcht. Warum haben wir das gepatcht? Weil es ein Bugfix war. Hat das funktioniert? Ja, wir haben vorher einen Test gemacht, wir haben nachher einen Test gemacht. Und das ist je nach Systemleitschaft ein immens hoher Aufwand. Also ich habe jetzt nicht so eine

große Landschaft, ich betreue so ca. 60 Systeme, aber da war trotzdem der Montag, der ging komplett für Dokumentation drauf. Und wenn ich jetzt ein Rechenzentrum habe mit mehreren Tausend Systemen, dann ist das ein unvorstellbar hoher Aufwand. Und mein Gedanke war, das muss man doch irgendwie automatisieren können.

Und hier habe ich auch ein kleines Tool programmiert, das ich eben Satprep nennt, steht an der Stelle für Satellite Patch Reporting. Und das ist einfach ein Toolkit, das diese Patch Reports automatisiert für mich erstellt, sodass ich da eigentlich nichts mehr machen muss. Die Reports werden mittels TeX als PDF-Datei

generiert. Und ich kann da eben patchrelevante Informationen und allgemeine Systeminformationen mit einbauen. Auch das gibt es auf GitHub zum Runterladen. Kann einer von euch gut Python programmieren? Ich habe gerade erst angefangen mit diesem Thema und

das funktioniert jetzt aber. Der Quellcode, der sieht vermutlich sehr, sehr schlecht aus. Also wenn mir da einer unter die Arme greifen möchte, das so richtig schön cool umzusetzen, da kann man noch sehr viel optimieren, glaube ich. Vielleicht mal ein Beispiel. Wie sieht sowas aus? Das ist jetzt eine Vorlage, die habe ich erstellt. Die verwenden wir auch so

in dem Unternehmen, für das ich tätig bin, nur mit dem anderen Logo eben. Das ist eine Vorlage, die haben wir in Zusammenarbeit mit dem TÜV erstellt. Und hier sehe ich eben auch allgemeine Informationen. Zum Beispiel, wie ist die IP von dem System? Wem gehört das System? Also wer ist quasi der Verantwortliche? Wann habe ich das System

gepatcht? Und auch so Dinge wie, ist es ein Standalone-System? Ist es jetzt ein Cluster-System? Habe ich was an der Hardware gemacht? Oder habe ich nur das OS oder die Anwendung aktualisiert? Das sind alles Informationen, die eben vom TÜV aufgrund der Zertifizierung gefragt waren. Und was die auch unheimlich

gerne sehen wollten, war so eine Checkliste. Also zum Beispiel habe ich die Hardware gecheckt, habe ich einen Snapshot erstellt, habe ich das Monitoring ausgeschaltet, bevor ich meine Aufgaben durchgeführt habe. Habe ich jetzt das System neu gestartet, läuft die Anwendung wieder, geht Backup und so weiter und so weiter. Da habe ich mir noch ein paar Funktionen

eingebaut. Dieses Tool verwendet quasi noch Metainformation, um das schon vorzuselektieren. Also man sieht hier, dass hier zum Beispiel schon eingetragen wurde, dass dieses System, dass da die Hardware nicht geprüft wurde, weil es kein physisches System ist. Weil von der VM kann ich keine Hardware testen, weil es keine physische Hardware gibt. Also da wird zum Beispiel abgefragt,

ist es eine VM? Ja, nein. Wenn es keine VM ist, dann nimmt er den Haken nicht rein. Wenn es eine VM ist, dann setzt er mir automatisch, es ist kein physischer Host. Worauf ich auch ganz stolz bin, ist, dass in den Errater geguckt wird, was wurde denn geändert. Und für RPM-Pakete gibt es ein tolles Flag, das eben definiert, dieser Patch braucht einen Reboot. Kernupdate zum Beispiel.

Ich kann keinen Kern updaten, ohne dass ich die oftmals freimache. Und dann muss ich einen Reboot machen. Erst dann habe ich den neuen Kern mit allen neuen Modulen drin. Und in aller Regel wird dieses Flag gesetzt. Und wenn ich jetzt einen Kern update, dann würde er hier den Haken nicht setzen. Wenn jetzt aber kein Kernpatch dabei ist, dann schreibt er mir voll automatisiert rein,

dass ich das System nicht gebootet habe, weil es einfach nicht notwendig war. Also ich muss mir nicht die Arbeit machen, diesen Haken zu setzen. Das macht das Tool für mich. Dann kann ich noch weitere Informationen setzen. Zum Beispiel kann ich definieren, dass ein System nicht im Monitoring ist, weil es ein Testsystem ist. Ist jetzt hier nicht gemacht. Wäre das jetzt ein Testsystem, würde er jetzt hier einen Haken beinein setzen und würde sagen,

ich habe das Monitoring nicht aktiviert, weil es keinen Monitoring gibt. Da brauche ich den Haken nicht setzen. Das macht das Tool für mich. Und letztendlich schreibt er mir unten eine Liste der Patches, die installiert wurden. Und schreibt mir auch rein, was für eine Art von Patch oder Errater das jetzt war. Hier zum Beispiel geht es um Feature Enhancement, also ein sogenanntes Product Enhancement

Advisory, so nennt Red Hat das. Dann habe ich hier den Namen, das Datum und was eigentlich installiert wurde. Also hier wurde zum Beispiel einfach nur die Timezone-Informationen hier aktualisiert. Und da brauche ich natürlich kein Reboot für. Also er guckt pro Paket, ist ein Flag gesetzt, dass ich einen Reboot machen muss. Wenn nicht, schreibe da hier einen Nein rein.

Aber wie verwende ich das eigentlich wirklich sinnhaftig? Also bevor ich meine Walungsarbeiten mache, erstelle ich mir einen Snapshot. Da gibt es ein Tool, das eben Sat-Rep-Snapshot heißt und der geht pro System in dem Satelliteserver durch und guckt, welche Patches gibt es für das System. Schreibe das in eine CSV rein. Dann mache ich meine eigentlichen Walungsarbeiten,

das heißt, ich patch die Systeme, ich reboote die, gucke, ob die Anwendung wieder läuft. Und wenn ich das alles gemacht habe, mache ich nochmal einen Snapshot. Und dann habe ich ja einen Vorher-Nachher-Zustand. Weil ich eben zwei Zustände habe in CSV-Dateien. Und hier greift ein weiteres Skript, das eben heißt Sat-Rep-Diff.

Dem übergebe ich die beiden CSV-Reports als Parameter. Und dann berechnet der ein Delta. Und anhand dieser Delta-Information erstellt er dann eben auch pro System die PDF-Reports. Und wenn ich das alles gemacht habe, brauche ich das nur unterschreiben und mich freuen, viel Zeit gespart zu haben. Gegenüber einem Tag, den ich vorher gebraucht habe, brauche ich da so

fünf Minuten. Und wie vorhin schon erwähnt, gibt es ja Meta-Information. Das ist das, was ich exemplarisch gezeigt hatte. Ist es ein Testsystem, ist es ein Monitoring. Das funktioniert über sogenannte System-Infoschlüssel. Das muss man sich vorstellen, das ist wie eine Variable, die ich pro System im Satelliteserver definieren kann. Und hier sind einfach ein paar Beispiele.

Das sind Variablen, die werten diesen Skript aus. Zum Beispiel System-Owner ist dann der Systembesitzer. System-Cluster ist ein Hinweis auf ein Cluster-System. System-Monitoring, da kann ich eine Null reinschreiben, wenn es nicht ein Monitoring ist. Und so weiter, und so weiter. Das sind nur ein paar Beispiele. Auf der GitHub-Seite gibt es eine vollständige Dokumentation mit weiteren Beispielen und mit allen Variablen.

Gut, so viel zu Sattprep. Die Reports kann ich natürlich auch individualisieren. Das heißt, ich kann zum Beispiel einen Report im Querstand, im Hochformat machen. Ich kann das Logo vom Unternehmen einfügen, also auch so ein bisschen Corporate Identity so implementieren.

Ich kann einzelne Informationen weglassen, kann sie hinzufügen. Wenn ich jetzt zum Beispiel nicht wissen will, ob es jetzt ein Feature-Enhancement oder ein Buckfix war, dann nehme ich die Spalte raus und dann ist die in dem Report einfach nicht zu sehen. Und letztendlich ist das ja auch nur irgendwie eine TeX-Vorlage, die da verwendet wird. Das heißt, wenn ich die nochmal anpassen will, andere Schriftarten, gibt es ein Template,

einfach den Quellcode öffnen, Variable ändern und dann sieht der Report aus, so wie ich ihn gerne hätte. Soweit Fragen dazu? Zum Abschluss noch ein paar Informationen. Ganz wichtig finde ich ja das Wiki von Spacewalk. Da gibt es sehr viele Detailinformationen und

Tipps und Tricks, wie man eben Spacewalk verwendet. Wenn man CentOS oder Fedora verwaltet, unbedingt mal CEFS angucken. Da gibt es wie gesagt für CentOS und Apple gibt es die ganzen Rata-Informationen. Wer sich jetzt mehr im Detail für Solaris mit Spacewalk

interessiert, gibt es im Offizieren Red Hat Blog. Da habe ich einen Gastartikel schreiben dürfen. Da gehe ich im Detail nochmal drauf ein, wie man das installiert, wie man es konfiguriert und wie das auch funktioniert. Und aktuell bin ich auch gerade dabei für das freies Magazin einer Spacewalk Artikel-Serie zu verfassen. Jetzt gerade letzten oder diesen Monat ist der erste Teil erschienen.

Nächsten Monat kommt der nächste. Da geht es auch nochmal um ein paar exemplarische Beispiele, wie ich jetzt meine Systeme dort reinbringe, wie ich installiere. Da wird es dann auch in einem Teil um Solaris gehen, wer das verwendet. Einfach mal reinschauen. Vielleicht hilft es einem oder anderen. Und last but not least bedanke ich mich ganz herzlich für die Aufmerksamkeit.

Freut mich sehr, dass auch so viele Leute gekommen sind. Wer mit mir in irgendeiner Art und Weise in Kontakt bleiben möchte, über Twitter bin ich da ganz gut zu erreichen und wer sich mehr für Enterprise Linux und Spacewalk interessiert, vielleicht noch mal einen kleinen Blick auf meinen Blog werfen, da schreibe ich relativ häufig über irgendwelche Dinge, die mir passieren und wie ich sie löse. Einfach mal reingucken. Gut, noch weitere

Fragen zu dem Thema? Ja, bitte? Die Frage war, ob Open Source sich auch mit Kickstarter installieren lässt. Ich habe kürzlich erst angefangen, mir das anzuschauen. Das Problem ist, bei dem Skript, das ich habe,

da habe ich die Ordnerstruktur von Enterprise Linux, also von CentOS eigentlich nur eins zu eins abgebildet und das funktioniert halt auch mit Oracle Linux, CentOS, mit Certific Linux und bei Open Source ist es nicht ganz so einfach, weil da habe ich jetzt auf dem Network MIROS noch keine Init-Rams

und das ganze CoreOS gefunden. Aber prinzipiell, das ist, glaube ich, auch auf GitHub einer der Issues, den ich reingeschrieben habe, dass auch Open Source man da mit kickstarten können sollte. Also prinzipiell geht das wohl, ich habe auch mal eine Anleitung gefunden, aber ich habe es jetzt noch nicht sinnvoll eben in MKRFS mit reinbekommen. Das steht aber auf der Agenda. Weitere

Fragen? Ja, bitte? Alles läuft mir gut. Ich muss sagen, ich glaube, dass wir dieselben

Updates auch in Produktion einspielen, die ich bereits im Test eingespielt habe, oder die bei der Traktor- und Verstauung-Atmosphäre, oder kann ich selektieren, dass ich in aktuellen Zeitpunkten, wie ich jetzt auf Test fahre, an Softwarepaketen, auch genauso auf Oracle

Also die Frage war jetzt, wenn ich jetzt ein paar Patches auf Test oder Entwicklung teste, wie kann ich sicherstellen, dass ich exakt dieselben Patch-Versionen auch dann auf der Produktion ausrolle? Also prinzipiell ist das nicht ganz so schön gelöst, weil da muss ich mir eben die Erater-Versionen genau angucken. Das heißt, ich teste jetzt Erater 2014

Doppelpunkt 0702 und dann muss ich auch darauf achten, dass ich genau diese Versionen auch dann auf Entwicklung dann auf Broad teste. Da könnte ich vielleicht Action-Chaining nehmen, indem ich genau diese Version auswähle und mir daraus eine Chain baue, die eben dann nur auf der Gruppe, mit Hilfe des System Set Managers zum Beispiel

Entwicklungen ausführe. Und wenn das funktioniert, eben dann auf Test und dann auf Produktion. Aber jetzt, mir ist jetzt kein schönerer Mechanismus bekannt, dass man sagt, ich habe jetzt eine Gruppe stand sowieso, das teste ich erst da und dann da, da ist mir jetzt kein Mechanismus bekannt. Das soll aber dann mit dem Vor- oder mit der neueren Major-Version dann passieren. Also ich weiß nicht,

ob jemand von euch schon was von Spacewalk 6 Beta gehört hat. Also die Software, die hier verwendet wird, die ist ja schon relativ alt. Also seit 2002 ist es eigentlich so die selbe Architektur, die verwendet wird. Und Red Hat entwickelt gerade eine komplett neue Major-Version, die auch kein Update in dem Sinne ist.

sondern wirklich eine Reprogrammierung und da gibt es dann zum Beispiel auch Baseline-Gruppen, wo ich sagen kann, ich habe jetzt einen Snapshot, stand sowieso mit denen den Patches, den teste ich da und dann kann ich diesen Content View, so wird das glaube ich genannt, wenn ich die Doku richtig verstanden habe, auf der nächsten Grube ausrollen. Das ist nämlich auch einer der Punkte, der mir aktuell leider nicht ganz so gut gefällt.

Bitte schön. Es gibt ja einen pragmatischen Weg, man könnte ja einfach die App plötzlich mehr runterladen. Man hat ja Channel, die aktualisiert werden jeden Nacht mal im Leben, und wenn ich einfach meinen Patch-Zyklus anfange, setze ich diesen Aktualisierungs-Algorithm einfach aus. Eine zweite Möglichkeit ist, man kann es bei Red Dead selber kaufen,

dass ein Channel-Freeze gemacht wird. Genau. Dann haben die aber die Tests richtig. Der Hinweis an der Stelle war jetzt gerade, dass man das ja auch ganz pragmatisch lösen kann, wenn man zum Beispiel diesen Cron-Shop hat, der jede Nacht die App jetzt runterlädt und ich weiß, ich habe jetzt einen definierten Zustand, den ich erstmal ausgiebig evaluieren möchte,

dass ich einfach diesen Cron-Shop aussetze. Das geht natürlich auch. Oder, was auch eben gerade erwähnt wurde, gegen extra Bezahlung bietet Red Dead das auch für einzelne Minor-Releases an. Also zum Beispiel für 6.3 gibt es irgendwie so ein Sonder-Agreement, dass man nur für dieses Minor-Release die Patches hat. Aber ich würde dann glaube ich auch eher den pragmatischen Ansatz wählen

und einfach diesen Job mal ausplanen. Genau. Das ist dann gewolltes Restrisiko des Administrators. Gut, okay. Noch weitere Fragen? Ja.

Die Frage war, ob sich das Configuration Management nur auf Dateien beschränkt. Also prinzipiell ist es natürlich primär für Configuration Files gedacht. Aber was ich auch machen kann, ist, ich kann symbolische Links auch erstellen und ich kann auch Binär-Dateien hochladen. Würde ich jetzt nicht unbedingt machen?

Ich habe mir die Frage auch gestellt, weil wir zum Beispiel bei uns in der Company auch einzelne RPM-Pakete haben, die ich dann eben zentral verwalten wollte oder einzelne Files hatten. Und ich habe den Ansatz gewählt, das nicht in die Datenbank zu integrieren, weil die Datenbank dann wohl von der Größe her wieder explodiert wäre. Ich habe das einfach in RPM-Pakete paketiert

und habe dann die RPM-Pakete eben Eigen-Challeng gebaut und in die Dateien rein. Aber prinzipiell geht es. Ich muss zugeben, ich habe es noch nicht produktiv verwendet und würde es auch nicht machen, weil RPM-Datei erstellen ist meiner Meinung nach der schönere Weg. Da kann ich dann auch zum Beispiel einzelne Errater für meine einzelnen Pakete erstellen.

Die Frage war, wie sich das im Backend darstellt, wenn jetzt Dateien, symbolische Links oder Binär-Files hochgeladen werden. Im Detail weiß ich es nicht genau, aber ich bin der Meinung,

dass das wirklich in der Datenbank landet. Also ich habe mal den Test gemacht, habe mal die Größe von der Datenbank mir auf dem Filesystem anzeigen lassen, als ich das System frisch installiert hatte. Ich hatte dann meine Konfiguration und ein paar symbolische Links reingepackt und dann ist die Größe angestiegen. Also ich gehe wirklich davon aus, dass das 1 zu 1 in der Datenbank auch gespeichert wird. Also ich konnte jetzt auch im Filesystem nirgends eine Datei finden,

die genau den Inhalt hatte, den ich vorher eingegeben hatte. Deswegen auch der Hinweis an Binär-Dateien am besten, weil Binär-Dateien können ja größer werden, je nachdem wie viele man hat, dass man das nicht in die Datenbank mit reinpumpt, sondern RPM-Pakete bauen, weil die landen dann wirklich im Filesystem. Ich habe dann unter bar.rhn, habe ich meine ganzen RPMs in einem sehr kryptischen Format, aber da sind die RPMs.

Also die sind nicht in der Datenbank, das sind nur Hinweise in der Datenbank, wo die auf dem Filesystem liegen. Okay, noch weitere Fragen? Die Frage war, wo die Folien nachher landen. Also ich werde die auch über das Frostcon-Portal zur Verfügung stellen,

werde gleich noch auf Twitter ein paar Links auf dem Blog rumschicken und kann man dann eben auf dem Blog oder auf der Frostcon-Seite runterladen. Die Folien gibt es übrigens dann auch nochmal auf Englisch, also ich habe die auch eins zu eins komplett übersetzt. Wenn da Interesse besteht, gibt es auch englische Slides.

Okay, vielen Dank für die Aufmerksamkeit.