Programm Freitag

Bei aller Virtualisierung ist dennoch auch bei jedem Cloud-Stack irgendwann anfassbare Hardware involviert. Um OpenStack auf Bare Metal zu installieren sind daher einige unbequeme Herausfoderungen zu miestern, da Hardware manchmal die physische Anwesenheit zu erfordern scheint.

Dieser Vortrag widmet sich den drei wichtigsten Aspekten des Bare-Metal-Deployments, nämlich dem Booten aus der Entffernung, der Überwachung der Abläufe, insbesondere, wenn etwas schief läuft und zuletzt die Post-Boot-Orchestrierung. Der Vortrag stellt dazu die verfügbaren kommerziellen und freien Werkzeuge vor. Nach der Session verstehen Teilnehmer die Anforderungen und Fallstricke des Deployments und sind in der Lage geeignete Werkzeuge für ihren eigenen Einsatzzweck auszuwählen.

Beschreibung folgt.

Das Mailprogramm Mutt existiert seit 1996 - und seit 2016 gibt es eine neue Version: NeoMutt. Der Mutt bedeutet Mischlingshund. Die E-Mail-Software integriert die Eigenschaften von den Mailern jener Zeit. Sie wurde damals vor allem geschaffen, um Digitale Signaturen und Verschlüsselung nach OpenPGP zu integrieren.

Seit 1996 gab es einige Patches, die in unterschiedlicher Kombination bei den Betriebssystemen mitgeführt wurden. Auch NeoMutt wurde als Patch Set begonnen (so wie mutt-ng), aber die viele Änderungen machen es nun zu einem Fork. Das Hauptmerkmal von NeoMutt ist wohl aber, dass der Code und die Dokumentation aufgeräumt wurden und somit die Entwicklung nun wesentlich besser und schneller vorangehen kann. NeoMutt plant, alle weiteren Änderungen von Mutt mit einbeziehen.

Bisher gibt es mehr als 30 wesentliche Änderungen, von denen der Vortrag einige bisherigen und zukünftigen Benutzern vorstellt, die eine schnelle und kryptographische sichere Alternative zu Webmailern und Outlook suchen. Schwerpunkt sind dabei das Einrichten, der Pager, Darstellung von Header und Body, das Kryptographiesubsystem, Folder, Tags, Anhänge und Signaturen. Konfigurationen zur Anbindung an IMAP, LMDB, NNTP und TLS-NSI kommen ebenso vor.

Kubernetes als Plattform für Microservices sowie ähnliche und skalierbare Anwendungen hat sich etabliert. Erfreulicherweise gibt es jede Menge Anleitungen, Tutorials und Dokumentation, wie so eine Plattform aufzubauen ist.

Dennoch ist das kein triviales Unterfangen, da eine ganze Reihe von Teilkomponenten zu installieren und zu konfigurieren ist. Daher gibt es bisweilen die Qual der Wahl. Dieser Vortrag stellt die wesentlichen Ansätze vor und berichtet von eigenen Erfahrungen, um auf OpenStack eine produktive Kubernetes-Umgebung aufzubauen.

Die Hürde, ein Shellscript zu schreiben ist denkbar gering: Aus der Kommandozeilen-Historie ein Skript zu machen ist schon der einfachste Weg zur vermeintlichen Automatisierung. Die Gefahr lauert jedoch im Kontext: Lassen sich Skripte auch in anderen Umgebungen ausführen? Was ist mit anderen Dateinamen oder beim Start aus anderen Verzeichnissen?

Dieser Vortrag ist eine Sammlung aus Best Practices, die beim Schreiben portabler und robuster Skripte hilft. Zur Sprache kommen:

• Dateinamen mit Leerzeichen oder: Über den Zweck von Doublequotes
  
• Schützen von Variablen oder: Was die geschweiften Klammern sollen
  * Useless use of cat und seine Verwandten
  * Wieso Umgebungsvariablen nicht immer eine gute Idee sind
  * Der Ärger mit Terminals und dem "read"-Builtin
  * Parsen von Kommandozeilenargumenten
  * Einrückungen und Semikolons bei "for", "if" und "while"
  * Gibt es eigentlich auch ein Lint für Shellskripte?
  

OpenStack hat als Software-Projekt den Anspruch, als Basis für eine Public Cloud zu dienen. Technisch trifft das zu: Man kann User verwalten, die User können VMs starten etc. Doch mit welchen Fragen ist man konfrontiert, wenn man wirklich eine Public Cloud betreibt? Wir wollen in diesem Talk darüber reden, welchen Herausforderungen (technischen und menschlichen) wir begenet sind. Es geht darum, wie man eine Cloud kontinuierlich mit (Sicherheits-) Updates versorgt, wie eine Produktionsplattform kontinuierlich weiterentwickelt wird und im Kern um eines: Wie macht man dabei eine produktive Public Cloud nicht kaputt?

Wir haben uns entschieden, die Maintenance unserer Plattform radikal zu automatisieren. Updates und Reboots der Cloud laufen bei uns maschinengesteuert, ohne dass ein Mensch diesen Vorgang kontrolliert. Altgediente Operations-Menschen haben dabei gelernt, dass Maschinen viel mehr Zustände gleichzeitig im Blick haben können und deshalb oft akkurater arbeiten als Menschen. Entwickler haben dabei gelernt, dass es gesund und erfolgreich funktioniert, wenn sie die Verantwortung für eine Produktionsplattform übernehmen.

