Ende 1999 wurde Version 1.0 der Software FAI (Fully Automatic Installation) veröffentlicht. 10 Jahre später wird das Projekt immer noch aktiv weiterentwickelt und hat sich einen festen Platz in der Systemadministration geschaffen.
FAI begann als automatisierter Netzwerkinstaller für Debian, der schon von Anfang an ein eigenes Klassenkonzept beinhaltete. Mit den Jahren sind viele Erweiterungen eingeflossen, sodass FAI mittlerweile auch das ganze Konfigurationsmanagement übernehmen kann und nicht mehr auf eine bestimmte Linux Distribution festgelegt ist. Ebenso können neben realer Hardware auch virtuelle Rechner installiert und konfiguriert werden und unterschiedliche Installationsmedien genutzt werden.
Der Vortrag gibt einen kurzen Rückblick auf 10 Jahre Entwicklung des Projekts und zeigt die neuesten Features der aktuellen FAI Version 3.3.3.
OSDC 2011 | FAI - Fully Automatic Installation by Thomas LangeNETWAYS
FAI (Fully Automatic Installation) ist eine Software zur automatischen Installation von Rechnern ohne jeglichen Benutzereingriff. Dadurch lassen sich bei der initialen Installation von einzelnen Rechnern, ganzen Rechnerpools oder größeren Clusterinstalltionen viel Zeit einsparen. Zusätzlich bietet diese Vorgehensweise eine höhere Qualität, da sich keine manuellen Fehler einschleichen können oder Rechner nach einem Ausfall schneller wiederhergestellt werden können.
FAI begann als automatisierter Netzwerkinstaller für Debian, der schon von Anfang an ein eigenes Klassenkonzept beinhaltete. Durch die konstanten Weiterentwicklung sind mit den Jahren viele Erweiterungen in das Projekt eingeflossen, sodass FAI mittlerweile auch das komplette Konfigurationsmanagement übernehmen kann. Ebenso ist FAI inzwischen nicht mehr auf Debian festgelegt, sondern kann auch andere Linux Ditsributionen wie SUSE, RedHat, CentOS und sogar Solaris installieren. Neben echter, physikalischer Hardware, können natürlich auch virtuelle Systeme installiert und konfiguriert werden.
Der Vortrag gibt einen kurzen Überblick zum Projekt und zeigt die neuesten Features der aktuellen FAI Version.
Open Source DMS / ECM agorum core das freie Dokumentenmanagement System und Enterprise Content Management System mit Workflow und Archivieren-Funktion.
Nagios Conference 2006 | NagiosOnCD – eine linux-basierte Live-CD mit Nagios ...NETWAYS
NagiosOnCD ist eine Linux-Live-CD, basierend auf Debian/Sarge, die eine komplette Nagios-Installation einschließlich der Standard-Plugins enthält. Mit dem Stackable Filesystem Unionfs überlagert NagiosOnCD die nicht veränderbare CDROM mit schreibbaren Filesystemen. So ist es möglich, Konfiguration, Nagios-Datenbank und Logdateien trotz des CDROM-Prinzips permanent zu speichern.
Ursprünglich wurde NagiosOnCD für den Einsatz in verteilten Nagios-Systemen als dezentraler Nagios-Sensor entwickelt: ein standardisiertes System, das Betriebssystem und Software streng von der eigentlichen Konfiguration trennt. Die Konfiguration kann zentral erstellt und gepflegt werden. Verteilt man die Konfiguration per Diskette, lässt sich Nagios vor Ort ohne Linux- und Nagios-Kenntnisse in Betrieb nehmen, solange dort jemand in der Lage ist, einen Standard-PC von CDROM zu booten.
NagiosOnCD deckt aber insbesondere in Kombination mit VMware auch viele andere Anwendungsfälle ab, bei denen eine standardisierte Installation oder ein leichter Zugang zu Nagios erwünscht ist, ohne gleich perfekte Kenntnisse in Linux mitzubringen. Hierzu zählt auch der Einsatz in Schulungen.
Der Vortrag erklärt Aufbau und Funktionsweise von NagiosOnCD, dabei wird auch auf das Stackable Filesystem Unionfs und dessen Möglichkeiten eingegangen sowie das Build-System zu NagiosOnCD erklärt. An einigen Beispielen werden schließlich unterschiedliche Einsatz- und Konfigurationsmöglichkeiten aufgezeigt.
NagiosOnCD ist OpenSource (GPL) und auf http://www.monitoringexchange.org verfügbar.
OSDC 2011 | FAI - Fully Automatic Installation by Thomas LangeNETWAYS
FAI (Fully Automatic Installation) ist eine Software zur automatischen Installation von Rechnern ohne jeglichen Benutzereingriff. Dadurch lassen sich bei der initialen Installation von einzelnen Rechnern, ganzen Rechnerpools oder größeren Clusterinstalltionen viel Zeit einsparen. Zusätzlich bietet diese Vorgehensweise eine höhere Qualität, da sich keine manuellen Fehler einschleichen können oder Rechner nach einem Ausfall schneller wiederhergestellt werden können.
FAI begann als automatisierter Netzwerkinstaller für Debian, der schon von Anfang an ein eigenes Klassenkonzept beinhaltete. Durch die konstanten Weiterentwicklung sind mit den Jahren viele Erweiterungen in das Projekt eingeflossen, sodass FAI mittlerweile auch das komplette Konfigurationsmanagement übernehmen kann. Ebenso ist FAI inzwischen nicht mehr auf Debian festgelegt, sondern kann auch andere Linux Ditsributionen wie SUSE, RedHat, CentOS und sogar Solaris installieren. Neben echter, physikalischer Hardware, können natürlich auch virtuelle Systeme installiert und konfiguriert werden.
Der Vortrag gibt einen kurzen Überblick zum Projekt und zeigt die neuesten Features der aktuellen FAI Version.
Open Source DMS / ECM agorum core das freie Dokumentenmanagement System und Enterprise Content Management System mit Workflow und Archivieren-Funktion.
Nagios Conference 2006 | NagiosOnCD – eine linux-basierte Live-CD mit Nagios ...NETWAYS
NagiosOnCD ist eine Linux-Live-CD, basierend auf Debian/Sarge, die eine komplette Nagios-Installation einschließlich der Standard-Plugins enthält. Mit dem Stackable Filesystem Unionfs überlagert NagiosOnCD die nicht veränderbare CDROM mit schreibbaren Filesystemen. So ist es möglich, Konfiguration, Nagios-Datenbank und Logdateien trotz des CDROM-Prinzips permanent zu speichern.
Ursprünglich wurde NagiosOnCD für den Einsatz in verteilten Nagios-Systemen als dezentraler Nagios-Sensor entwickelt: ein standardisiertes System, das Betriebssystem und Software streng von der eigentlichen Konfiguration trennt. Die Konfiguration kann zentral erstellt und gepflegt werden. Verteilt man die Konfiguration per Diskette, lässt sich Nagios vor Ort ohne Linux- und Nagios-Kenntnisse in Betrieb nehmen, solange dort jemand in der Lage ist, einen Standard-PC von CDROM zu booten.
NagiosOnCD deckt aber insbesondere in Kombination mit VMware auch viele andere Anwendungsfälle ab, bei denen eine standardisierte Installation oder ein leichter Zugang zu Nagios erwünscht ist, ohne gleich perfekte Kenntnisse in Linux mitzubringen. Hierzu zählt auch der Einsatz in Schulungen.
Der Vortrag erklärt Aufbau und Funktionsweise von NagiosOnCD, dabei wird auch auf das Stackable Filesystem Unionfs und dessen Möglichkeiten eingegangen sowie das Build-System zu NagiosOnCD erklärt. An einigen Beispielen werden schließlich unterschiedliche Einsatz- und Konfigurationsmöglichkeiten aufgezeigt.
NagiosOnCD ist OpenSource (GPL) und auf http://www.monitoringexchange.org verfügbar.
OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...NETWAYS
Dieser Workshop ist in erster Linie für Konferenzteilnehmer gedacht, die sich für Plugin-Programmierung interessieren.
Der Workshop zeigt auf, welche überwachenswerten Daten und Parameter es auf einem NetApp-Filer gibt und wie die Zugänge zu diesen Daten (Telnet, HTTP, SNMP, SSH, XML/Webservices, Data ONTAP APIs) sind. Ingo Lantschner wird eine theoretische Einführung und Demonstration an Hand des NetApp-Simulators präsentieren und mit den Teilnehmern ein Demo-Plugin auf Basis der o.g. Erkenntnisse entwickeln, anschließend erfolgt der Upload des Plugins auf Nagios-Exchange.
Nagios Conference 2007 | Aufbau eines hochverfügbaren Nagios Clusters by Mart...NETWAYS
Nagios auf eine HA Clusterinfrastrukur mit Clusterfilesystem- warum macht man so etwas. Vorteile und Nachteile gegenüber einer Master-/Slave- Konfiguration. Wodurch kann ein solcher Konstrukt erzwungen werden? Was ist beim Aufsetzen zu bedenken? Und was mach ich mit Cronjobs?
Nagios Conference 2007 | Pluginprogrammierung in Perl by Wolfgang BarthNETWAYS
Nicht immer findet sich ein passendes Plugin für die konkrete Aufgabenstellung. Dann ist Eigenbau angesagt. Plugins selbst zu schreiben ist nicht schwer, vorausgesetzt, man hält einige Spielregeln ein.
Dieser Workshop zeigt auf, wie man in Perl Plugins erstellt, die sich an die wichtigsten Spielregeln halten. Die Programmierung erleichtert das Perlmodul
Nagios::Plugin von Ton Voon, dem Maintainer der offiziellen Nagios-Plugins. Neben dem Modul Nagios::Plugin kommt auch das Modul GetOpt::Long für die Zerlegung der Kommandozeile und die Perl-Online-Dokumentation (POD) zur
Sprache. Für die Ausführung von Perl-Plugins liefert Nagios einen integrierten Perl-Interpreter mit (ePN – embedded Perl Nagios), der allerdings besondere Anforderungen an ein Plugin stellt. Der Workshop geht auch auf die nicht immer
einfache Fehlersuche ein, mit der man konfrontiert wird, wenn ein unter normalen Umständen funktionierendes Plugin nicht so recht mit ePN zusammen arbeiten mag.
Aus dem Inhalt:
Standard-Anforderungen an ein Plugin
Rückgabewerte und Textausgaben
Verarbeitung der Kommandozeile
Online-Hilfe und integrierte Manpage
Die Sache mit dem Timeout
Formate für Schwellwerte: Thresholds
Ausgabe von Performancedaten
Konfigurationdateien für ein Plugins verwenden
ePN, der embedded Perl-Interpreter: Anforderungen, Fehlersuche.
Der Workshop richtet sich an Teilnehmer mit Programmierkenntnissen in einer Skriptsprache und zumindest einfachen Perl-Grundkenntnissen. Die Plugin-Erstellung erfolgt unter Linux.
SUSE Linux (Enterprise Server) ist eine populäre Linuxdistribution. Doch wo hört Linux auf und fängt SUSE an ? Im professionellen Umfeld lohnt es sich, die Betriebskonzepte etwas auf SUSE auszurichten um damit die Linuxumgebung effizienter und optimaler zu betreiben. Der Vortrag führt in die speziellen Themen von SUSE Linux ein und zeigt wie man mit SUSE Linux optimal arbeitet und zeigt nützliche Tipps und Handwerkszeug für den professionellen Einsatz von SUSE Linux auf:
Software Management mit Repositories
RPM Pakete für die Administration und eigene Inhalte verwenden
Subscription Management Tool
SuSE Linux unter die Haube geschaut - Wie man YaST nicht benutzt
Netzwerkkonfiguration SuSE-like (ifrename, bonding, bridging ...)
Warum SLES und nicht openSuSE - aus dem wahren Leben berichtet
Wie bekommt man wirklich Support bei SuSE ? Die Nuernberger gibt es noch !
Vortrag auf dem TYPO3 Meetup 3 am 13.11.2017 bei sitegeist
über Docker Umgebungen für TYPO3 zu Präsentationszwecken und als Entwicklungsumgebung mit xdebug.
http://www.opitz-consulting.com/go/3-6-11 --- Softwareentwicklung, -test und -betrieb können durch Virtualisierung viele Vorteile erzielen. In diesem Zusammenhang werden häufig Werkzeuge für die Bereitstellung von Umgebungen eingesetzt. Verschiedene Werkzeuge adressieren aber unterschiedliche Einsatzszenarien. Wo im Applikationslebenszyklus können diese Werkzeuge sinnvoll eingesetzt werden und wie sieht es mit Kosten und Nutzen aus? ---- Unser Senior Software Architect Richard Attermeyer stellte bei der W Jax am 5.11.2014 in München die Tools Vagrant, Puppet und Docker im Einzelnen vor und erläuterte ihren Nutzen anhand von Use Cases und Live Demos. ---- Weitere Infos: https://jax.de/wjax2014/sessions/vagrant-puppet-docker-fuer-entwickler-und-architekten ---- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.---- Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 ---- Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 ---- Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
RPM kommen nur von der Distribution ? Eigentlich ist es ganz einfach, ein RPM Paket zu erstellen. Im Ergebnis unterstützen RPM Pakete die Systemautomatisierung und Standardisierung.
Sinn und Nutzen von Paketierung
RPM Paketen unter die Haube geschaut - technische Details
Best Practice - Erstellung eigener Pakete
Dependency Hell - Wie RPM kaputt geht
openSUSE Build Service - bauen lassen
Paketierung für Maintainer (Unterpakete, Cross-Plattform, Doku ...)
OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...NETWAYS
Dieser Workshop ist in erster Linie für Konferenzteilnehmer gedacht, die sich für Plugin-Programmierung interessieren.
Der Workshop zeigt auf, welche überwachenswerten Daten und Parameter es auf einem NetApp-Filer gibt und wie die Zugänge zu diesen Daten (Telnet, HTTP, SNMP, SSH, XML/Webservices, Data ONTAP APIs) sind. Ingo Lantschner wird eine theoretische Einführung und Demonstration an Hand des NetApp-Simulators präsentieren und mit den Teilnehmern ein Demo-Plugin auf Basis der o.g. Erkenntnisse entwickeln, anschließend erfolgt der Upload des Plugins auf Nagios-Exchange.
Nagios Conference 2007 | Aufbau eines hochverfügbaren Nagios Clusters by Mart...NETWAYS
Nagios auf eine HA Clusterinfrastrukur mit Clusterfilesystem- warum macht man so etwas. Vorteile und Nachteile gegenüber einer Master-/Slave- Konfiguration. Wodurch kann ein solcher Konstrukt erzwungen werden? Was ist beim Aufsetzen zu bedenken? Und was mach ich mit Cronjobs?
Nagios Conference 2007 | Pluginprogrammierung in Perl by Wolfgang BarthNETWAYS
Nicht immer findet sich ein passendes Plugin für die konkrete Aufgabenstellung. Dann ist Eigenbau angesagt. Plugins selbst zu schreiben ist nicht schwer, vorausgesetzt, man hält einige Spielregeln ein.
Dieser Workshop zeigt auf, wie man in Perl Plugins erstellt, die sich an die wichtigsten Spielregeln halten. Die Programmierung erleichtert das Perlmodul
Nagios::Plugin von Ton Voon, dem Maintainer der offiziellen Nagios-Plugins. Neben dem Modul Nagios::Plugin kommt auch das Modul GetOpt::Long für die Zerlegung der Kommandozeile und die Perl-Online-Dokumentation (POD) zur
Sprache. Für die Ausführung von Perl-Plugins liefert Nagios einen integrierten Perl-Interpreter mit (ePN – embedded Perl Nagios), der allerdings besondere Anforderungen an ein Plugin stellt. Der Workshop geht auch auf die nicht immer
einfache Fehlersuche ein, mit der man konfrontiert wird, wenn ein unter normalen Umständen funktionierendes Plugin nicht so recht mit ePN zusammen arbeiten mag.
Aus dem Inhalt:
Standard-Anforderungen an ein Plugin
Rückgabewerte und Textausgaben
Verarbeitung der Kommandozeile
Online-Hilfe und integrierte Manpage
Die Sache mit dem Timeout
Formate für Schwellwerte: Thresholds
Ausgabe von Performancedaten
Konfigurationdateien für ein Plugins verwenden
ePN, der embedded Perl-Interpreter: Anforderungen, Fehlersuche.
Der Workshop richtet sich an Teilnehmer mit Programmierkenntnissen in einer Skriptsprache und zumindest einfachen Perl-Grundkenntnissen. Die Plugin-Erstellung erfolgt unter Linux.
SUSE Linux (Enterprise Server) ist eine populäre Linuxdistribution. Doch wo hört Linux auf und fängt SUSE an ? Im professionellen Umfeld lohnt es sich, die Betriebskonzepte etwas auf SUSE auszurichten um damit die Linuxumgebung effizienter und optimaler zu betreiben. Der Vortrag führt in die speziellen Themen von SUSE Linux ein und zeigt wie man mit SUSE Linux optimal arbeitet und zeigt nützliche Tipps und Handwerkszeug für den professionellen Einsatz von SUSE Linux auf:
Software Management mit Repositories
RPM Pakete für die Administration und eigene Inhalte verwenden
Subscription Management Tool
SuSE Linux unter die Haube geschaut - Wie man YaST nicht benutzt
Netzwerkkonfiguration SuSE-like (ifrename, bonding, bridging ...)
Warum SLES und nicht openSuSE - aus dem wahren Leben berichtet
Wie bekommt man wirklich Support bei SuSE ? Die Nuernberger gibt es noch !
Vortrag auf dem TYPO3 Meetup 3 am 13.11.2017 bei sitegeist
über Docker Umgebungen für TYPO3 zu Präsentationszwecken und als Entwicklungsumgebung mit xdebug.
http://www.opitz-consulting.com/go/3-6-11 --- Softwareentwicklung, -test und -betrieb können durch Virtualisierung viele Vorteile erzielen. In diesem Zusammenhang werden häufig Werkzeuge für die Bereitstellung von Umgebungen eingesetzt. Verschiedene Werkzeuge adressieren aber unterschiedliche Einsatzszenarien. Wo im Applikationslebenszyklus können diese Werkzeuge sinnvoll eingesetzt werden und wie sieht es mit Kosten und Nutzen aus? ---- Unser Senior Software Architect Richard Attermeyer stellte bei der W Jax am 5.11.2014 in München die Tools Vagrant, Puppet und Docker im Einzelnen vor und erläuterte ihren Nutzen anhand von Use Cases und Live Demos. ---- Weitere Infos: https://jax.de/wjax2014/sessions/vagrant-puppet-docker-fuer-entwickler-und-architekten ---- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.---- Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 ---- Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 ---- Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
RPM kommen nur von der Distribution ? Eigentlich ist es ganz einfach, ein RPM Paket zu erstellen. Im Ergebnis unterstützen RPM Pakete die Systemautomatisierung und Standardisierung.
Sinn und Nutzen von Paketierung
RPM Paketen unter die Haube geschaut - technische Details
Best Practice - Erstellung eigener Pakete
Dependency Hell - Wie RPM kaputt geht
openSUSE Build Service - bauen lassen
Paketierung für Maintainer (Unterpakete, Cross-Plattform, Doku ...)
OSMC 2010 | Verwendung von Puppet in verteilten Monitoring Umgebungen by Birg...NETWAYS
Zunehmend werden virtualisierte oder automatisiert aufgesetzte Systeme im Data Center eingesetzt. Beide Varianten eröffnen die Möglichkeit schnell über viele ähnliche Systeme zu Verfügen. Leider fehlt hier oft der Brückenschlag zum Monitoring. Nach dem Bereitstellen der Systeme müssen diese auch kontrolliert ins Monitoring aufgenommen werden.
In komplexen, stark automatisierten Umgebungen kann Puppet nicht nur beim automatischen Configurations- und Change Management, sondern auch bei der Einrichtung des Monitoring ein treuer Gefährte sein. Der Vortrag bietet eine Einführung in die Möglichkeiten des Open Source Tools Puppet und erklärt die Konzepte, welche die Schlagkraft in Verbindung mit Icinga bzw. Nagios ausmachen anhand von Beispielen.
Einführung in Vagrant und wie es als lokale Entwicklungsumgebung verwendet werden kann.
Präsentation von März 2015.
Themen: Vagrant CLI, vagrant share, Provider, Boxes, Provisioning, Netzwerk, Synced Folders, Multi-Maschine Setup, Vergleich mit Docker
Automatisierung? ANSIBLE - Einfach. Sicher. Zuverlässig.
Ansible ist ein Open-Source Werkzeug zur Automatisierung von Deployment-, Konfigurations- und Administrationsprozessen. Die Beschreibung der Aufgaben basiert auf YAML und Jinja Templates. Es lässt sich zudem in Verbindung mit Vagrant und Docker nutzen.
Wer sich mit XPages-Entwicklung beschäftigt, wird über Kurz oder Lang auch auf OpenNTF und die eXtension Library stoßen.
Was ist die eXtension Library und wie kann ich die Erweiterungen in meiner Entwicklungsumgebung nutzen?
Wie können mir die zahlreichen Custom Controls auf OpenNTF helfen, den Entwicklungsaufwand zu reduzieren?
Seit Juli 2011 gibt es die Möglichkeit, aus XPages heraus auf relationale Datenbanken zuzugreifen. Was wird dazu benötigt und wie sieht der Zugriff in der Praxis aus?
Zielgruppe: Teilnehmer mit Grundlagenkenntnissen in der XPages-Entwicklung
Kenntnisse: Grundlagenkenntnisse in der XPages-Entwicklung
Provisionierung von Dockerhosts und -Containern mit Terraform, Ansible und LXD auf Blech und Cloud
Lästige und aufwändige manuelle Serverinstallation kann auf einfache Art durch automatisierte Provisionierung und Konfiguration der Infrastruktur ersetzt werden. Dieser Vortrag zeigt einen Ansatz, bei dem die Definition der Infrastruktur in voll maschinenlesbarer und ausführbarer Form in einem git repo anstatt in den Köpfen der (oder des) Engineers vorhanden sind.
Es wird gezeigt, wie das Verfahren sowohl auf Blech (d.h. auf lokalen physischen Maschinen) als auch in der Cloud angewendet werden kann, und somit eine grosse Übereinstimmung zwischen Test-/Integrations- und Produktionsinfrastruktur erreicht wird.
Die vorgestellten Werkzeuge sind terraform und ansible für Provisionierung und Konfigurationsmanagement, sowie lxd (nur lokal) und docker für System- und Applikationscontainer. Die vollständige Codebasis ist auf github verfügbar, so dass alle TeilnehmerInnen auch sofort mit eigenen Experimenten loslegen können.
Opensource Tools für das Data Center Managementinovex GmbH
Let's talk about Open Source Data Center Management with Foreman, Puppet & docker.io! We invite everyone who's interested to join us at our inovex Meetup in Cologne. This time we will cover the following topics: [01] An introduction to docker.io: Secure and portable containers made easy "Docker is an open-source engine that automates the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere." Learn how docker.io can be a huge benefit for you by bringing operations and development closer together. [02] OSS Data Center Management with The Foreman & Puppet. Have you ever wondered why your IT department needs about 5-10 weeks to have a new project infrastructure up and running? We will discuss the reasons and show you how to fix the issue using our Open Source Data Center Management setup.
OSMC 2016 - Hello Redfish, Goodbye IPMI - The future of Hardware MonitoringNETWAYS
Thomas Niedermeier, Abteilung Communications / Knowledge Transfer bei Thomas-Krenn, absolvierte an der Hochschule Deggendorf sein Studium zum Bachelor Wirtschaftsinformatik. Seit 2013 ist Thomas bei Thomas-Krenn beschäftigt und kümmert sich hier vor allem um das Thomas-Krenn-Wiki, Synology NAS Geräte und um die Weiterentwicklung von TKmon.
OSMC 2016 | Hello Redfish, goodbye IPMI - Die Zukunft des Hardware-MonitoringsNETWAYS
Wir schreiben das Jahr 2016 und der PC-Markt schrumpft weiter. Immer mehr Menschen verwenden mobile Geräte und speichern die meisten ihrer Daten in der Cloud. Dies sind gute Entwicklungen für Server-Hersteller und Datacenter Admins, denn Marktforscher erwarten (damit verbunden) ein dreiprozentiges Wachstum für Investments in Data Center Systeme. Um mit dem Managementaufwand all dieser Cloud Systeme Schritt halten zu können, haben sich IT Profis auf der ganzen Welt zu der DevOps Bewegung zusammengeschlossen und die die Software-Seite der Serverautomation mit Tools wie Puppet, Ansible, Chef oder Salt erheblich vereinfacht. Das ist der Software-Teil... aber was ist mit der Hardware? Hmm..., IPMI (das sogenannte Intelligent Platform Management Interface) ist seit 1998 der Standard für das Out-of-Band Management der Server-Systeme. Es verwendet den UDP Port 623, das Dokument der Spezifikation umfasst mehr als 600 Seiten, es benötigt tiefergehendes Spezialwissen und enthält einige schwerwiegende Sicherheitsrisiken. Um diesen Einschränkungen entgegenzuwirken und das Hardware-System-Management in moderne Zeiten zu katapultieren, wurde von der DMTF (Distributed Management Task Force) der Redfish Management Standard entwickelt und veröffentlicht. Redfish verwendet ein RESTful Interface, funktioniert über HTTPS und stellt alle Daten mittels des JSON Formats unter Zuhilfenahme des ODATA Schemas dar.
Thomas beschreibt in diesem Vortrag die Ziele von Redfish und zeigt auf wie das Monitoring mit Redfish gelingt. Besuchen Sie diesen Vortrag und starten Sie anschließend mit der modernen Art Server-Hardware zu überwachen.
Deployment von Entwicklungsumgebungen eines TYPO3-Intranets mit Vagrant
OSDC 2010 | FAI - ein Projekt wird 10 Jahre alt by Thomas Lange
1. FAI – Ein Projekt wird 10
Jahre alt
Open Source Data Center Conference 2010
Thomas Lange, Universit¨at zu K¨oln
lange@informatik.uni-koeln.de
p.1/51
2. Agenda
Wie alles begann
Wie funktioniert FAI?
Nachteile der Automatisierung
10 Jahre FAI
Erfahrungen mit FAI
p.2/51
3. finger
whoami
Diplominformatiker, Uni Bonn
Systemadministrator an der Uni Köln seit über 18 Jahren
SunOS 4.1.1 auf SPARC, Solaris Jumpstart
Debian Entwickler seit 2000
Vorträge und Tutorials auf zahlreichen Konferenzen:
Linux Kongress, Linuxtag, DebConf, SANE, LCA,
FOSDEM, SUCON, CeBit, FFG
p.3/51
4. Wie alles began
Wir schreiben das Jahr 1999...
Das Jahrhundert in dem man noch per CD installierte
16 Rechner, je zwei Pentium II 400Mhz, 256 MB, 4GB
256 MB RAM, nicht L2 Cache
4GB Festplatte, nicht RAM
Aufgabe: Baue ein Beowulf Cluster und administriere es
Ich bin faul!
Sehr faul!!!
Es gibt keine fertige Lösung :-(
Also programmieren wir etwas Eigenes
p.4/51
5. Man nehme
Zwei Studenten als Hilfe
Debian Linux
Standardtechnik: PXE, TFTP, NFS
Shell und Perl
Ein paar Ideen von Solaris Jumpstart
p.5/51
6. Kochrezept
Einige Monate bei mittlerer Flamme,... = Entwicklungszeit
Achte auf Flexibilität
Garniere mit Klassenkonzept nach Ideen von Casper Dik
Erste Präsentation: Linux Kongress September 1999, Augsburg
Hands-on Tutorial
p.6/51
10. Kinderjahre
21. Dezember 1999: Version 1.0
Tarball
Debian 2.1 (slink)
Kernel 2.0.36
1700 Zeilen Shell und Perl
Davon 900 Zeilen Partionierungstool
Technical Report als Handbuch
Aber es gab einige mutige Benutzer!
p.10/51
11. TODO
TODO list for FAI, december 20, 1999
1. Most people wish that we would support other Linux distributions
(redhat, Suse)
2. Booting a kernel with pcmcia support for automatic installation of
notebooks and laptops
3. Cleanup the code of some perl scripts
4. install/class/S*.{pl,sh} scripts should check and resolve
dependencies
5. Make some change in rcS to run with Debian 2.2 and futher releases
6. class/S*.source: define variabel tftplink which is the name of the
link created in /tftplink. At present it’s always clusterimage
p.11/51
13. Wert eines Computers
Was ist der Wert ihrer Computer?
Was beinhalten ihre Rechner?
Kundendaten
Services
Applikationen
Eigenes Know-How
Was passiert, wenn ihre Rechner einen Tag lang nicht laufen?
Eine gute Computerinfrastruktur ist so wichtig wie ...?
Wie sichern Sie diese Werte?
Ist damit wirklich alles gesichert?
p.13/51
14. Der Crashtest
Wählen Sie zufällig einen Rechner (ohne
Backup vorher)
Werfen sie den Rechner aus dem 10.Stock
(oder dd if=/dev/zero of=/dev/hda)
Stellen Sie alle Arbeit des Sysadmin innerhalb von 10 Minuten
wieder her
Schaffen Sie das? Und ihr Praktikant?
p.14/51
15. Manuelle Installation
Dauert viele Stunden
Viele Fragen
Wiederholende Arbeit ist stupide => Fehler
Dokumentation fehlt, Reproduzierbarkeit?
Jede Installation ist ungewollt einzigartig
Eine Installation per Hand skaliert nicht !
p.15/51
16. Warum voll automatisch?
”No simple sysadmin task is fun more than twice”
Ist schnell
Disaster recovery
Garantiert identische Installationen
Automatische Dokumentation
Spart sehr viel Arbeit (= Zeit = Geld). ROI
Macht mehr Spaß
p.16/51
17. Was ist FAI ?
FAI macht alles, was ihr Systemadministrator zu tun hat, bevor der
Benutzer das erste Mal auf einem neuen Rechner arbeiten kann
Deployment- und Config Management von OS und
Anwendungsprogramme
Skriptgesteuerte vollautomatische Installation
Kein Master Image
Modular durch Klassensystem
Erweiterbar und flexibel durch hooks
Es kann die Installation nicht planen :-(, aber
Plane deine Installation und FAI installiert deinen Plan! :-)
p.17/51
18. Wie funktioniert FAI ?
local
hard disk
provided via HTTP, FTP or NFS
./class
./disk_config
./package_config
./scripts
./files
Debian mirror
mounted by install kernel
NFS, CVS, svn or HTTP
install clientinstall server
./hooks
/target/
/target/var
.../fai/config/
/var
/bin
/usr
/
/target/usr
nfsroot
config space
Die Konfiguration liegt auf dem Install server
Die Installation läuft auf dem Klienten
p.18/51
19. Was braucht FAI?
Installserver mit DHCP, NFS und TFTP
Client bootet via PXE, CD-ROM, USB Stick
Optional: Lokaler Spiegel von Debian (NFS, FTP oder HTTP)
Plattenplatz auf dem Server:
FAI Paket <1 MB Skripte, Konfigurationdateien
nfsroot 380 MB erzeugt mit make-fai-nfsroot
Debian Spiegel <22 GB Debian 5.0 (lenny, nur i386)
Alle Install Clients nutzen die gleichen Verzeichnisse
Konstanter Plattenplatz
p.19/51
20. Ablauf einer Installation I
Plane deine Installation!
Booten via PXE und Kernel mit initrd via TFTP holen
Rechner startet als Diskless Client
Hardwareerkennung und Kernel Module laden
p.20/51
21. Ablauf einer Installation II
Klassen und Variablen definieren
Festplatten partitionieren
Dateisysteme erzeugen und mounten
Software Pakete installieren
Betriebssystem und Anwendungen konfigurieren
Protokolldateien lokal und auf Install Server speichern
Neu installiertes System booten
p.21/51
22. Das Klassenkonzept
Ein Rechner gehört zu mehreren Klassen
Priorität von niedrig nach hoch
Beispiel: DEFAULT FAIBASE GRUB GNOME demohost LAST
Alle Teile der Installation nutzen das Klassenkonzept
Konfiguratitonsdateien werden anhand der Klassennamen
ausgewählt
Erfahrener Admin kreiert die Klassen
Junior Admin ordnet die Klassen den Rechnern zu
PC installiert sich selber
p.22/51
33. Installationszeiten
Host RAM in MB Software in MB Time
Pentium 4 2.6 GHz 512 190 2 min
Pentium 4 2.6 GHz 512 750 7 min
Pentium 4 2.6 GHz 512 2600 15 min
Intel Core2 Duo 2048 3000 14 min
Pentium 4 2.80 GHz 1024 948 5 min
Athlon XP1600+ 896 1000 6 min
AMD-K7, 500MHz 320 780 12 min
PentiumPro 200MHz 128 800 28 min
Knoten Sekunden
1 337
5 340
10 345
20 379
12% mehr Zeit bei 20 Rechnern.
p.33/51
34. Noch ein Beispiel
Top500: 58th in 6/2008, 1340 nodes, 5376 cores, Xeon 2.4 GHz
Max Planck Institute for Gravitational Physics
p.34/51
35. FAI Benutzer
City of Munich, >3000, (14.000 hosts planed)
BUF, digital visual effects company, 1000 hosts
Opera Software, 300 hosts
Spotify, 300 physical, 150 virtual hosts
Albert Einstein Institute, Germany, 800+ hosts
ComBOTS, 700 Blades, 650 Server (16GB RAM, 8TB disk)
Spotify, 300 physical and 150 virtual hosts
Netways, 160 hosts
Host Europe, 250 hosts
HPC2N, 2 clusters listed in top500.org, 192 dual Opteron, 120 dual Athlon
Electricité de France (EDF), France, 200 hosts
MIT Computer science research lab, 200 hosts
Stanford University, 450 hosts
University of New Orleans, 72 node Beowulf cluster
Brown University, Dep. of Computer Science, 300+ hosts
University of West Bohemia, Czech Republic, 180+
Netcologne, MPI Meteorologie, DESY, Genua, taz, thomas-krenn.com, mc-wetter.de
p.35/51
36. Nachteile der Automatisierung
Kann oder soll alles automatisiert werden?
Fehler werden auch verteilt
Weniger aber höher qualifiziertes Personal notwendig
Man muss erstmal Zeit und Arbeit investieren
Bereitschaft für Veränderungen?
Sysadmin wird zum sauberem Arbeiten gezwungen
Manuelle Änderungen an einzelnen Rechner sind verboten!
p.36/51
37. Entwicklung
2000: eigene Mailingliste, erstes Debian Paket
Fork: NAIS
2001: grub support, fcopy, hooks, softupdate, Fragebogen
2003: fai-chboot
2004: DHCP nun default, statt BOOTP
2005: Wiki, IRC, fai-cd
2005: fai-server, fai-client, fai-doc, fai-nfsroot
2006: chroot Umgebung aufsetzen (nutzt GRML seit 2008), ainsl
2007: Kernel mit initramfs, faimond-gui, booten von USB-Stick
2008: setup-storage, Namen in Changelog
2009: fai-guide in asciidoc, Tests, setup-storage Verbesserungen
2010: Beschleunigung durch Ramdisk
p.37/51
46. Dokumentation, Werbung
40 Seiten Handbuch
Über 50 Vorträge, Paper, Artikel
Mehrere Projekte zum Fachinformatiker, Diplomarbeit
Übersetzungen (leider nicht mehr aktuell)
Flyer, Poster
Fast alles auf der Webseite
Messepräsenz
Artikel in aktueller UpTimes
p.46/51
47. Gut gemacht
Früh Vorträge gehalten
Flexibel gehalten und KISS (ASCII Dateien)
Klassensystem
Partitionierungstool
Support für viele Distributionen
FAI Fragebogen
p.47/51
49. Zukunft
Fortschrittsbalken auf dem Client
Automatische Tests
Feste Releasezyklen?
Zielgruppe erweitern?
Konfigurationsmanagement Tool?
System Management? RH Network Satellite? Cobbler?
Logo
p.49/51
50. Fazit
Gute Software entwickeln macht Spaß
Technik ist nicht alles
Planen und Kontinuität mit Freiwilligen ist schwer
Feedback von Firmen sehr mühsam
User Feedback ist wie Applaus
p.50/51