Anwender, die wiederkehrende Aufgaben automatisieren möchten, haben dazu viele Optionen. Manchmal sind das zu viele Optionen: Es gibt so viele Skriptsprachen, Werkzeuge und Tools, die sich von der Kommandozeile aufrufen und damit in Skripte übernehmen lassen, dass es leicht ist, von rechten Weg abzukommen. Im Vortrag wird die These diskutiert, dass eine Mehrheit der Anwendungsfälle jedoch nur einen Bruchteil an Werkzeugen wirklich benötigt, weil vieles nämlich in den großen Shells eingebaut ist.

Zu den großen Shells gehören die Kornshell und die Bash. Beide kommen heute mit einem sehr umfangreichen Funktionsumfang, sowohl was Skripte als auch den interaktiven Umgang angeht. Der Beitrag vergleicht die beiden Vertreter, weist auf Gemeinsamkeiten, aber auch auf Unterschiede hin. So manche scheinbar kleine Funktion löst bei dem einen oder der anderen vielleicht einen Aha-Effekt aus, der die Produktivität im Arbeitsalltag drastisch steigern kann.

Eine Abfolge von Beiträgen der Teilnehmer zu aktuellen Themen.

End-to-end Encryption is a game of compromises when paired with a file sync and share solution. Some offer it integrated but that means no web interface (or compromising your security by offering the encryption in the browser). Others require extra tools like GPG with manual and often complicated key handling. Or require you to sent passwords around to be able to share (good luck revoking them). And of course, if you share a file with an additional person, be prepared to re-encrypt the entire file and re-upload it. Fun if that's several gigabytes of data!

Nextcloud designed a client-side end-to-end encryption protocol meant to protect user data from nosy system administrators or a full server security breach while limiting usability as little as possible. Of course, some functionality got lost but we think we struck a pretty decent balance between usefulness and security.

The goal of being easy to use was central because complexity leads to mistakes and mistakes lead to security breaches. We avoided users having to choose (and even remember!) passwords, for example, and don't require passwords for sharing. But it also has to be efficient, not require re-uploading data unless it is changed.

Our end-to-end works on a per-folder level and features an easy to use, server-assisted but fully secure key management with Cryptographic Identity Protection, our method of securely signing and handling user certificates. Users can easily access their data on any of their devices using the clients (not via the web interface) and share with other users, securely. But it also offers an audit log, optional offline admin recovery key and more features.

A first implementation is available in Nextcloud 13 and its clients. We'll go over the design in this talk and take your feedback on it!

Der professionelle Betrieb moderner Software erfordert ausführliches und beständiges Testen. Das bedeutet, dass neben der Softwareentwicklung parallel Tests implementiert werden sollten. Dieser Vortrag befasst sich mit Testing im Kontext der auf OpenStack basierenden Open Telekom Cloud und geht dabei auf die Enstehung, dem Aufbau, der Weiterentwicklung, sowie Nutzung des dazu genutzten Robot Frameworks ein. Anschauliche Beispiele verdeutlichen den Umgang mit dem Framework und zeigen die Herausforderungen, die die Testintegration mit sich bringt.

Management und ein Open-Source-Team - wie geht das zusammen? Worauf muss der Teamleiter hier besonders achten? Was ist anders als in anderen Branchen? Über mehr als zwei Jahrzehnte in der Welt der Freien Software und in der IT hat Markus Feilner verschiedene Führungsansätze erlebt - und mit diesem Vortrag gibt er einen Einblick wie anders Führung in Open-Source-Unternehmen funktionieren muss.

Sehr häufig läßt sich beobachten, wie schlecht traditionelle Führung, Amerikanischer "Corporate Style" ("We are family!") oder die "klassisch-deutsche" Organisationsform in der Open-Source-Welt funktionieren. Als Team Lead bei SUSE hat der Referent gelernt, als API zwischen Managementaufgaben und hochmotivierten Menschen zu vermitteln, deren Visionen in erster Linie
darauf ausgerichtet sind, etwas zu bewegen und "größere" Veränderungen zu schaffen, vielleicht die Welt ein klein wenig besser zu machen und auf dem Weg dorthin großartige Sachen zu produzieren.

Der Vortrag gibt Beispiele, wie eine Führungsperson den Open-Source-Geeks, -Nerds und -Hackern helfen kann, erfolgreich innerhalb eines Teams zu arbeiten, ihren "Job" gerne zu machen und dabei kreativ zu sein. Worauf kommt es an, will man das Gefühl vermitteln, die Arbeit der Mitarbeiter habe Bedeutung über die Firma hinaus, mache eine großen Unterschied und helfe gleichzeitig
Unternehmensziele zu erreichen und das Management zufriedenzustellen.

Der Vortrag wird auch Beispiele geben, wie Teams in unbekanntem Terrain (Wissenschaft, Programmieren, Noosphere) Lösungen finden können, wie sich Konflikte lösen lassen, Motivaton und Inspiration finden lassen und dabei auch der Spaß nicht zu kurz kommt.