· Ceph Lars Marowsky-Bree (Abbildung 3) arbeitet seit ... Zeitpunkt Ende März) angab, dass...

2017-1

Kernel-Regressions bekämpfen

Druckersicherheit analysieren

Infrastrukturtests automatisieren

UpTimesMitgliederzeitschrift der

German Unix User Group

UPTIMES SOMMER 2017 INHALTSVERZEICHNIS

Inhaltsverzeichnis

Auf ein Neues: Liebe Mitglieder!von Ingo Wichmann und Nils Magnus 3

Real-Life-Forum: Das Frühjahrsfachgespräch 2017von Anika Kehrer 6

Feind in meinem Netz: Firmwareanalyse einesMultifunktionsdruckersvon Yves-Noel Weweler 10

Freiwillige Feuerwehr: Kernel-Regressions bekämpfenübersetzt von Anika Kehrer 17

Ein Gral für DevOps: Infrastrukturtests automatisierenvon Christopher J. Ruwe 21

Shellskripte mit Aha-Effekt VIII: Bash-Arraysvon Jürgen Plate 29

Support vermarkten: Das Thomas-Krenn-Wiki alsBeispiel für Content Marketingvon Anika Kehrer 37

Hilfreiches für alle Beteiligten: Autorenrichtlinien 43

Über die GUUG: German Unix User Group e.V. 46

Impressum 47

UPTIMES – MITGLIEDERZEITSCHRIFT DER GERMAN UNIX USER GROUP E.V. Seite 2

UPTIMES SOMMER 2017 AUF EIN NEUES

Auf ein NeuesLiebe Mitglieder!

Neues Jahr, neuer Vorstand, neue Pläne: Willkommenbei der Sommer-UpTimes 2017.

von Ingo Wichmann und Nils Magnus

Der eine wartet,dass die Zeit sich wandelt.Der andere packt sie kräftig an –und handelt.

Johann Wolfgang von Goethe

Haben nur wir den Eindruck, dass sich unsereTechnikwelt in letzter Zeit einmal wieder etwasschneller dreht? Dass die Informationstechnik einschnelllebiges Geschäft ist, wissen wir alle. Aberin letzter Zeit nimmt sie wieder mächtig Fahrtauf: Konnte man sich vor ein paar Jahren daraufausruhen, dass es dann und wann einen etwasschnelleren Prozessor und mehr Speicher gab, ha-ben sich mit Virtualisierung, Cloud Computing,Containern und Orchestrierungswerkzeugen zwi-schenzeitlich völlig andere Perspektiven auf unse-re Technik ergeben.

Das Tröstliche dabei: Eine Konstante ist seitJahrzehnten dabei und nimmt erfreulicherweisesogar wieder an Bedeutung zu – der Geist von Un-ix. Es macht schon stolz zu sehen, wie ein Satz vonTechniktugenden (modularer Aufbau, Kombinier-barkeit von Einzelkomponenten, offene Architek-tur, herstellerübergreifende Produkte, Fokus aufdas Netzwerk) eine so lange Zeit überdauert, egalob es sich nun um ein BSD, Solaris, Linux oder An-droid handelt.

Auch Anderes ändert sich und bleibt sich den-noch treu: Der GUUG-Vorstand beispielsweise.Nach über 20 Jahren mit kurzen Unterbrechungenim Dienst der Mitgliedervertretung — viele da-von als erster Vorsitzender — hat Martin Schultebei den letzten Vorstandswahlen nicht mehr kan-didiert. Wir danken Martin für die umfassende Ar-beit und sein immerwährendes Engagement. Dasgilt natürlich auch für die anderen ausgeschiede-nen Kollegen Julius Bloch und Erwin Hoffmann(der aktuell noch kommissarisch die Kasse führt).

Das neue Team steht im Zeichen der Verbin-dung von Bewährtem und Neuem: Neben langjäh-rigen GUUG-Mitgliedern hat die Mitgliederver-

sammlung auch Aktive des LinuxTag in das Ver-tretungsorgan berufen. Mit diesem Verein plantdie GUUG schließlich auch eine Verschmelzungin diesem Sommer. Sobald die Steuerabschlüsseund rechtlichen Voraussetzungen erfüllt sind, in-formieren wir Euch über die folgenden Schritte.Mit etwas Glück kann das schon in wenigen Wo-chen anstehen.

Jetzt jedoch steht die Ferienzeit vor der Tür.Hoffen wir, dass die Zeit sommerlicher Tempera-turen mehrheitlich zu kühlenden Besuchen am Ba-desee oder im Biergarten führt (vormerken: am 29.Juli ist Admin Appreciation Day) und weniger zuUSV-Failovers im überlasteten Serverraum. Sei dieUpTimes dabei eine erquickende Lektüre!

Übrigens: Um die UpTimes nach dieser Som-merausgabe nahtlos fortzuführen, sucht dieGUUG einen Chefredakteur oder eine Chefredak-teurin, der oder die die Fäden in der Hand hältund das Erscheinen der folgenden Ausgaben si-cherstellt. Einzelheiten entnehmt bitte dem KastenStellenausschreibung: Chefredaktion für die UpTimes.

Und es gibt sogar neue Pläne: Wir haben eineUmfrage unter den GUUG-Mitgliedern durchge-führt, ob sie gern die UpTimes auch in der hoch-verfügbaren Variante, sprich auf Papier in derHand halten würden. Da wir darauf eine viel-versprechende Resonanz erhalten haben, startenwir einen experimentellen Testballon. Wer unterhttps://guug.de/uptimes-versand bestätigt, dass sei-ne Anschrift noch stimmt, kann die UpTimes ingedruckter Form zugeschickt bekommen. DiesenBeta-Service probieren wir einige Ausgaben langunverbindlich aus. Die PDF- und ePub-Versionengibt es weiterhin unverändert zum Download un-ter http://www.uptimes.de/.


https://guug.de/uptimes-versand

http://www.uptimes.de/


Über Ingo und Nils

Ingo Wichmann ist seit vielen Jahren Mitglied im German Unix Users Groupe.V. (GUUG) und fungiert seit 2017 als erster Vorsitzender des Vorstands.Das idyllische Konferenzhaus Linuxhotel im Essener Ortsteil Horst, in demIngo als Geschäftsführer und Referent arbeitet und lebt, wäre ohne ihnnicht dasselbe. Auch als langjähriger Vorsitzender und Veranstalter des Li-nuxTag hat er der Open-Source-Community seinen Dienst erwiesen. NilsMagnus ist Mitgründer des LinuxTag, ebenfalls seit etlichen Jahren GUUG-Mitglied und seit 2014 Mitglied im GUUG-Vorstand. Beruflich verdingt ersich als leitender Security-Consultant, Referent und Fachautor. Als Mitver-anstalter beim LinuxTag und bei der GUUG organisiert er seit über 15 Jah-ren Konferenzen und Workshops. Nils zieht gerade nach Berlin.



Stellenausschreibung: Chefredaktion für die UpTimes

Die German Unix Users group (GUUG e.V.) sucht zum 1. Juli 2017 eine Chefredaktion für die UpTimes,die Mitgliederzeitschrift der GUUG.

Gesucht ist ein Mitglied oder eine externe Person, die sich der UpTimes, dem Mitgliedermagazin desGUUG e.V., gesamtverantwortlich annimmt. Sie koordiniert und produziert federführend zwei bis vierAusgaben pro Jahr. Journalistische oder redaktionelle Erfahrung ist sehr nützlich, aber nicht zwingendnotwendig. Eine grundsätzliche Affinität zu technischen Themen ist erwünscht, insbesondere rund umunixoide Betriebssysteme und damit verbundener Anwendungen. Zu den Aufgaben zählen:

(1) Artikelakquise und Autorenkorrespondenz: Suchen und Finden von Themen und Autoren.

(2) Textredaktion und Bilderrecherche: inhaltliche und sprachliche Qualitätssicherung sowie Sicher-stellen, dass das Magazin ausreichend viele Abbildungen, Autorenbilder und Bildunterschriftenenthält.

(3) Zusammenarbeit mit und Förderung der ehrenamtlichen Redaktionsmitglieder: Mailinglisten-Updates, Korrespondenz mit der Redaktion und Außenstehenden, Pflege der Organisationsseitefür jede Ausgabe im GUUG-Wiki.

(4) Vorbereiten der UpTimes-Inhalte für ihre Verarbeitung durch die Produktions-Toolchain, die git

und LATEX enthält. Für den Satz und die Betreuung der IT-Systeme wird gesorgt.

(5) Weiterentwicklung des Layouts und der grafischen Gestaltung in Absprache mit den dafür zustän-digen Mitgliedern.

(6) Zusammenarbeit mit den Organen und Gruppen innerhalb der GUUG: Unterstützung von Anliegendes Vereines unter Wahrung der redaktionellen Unabhängigkeit.

(7) Handling der Autorenabrechnungen in Form von Honorarberechnung und Informationsverteilungan Autoren und Kassenwart. Die Rechnungen selbst schicken die Autoren an den Verein, der auchdie Zahlungen abwickelt.

Es sind verschiedene Vergütungsmodelle möglich, etwa auf Stundenbasis oder pauschal pro Ausgabe.Büroeinrichtung und Kommunikationsinfrastruktur organisiert die Chefredaktion selbständig. Die Wahldes Arbeitsortes ist frei wählbar. Der Vorstand vergütet Materialaufwände und Reisekosten nach Abspra-che, zum Beispiel die Teilnahme am FFG, der hauseigenen Fachkonferenz der GUUG, zu Berichts- undKontaktzwecken.

Interessierte melden sich bitte zusammen mit einer Beschreibung ihrer Motivation und ihrer redaktionel-len Erfahrung bei der Redaktion unter <[email protected]>, die für Fragen zur Verfügung steht.

Dieses Stellengesuch kann gern an geeignete Stellen innerhalb und außerhalb des Vereins weiterge-reicht werden.


mailto:[email protected]

UPTIMES SOMMER 2017 REAL-LIFE-FORUM

Real-Life-ForumDas Frühjahrsfachgespräch 2017

Das FFG (Frühjahrsfachgespräch) der GUUG fandin seiner 2017-er Ausprägung am 21. bis 24. März inDarmstadt statt.

von Anika Kehrer

Es fällt immer auf,wenn jemand über Dinge redet,die er versteht.

Helmut Käutner

Ungewöhnlich, aber gut war die Idee, eine Keyno-te mal an das Ende der Veranstaltung zu legen.Der Informatiker und Journalist Hanno Böck (Ab-bildung 1) verschaffte somit am frühen Freitag-abend des 24. März den bisweilen schon ermatte-ten Geistern Frischluft, als er die mangelnde Wis-senschaftlichkeit der IT-Sicherheit (und in Teilenauch der Wissenschaft an sich) anprangerte. SeinVortrag war allein schon deswegen anregend, weilman sich für den Ironieanteil seiner so lakoni-schen wie informativen Ausführungen nochmalneu kallibrieren musste – ein gelungener Event-Abschluss. Böcks Slides sind mit einigen anderender FFG-Vorträge auf den GUUG-Webseite ver-fügbar [1].

Abbildung 1: IT-Journalist Hanno Böck zog vom Leder.(Fotos: Anika Kehrer)

Mehrfach hatte ja die Community beim dies-jährigen Frühjahrsfachgespräch bemängelt, dassdie Veranstaltungsankündigung relativ spät fer-tig geworden war. Es haben in der Folge nichtganz so viele Konferenzbesucher (rund 60) diesteinernen Treppen der Technischen UniversitätDarmstadt abgenutzt, als es in anderen Jahrenauf anderen Universitätstreppen der Republik derFall gewesen sein mochte. Es wurde aber auch

mehrfach angemerkt, dass das Programm sich se-hen lassen konnte [2]. Die zwei Vormittags- undNachmittagsblöcke, parallel in zwei Räumen lau-fend, waren großteils so geclustert, dass thema-tisch benachbarte Vorträge aufeinander folgten.Auf den Wortteil ‚Fachgespräch‘ in ‚Frühjahrs-fachgespräch‘ wirkte sich das förderlich aus: Nichtnur Zuhörer, sondern auch die Referenten kamenin den abschließenden Q&A-Teilen ihrer Vorträgemiteinander ins Gespräch.

Software Storage

Man stutzte etwas, als Felix Hupfeld (Abbildung2) seinen Vortrag Software Storage – Storage zumHerunterladen mit einer Übersicht zur Entwick-lung der Netzwerkgeschwindigkeit begann. ÜberStorage-Software und -Hardware in verteilten Sys-temen ging er zu Ansätzen der Fehlertoleranz inSoftware über. Es gelte die „magische Zahl 3“:Zwei Systeme mit automatischem Failover funk-tionieren nicht – man brauche ein drittes System,außerdem menschliches Entscheiden im Zweifels-fall. Er landete beim „Storage der nächsten Gene-ration“: ein verteiltes System, Software-basiert aufStandard-Hardware, mit Fehlertoleranz und Red-undanz in der Software.

Google nannte der Referent als lebenden Be-weis, dass Software-Storage funktioniere. Umsowichtiger sei bei so einem verteilten Storage-System natürlich das Netzwerk: Man braucheschnelle Netze. Daher das Referat darüber am An-fang. Da die Netze schneller sind als die Hardwa-re, sei es auch egal, ob das Storage lokal oder re-mote ist – nur ein paar hundert Nanosekunden La-tenz wiesen Ethernet-Switche heute auf.



Abbildung 2: Felix Hupfeld wusste, wovon er redet.

Dass der Referent quasi seine eigene Geschäfts-grundlage verargumentierte (und mithin bewarb)störte bei seinem sachlichen Vortrag kaum. AmBerliner Bahnhof Zoo sitzt nämlich die von ihmund einem Kollegen 2013 gegründete Firma Quo-byte. Produkt der Software-Firma ist das Data Cen-ter File System [3], das eine Weiterentwicklung desEU-geförderten verteilten Dateisystems XtreemFS[4] für Hardware-entkoppelte Storageinfrastruk-turen ist. Dieses wiederum haben Hupfeld undsein Quobyte-Gründerkollege 2006 selbst im Rah-men ihrer Doktorarbeit angestoßen. Der Vortragwar also ein gutes Beispiel dafür, wie sachlicheTiefe – kombiniert mit konzentriertem Sprechen –Genuss für den Hörer schafft, auch wenn der Vor-tragende finanzieller Stakeholder des Themas ist.

Ceph

Lars Marowsky-Bree (Abbildung 3) arbeitet seitsage und schreibe 17 Jahren bei dem Linux-Distributor SUSE und ist dort derzeit Architekt fürCeph-basiertes Enterprise-Storage. Naheliegender-weise referierte er über Ceph Status und Roadmap.Auch Ceph begann 2004 sein Ideenleben als Dok-torarbeit, rief der Referent ins Gedächtnis [5]: DerDoktorand – Sage Weil ist heute bei Red Hat an-stellig – wollte ein skalierbares Dateisystem schrei-ben, und es stellte sich heraus, dass das ganz schönkompliziert ist. Inzwischen skaliert es in der Pra-xis aber auf mehrere tausend Server (etwa beimCERN, [6]). Seine Basis ist RADOS (reliable au-tonomic distributed object store), worauf Daten-Handling für drei Fälle sitzt: Object Storage, Block-Devices, und CephFS. CephFS wurde im April2016 mit der LTS-Version 10.2 (Jewel) von Ceph alsstabil erklärt.

Abbildung 3: Lars Marowsky-Bree war begeistert vonBlueStore.

Begeistert zeigte sich der Referent von BlueSto-re [7], das ab Version 10.2 experimentell an Bordist, und das insbesondere für Kunden wertvoll sei,weil alles damit zwei mal schneller gehe. In deraktuellen Stable-Release 11.2 (Kraken) von Januarist BlueStore aber noch als experimentell gekenn-zeichnet [8]. Die Entwickler arbeiten derzeit an derFertigstellung der nächsten LTS-Release 12 (Lumi-nous), die für dieses Frühjahr angekündigt warund für die der Referent (wohlgemerkt zum FFG-Zeitpunkt Ende März) angab, dass BlueStore hiernicht nur stabil, sondern auch bereits der Defaultsein sollte.

Sicher authentisieren

Der NetKnights-Sicherheitsberater Cornelius Köl-bel (Abbildung 4) schlug eine Bresche fürZweifaktor-Authentisierung. Der normale An-wender, begann er, tendiere ja dazu, ein Passworteinfach immer wiederzuverwenden, das er sichmerken kann. Daraus resultiert dann der Unken-ruf: Das Passwort ist tot – sprich, nicht sicher ge-nug. Kölbel ist der Meinung, auf ein Passwort zuverzichten sei Quatsch, denn immerhin erschwerees den Angriffsweg. Aber man könnte es zu bes-seren Sicherheit um eine weiteres Attribut anrei-chern. Zum Beispiel könnte über die bloße Zei-chenkette hinaus eine Rolle spielen, wer das Pass-wort besitzt, oder welche Merkmale es hat. So lan-det man bei Zweifaktor-Authentisierung.

Der eine Faktor darf hierbei das gewöhnlichePasswort bleiben. Der zweite Faktor muss sichdurch drei Eigenschaften auszeichnen. Erstens:Eindeutigkeit. Er darf also nicht kopierbar sein.Zweitens: Der Verlust soll bemerkbar sein. Bei ei-nem Fingerabdruck wäre das zum Beispiel nichtder Fall. Drittens soll er rückrufbar und neu aus-stellbar sein – für biometrische Merkmale gilt das



zum Beispiel nicht. Biometrische Merkmale eig-nen sich darum zwar für die Identifizierung, al-so den Benutzernamen, aber nicht als Authenti-sierungsfaktor, erklärte der Referent. Als Beispielezweiter Faktoren führte er Einmalpassworte, eineSmartcard und U2F ins Feld. Hinter U2F verbirgtsich der so genannte Universal 2nd Factor, den dieFiDO Alliance (Fast iDentity Online, [9]) ausbrütet:Die Idee ist, dass sich die Nutzer von Webdienstenzusätzlich zum Passwort mit einem Stück Hard-ware authentisieren, um Identitätsmissbrauch zuvermeiden.

Abbildung 4: Cornelius Kölbel sah die Schuld mal nichtnur beim User.

Was genau als zweiter Faktor das Beste ist,wollte Kölbel nicht final entscheiden. Er hader-te damit, dass seine eigentlich favorisierte Lö-sung U2F bei Anwendern schlicht nicht zum Ein-satz komme. Das liege aber zur Abwechslungmal nicht am User, sondern an den Herstellern.Das U2F-Device ist nämlich typischerweise einUSB-Stick, und die FiDO Alliance hat eigentlichzum Ziel, die Anmeldung bei Google, Facebookund Consorten sicherer zu machen. Das würdeaber bedeuten, dem Browser Zugriff auf die USB-Schnittstelle zu geben – schwierig, schwierig, woger den Kopf hin und her.

Insbesondere litt der Referent darunter, dasspro Dienst ein separates Schlüsselpaar nötig wird.Das lasse nämlich die Zahl der Schlüssel auf demDevice explodieren. Darum arbeitet der Stick miteinem Masterkey, der auf dem Device liegt undauf dessen Basis die Schlüsselpaare entstehen.Das Problem: Der Masterkey wird vom Herstel-ler generiert. „Uns wird nicht zugetraut, so etwasselbst zu erzeugen“, zuckt der Referent traurig dieSchultern.

Abbildung 5: Gutgelaunte Restmenge der FFG-Besucher 2017 am Freitag gegen 19 Uhr.

Gehet hin und redet

Das Berichtete sind natürlich nur Schlaglichter, re-lativ willkürlich herausgegriffen aus rund 30 Vor-trägen des FFG 2017. Nie ist ein Vortrag so gut wieder andere, und immer stellt sich bei einem Eventjedweder Art die Frage, ob man wirklich dage-wesen sein muss. Neben seinem deutlichen fachli-chen und eventplanerischen Anspruch ist das FFGaber stets auch ein Forum, in dem sich GUUG-Mitglieder und Artverwandte treffen. Einige ken-nen sich seit Jahrzehnten – doch mittlerweile tre-ten auch Jüngere wieder aufs Parkett (Abbildung5).

Abbildung 6: Geselliger Abend des FFG 2017.

Der Schlüssel des Ganzen ist Reden. Gehet al-so hin und redet: Auf dem Social Event (Abbil-dung 6), in den Q&A-Sessions, auf dem Flur . ZurNot redet mitten in einen Vortrag hinein! Letzte-res aber am liebsten dann in solcher Güte, dass esBeifall statt Brummen verdient.



Links

[1] Verfügbare Vortragsfolien des FFG 2017: https://guug.de/veranstaltungen/ffg2017/slides.html[2] Programm des FFG 2017: https://guug.de/veranstaltungen/ffg2017/programm.html[3] Data Center File System: https://www.quobyte.com/de/product[4] XtreemFS: http://www.xtreemfs.org[5] Sage A. Weil: Ceph; Reliable, scalable, and high-prformance distributed storage. Dissertation, SantaCruz 2007: https://ceph.com/wp-content/uploads/2016/08/weil-thesis.pdf[6] Aufzeichnung des Vortrags Ceph beim CERN von Dan van der Ster beim Openstack-Summit Vancouver2015: https://www.openstack.org/videos/vancouver-2015/ceph-at-cern-a-year-in-the-life-of-a-petabyte-scale-block-storage-service[7] Vortragsfolien BlueStore, a new storage backend for Ceph von Sage Weil im Jahr 2017:

https://de.slideshare.net/sageweil1/bluestore-a-new-storage-backend-for-ceph-one-year-in[8] Release Notes von Ceph: http://docs.ceph.com/docs/master/release-notes/[9] FiDO Alliance: https://fidoalliance.org

Über Anika

Anika Kehrer arbeitet seit rund zehn Jahren als Technikjournalistin für ver-schiedene Medien und ist seit der Wiederauflage der UpTimes im Som-mer 2012 als Chefredakteurin an Bord. Ihre Arbeit ist auszugsweise aufder Webseite https://www.torial.com/anika.kehrer zu sehen. Auf Google Plus(https://plus.google.com/114887154907909509357) reichert sie die digitale Öf-fentlichkeit um subjektiv Relevantes an. Manchmal auch ironisch.


https://guug.de/veranstaltungen/ffg2017/slides.html

https://guug.de/veranstaltungen/ffg2017/programm.html

https://www.quobyte.com/de/product

http://www.xtreemfs.org

https://ceph.com/wp-content/uploads/2016/08/weil-thesis.pdf

https://www.openstack.org/videos/vancouver-2015/ceph-at-cern-a-year-in-the-life-of-a-petabyte-scale-block-storage-service

https://www.openstack.org/videos/vancouver-2015/ceph-at-cern-a-year-in-the-life-of-a-petabyte-scale-block-storage-service

https://de.slideshare.net/sageweil1/bluestore-a-new-storage-backend-for-ceph-one-year-in

http://docs.ceph.com/docs/master/release-notes/

https://fidoalliance.org

https://www.torial.com/anika.kehrer

https://plus.google.com/114887154907909509357

UPTIMES SOMMER 2017 FEIND IN MEINEM NETZ

Feind in meinem NetzFirmwareanalyse eines Multifunktions-druckers

Sicherheits- und Erkenntnisinteresse führten zudiesem Artikel, der Schritt für Schritt durch dieFirmwareanalyse des Epson-MultifunktionsdruckersWF-2540 geht.

von Yves-Noel Weweler

Du willst nicht zornsüchtig sein?Gut, dann sei nicht neugierig.

Seneca

Die Glücklichen sind neugierig.

Nietzsche

Ein Epson WF-2540-Multifunktionsdrucker [1]war gerade zur Hand, sodass die Untersuchungenauf diesem Gerät erfolgten. Um an die Firmwareeines Gerätes zu kommen, gibt es in der Regel fol-gende Optionen:

• Firmware beim Update abfangen,

• Firmware aus Hardware auslesen,

• Firmware beim Hersteller herunterladen.

Viele Geräte haben eine Aktualisierungsfunkti-on, bei der das Gerät selbst die Firmware herun-terlädt und installiert. Der Netzwerkverkehr lässtsich zum Beispiel mit Wireshark [2] aufzeichnenund dann nach Firmwaredateien durchsuchen. Al-ternativ liest man die Firmware aufwendig aus derHardware eines Gerätes aus. Dazu später mehr.Denn glücklicherweise bieten die meisten Herstel-ler Firmware und Updatetools zum Download an,sodass diese nur noch heruntergeladen werdenmüssen.

Für den WF-2540 stellt Epson einen Firmwar-einstaller für Microsoft-Windows-Betriebssystemebereit. Diese .exe-Datei ist dazu da, die Firmwareeines Gerätes über USB oder über das Netzwerkzu aktualisierten. Um an die Firmware zu gelan-gen, die sich irgendwo im Installer verbirgt, ent-packen wir ihn:

$ gunzip installer.exe

e_dge321.dll

ENBoost.dll

ENWA.ini

EPFWUPD.exe

FWG658TL.efu

iconv.dll

Resources/

unicows.dll

Unzip32.dll

Ins Auge sticht die Datei FWG658TL.efu. Mitetwas Fantasie könnte die Dateiendung für ‚Ep-son Firmware Update‘ stehen. Da wir nicht wis-sen, womit wir es zu tun haben, versuchen wir mitfile herauszufinden, um was für eine Art von Dateies sich handelt:

$ file FWG658TL.efu

FWG658TL.efu: Zip archive data, at least v2.0 to extract

Entpacken wir das ZIP-Archiv, kommt eineominöse Datei mit der Endung .rcx zum Vor-schein:

$ unzip FWG658TL.efu

Archive: FWG658TL.efu

inflating: FWG658TL.rcx

In Erwartung einer Binärdatei öffnen wir siemit einem Hexeditor, wobei sich herausstellt, dasssie mit einem Textteil beginnt. Sieht man sichdie .rcx-Datei dann in einem Texteditor an, äh-nelt ihr Anfang einer INI-Datei. Darauf folgen je-doch mehrere Megabyte Binärdaten. In den Ein-trägen der INI-Datei finden sich außerdem dasWort ‚Firmware‘ und sogar die vom Hersteller fürden Installer angegebene Firmwareversion. DieFirmware haben wir also schon einmal gefunden.

Updatemechanismus nutzen

Wie aber wird die Firmware an das Gerät übermit-telt, und wie wird mit ihr verfahren? Um das her-auszufinden, probieren wir das netzwerkbasierteFirmwareupdate des Installers aus. Das mit Wires-hark aufgezeichnete Update sieht aus wie in Ab-bildung 1.

Im Netzwerkverkehr finden sich keine Verbin-dungen zum Hersteller. Die Firmware ist alsokomplett im Installer enthalten. Das Update selbsterfolgt unverschlüsselt über HTTP in zwei Stu-fen. Es bereitet den Drucker zunächst mit einer



GET-Nachricht auf das Update vor. Mit Erhaltder Nachricht zeigt der Drucker auf dem Displayan, dass ein Update stattfindet. Durch eine POST-Nachricht schickt der Updatemechanismus in ei-nem zweiten Schritt Binärdaten an den Drucker.Dabei überträgt er die vorher gefundene .rcx Da-tei, aber ohne den INI-Abschnitt am Dateianfang.

Abbildung 1: Aufgezeichnete Netzwerkkommunikati-on bei der Firmwareaktualisierung.

Nun wissen wir grob etwas über die Firmware-Datei und ihren Übertragungsweg. Es gilt, Nä-heres darüber herauszufinden. Der WF-2540 bie-tet laut Handbuch zusätzlich zu normalen Firm-wareupdates einen speziellen Wiederherstellungs-modus an. In diesem Modus soll man nach einemfehlgeschlagenen Firmwareupdate neue Firmwa-re installieren können. Für uns klingt das gut, fallswir das Gerät nämlich bei unseren Versuchen un-brauchbar machen sollten. Außerdem zeigt derWiederherstellungsmodus Status und Fehlernach-richten an. Diese könnten helfen, den Prozess bes-ser zu verstehen.

Das Handbuch enthält allerdings keine Infor-mationen darüber, wie dieser Wiederherstellungs-modus zu nutzen ist. Eine Suche im Netz fördertzu Tage: Dieser versteckte Betriebsmodus wird ak-tiv, wenn man das Gerät mit der Tastenkombinati-on STOP + LEFT + COPY + POWER einschaltet.Siehe da: Das Gerät startet und teilt uns auf demDisplay mit, dass es auf Firmware wartet.

Die jetzt beim Update ausgegebenen Statusmel-dungen ermöglichen, ein Ablaufdiagramm zu er-stellen. Dafür führen wir mehrere Updates mitoriginaler Firmware durch. Damit aber möglichstverschiedene Pfade durchlaufen werden, verän-dern wir nach Zufallsprinzip in einem Hexeditorjeweils einige Bytes in der Firmware, um Fehlerzu-stände zu provozieren. Über die angezeigten Sta-tusmeldungen ergibt sich so das Ablaufdiagrammin Abbildung 2.

Beim Update werden also zwei Dateien gelesenund irgendetwas mit der Bezeichnung ‚IPL‘ aufKorrektheit geprüft. Anschließend werden die Da-teien in zwei separate ROM-Bereiche geschrieben.

Annäherung: Entropie-Analyse derFirmwarestruktur

Firmware ist in der Regel speziell auf einen einzel-nen Gerätetyp zugeschnitten. Verschiedene Her-steller nutzen unterschiedliche Formen von Firm-ware für ihre Geräte. Herstellerübergreifend defi-nierte Datenformate und Darstellungsformen sindunüblich.

Abbildung 2: Ablaufdiagramm des Firmwareupdate-Prozesses.

Bei unbekannter Firmware ist es wichtig, zu-nächst einen Überblick zu bekommen und her-auszufinden, womit man es zu tun hat. Dazu eig-net sich hervorragend das Programm binwalk [3],welches in der Firmware nach bekannten Signa-turen sucht. Dadurch lassen sich schnell bekann-te Dateisysteme, Datentypen und komprimierteDaten innerhalb der Firmware identifizieren. Bin-walk erlaubt außerdem, grafisch die Entropie ei-ner Datei anzuzeigen, um deren Struktur besserzu verstehen. Wir durchsuchen also die Firmwa-redatei nach Signaturen bekannter Dateiformate.



Dabei sucht das Tool nach Bytefolgen, mit denenbekannte Dateiformate starten. Das bringt jedochnicht selten auch eine ganze Reihe von falsch er-kannten Inhalten mit sich. Letztlich ist Handarbeitgefragt, um die Brauchbarkeit der Funde zu be-werten.

Deswegen gehen wir die Liste der Funde ma-nuell durch und überprüfen offensichtlich falscheFunde mit einem Hexeditor. Falsche Funde sinddann wahrscheinlich, wenn die Daten schon aufden ersten Blick nicht zu den Beschreibungen oderDatenstrukturen passen, die für viele Datenfor-mate (etwa JPG) dokumentiert sind. Mit etwasSuchen finden sich oft auch Datenstrukturen ausImplementierungen, die solche Dateien verarbei-ten. Die Überprüfung erfolgt anhand der gefun-denen Bytefolge, ob nämlich eine valide Datei die-ses Typs bestehen könnte. Falls nein, brauchen wirdiesen Fund nicht weiter zu beachten. Falls ja, be-trchten wir den Fund näher, um mehr über dieFirmware zu lernen – etwa ihre Dateisysteme.

Im Entropiegraphen (Abbildung 3) zeigt sichklar erkennbar, dass die Firmware aus mehrerenBlöcken besteht. Bereiche mit hoher Entropie deu-ten auf Inhalte mit hohem Informationsgehalt hin.Stark komprimierte oder verschlüsselte Daten ha-ben beispielsweise eine hohe Entropie. Im Falleunserer Firmware trifft dies etwa auf den kom-primierten Kernel und die komprimierten Datei-systeme vom Typ CRAMFS (Compressed ROM fi-le system) zu. Die Bereiche des Graphen mit ei-ner Entropie nahe Null enthalten hingegen fastgar keine Informationen. Es handelt sich dabei umBlöcke mit Nullbytes.

Abbildung 3: Entropiegraph der Firmware.

Nun wird klarer, womit wir es zu tun haben:Auf dem WF-2540 läuft ein Linuxkernel mit zweikomprimierten CRAMFS-Dateisystemen.

Sprungbrett Dateisystem

Da wir jetzt wissen, wo welche Arten von Datei-systemen in der Firmware enthalten sind, versu-chen wir, diese genauer zu untersuchen. Mit dd

schneiden wir die CRAMFS-Dateisysteme aus derFirmware aus. Anschließend entpacken wir sie mitcramfsck. Das erste CRAMFS enthält das Root-Dateisystem, das zweite proprietäre Programmeund Konfigurationsdateien. Zum booten startetder Kernel lediglich ein Shellskript, welches Datei-systeme einhängt und das System einrichtet. Ab-gesehen von einem rudimentären Busybox existie-ren zwei proprietäre Anwendungen.

Welche Software auf dem WF-2540 läuft undwas sie genau tut, ließe sich nun genauer unter-suchen. Das ist bereits viel wert, aber noch bes-ser wäre es natürlich, wenn wir die Software inAktion beobachten und selbst verändern könnten.Um Zugriff auf den Drucker zu bekommen, versu-chen wir also, auf dem Gerät eine Shell zu aktivie-ren, die auf Netzwerkverbindungen wartet. Da-zu fügen wir auf dem entpackten Dateisystem in/etc/inted.conf folgende Zeile hinzu, die aufPort 4711 eine Shell öffnet:

4711 stream tcp nowait root /bin/sh sh -i

Mittels mkcramfs erstellen wir ein neuesDateisystem, das wir mit dd zurück in die Firm-ware kopieren. Anschließend starten wir den In-staller mit der neuen Firmware und versuchen un-ser Glück. Wir stellen fest, dass das Gerät nachwenigen Sekunden ohne ersichtlichen Grund dasFirmwareupdate stoppt. Wäre ja auch zu schöngewesen, wenn alles beim ersten Versuch funktio-niert hätte.

Schutz aushebeln: Datenstrukturengenauer ansehen

Unbekannte Schutzmechanismen scheinen zu ver-hindern, dass der Drucker unsere manipulierteFirmware installiert. Jetzt wird es knifflig. Diegrundlegenden Inhalte der Firmware sind gefun-den. Wie aber werden diese Inhalte zur eigentli-chen Firmware zusammengesetzt und vom Dru-cker gelesen? Beim Erstellen der Firmware kom-men sehr wahrscheinlich Schutzmechanismen ge-gen Übertragungsfehler oder Veränderungen zurAnwendung. Ohne zu verstehen, wann diese an-gewendet werden und wie sie funktionieren, kön-nen wir das System nicht verändern. Also zerlegenwir sie in Details.

Damit der Drucker die Firmware verarbeitenkann, muss sie eine Struktur haben, in der Infor-mationen abgelegt sind, die etwas über sie selbstsagen und darüber, wie mit ihr zu verfahren ist.Wie bei einer klassischen Datei ist davon auszuge-hen, dass die Firmware mit einer Art Dateiheader



beginnt. Ein Blick auf den zuvor erstellten Entro-piegraphen bestätigt einen noch unbekannten Da-tenblock am Anfang der Datei. Mit hexdump las-sen wir uns den Dateianfang ausgeben:

$ hexdump -C firmware | head

45 50 53 4f 4e 20 49 50 4c 66 00 4c 4a 00 30 00 |EPSON IPLf.LJ.0.|

01 00 59 35 00 00 00 00 00 00 00 00 00 10 00 00 |..Y5............|

02 00 8f 25 00 00 00 00 00 00 01 00 00 00 71 00 |...%..........q.|

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Die ersten Bytes bilden die Zeichenkette EP-SON IPL. Die Bezeichnung ‚IPL‘ ist bereits imAblaufdiagramm für den Update-Prozess aufge-taucht. Allerdings ist sie dort zweimal zu finden.Wir suchen also nach der Zeichenkette, um zu prü-fen, ob sie auch in der Firmware mehrfach vor-kommt. Ergebnis: Die Zeichenkette ist auch genauzweimal in der Firmware enthalten. Wenn wir de-ren Positionen zusammen mit den bisherigen Fun-den in einer Grafik einzeichnen, ergibt sich dieStrukturübersicht in Abbildung 4.

Abbildung 4: Strukturübersicht der Firmware.

Die aufgedeckten IPL-Datenstrukturen be-schreiben, wie die Firmware aufgebaut ist. Wieaber kann diese Anhäufung von Bytes entziffertwerden? Dazu gehört viel Geduld und langwie-riges Probieren. Doch es gibt Schritte, die dabeihelfen:

(1) Verschiedene Datenstrukturen sammeln.

(2) Unterschiede feststellen.

(3) Aufgaben einzelner Felder in der Daten-struktur rekonstruieren.

Es lohnt sich zunächst einmal, mehrere Daten-strukturen aus verschiedene Firmwareversionenfür das zu untersuchende Gerät zu ziehen, um et-was Varianz zu haben. Je mehr, desto besser. AuchFirmware für andere Geräte aus derselben Modell-reihe kann hilfreich sein.

Die gesammelten Datenstrukturen lassen sichdann zum Beispiel mit Binwalk vergleichen (Ab-bildung 5). So lassen sich zum einen einzelne Be-reiche in der Datenstruktur identifizieren. Zumanderen hat man verschiedene Beispiele für Da-ten, die Felder in der Datenstruktur enthalten kön-nen. Das hilft ungemein dabei, deren Funktion zu

studieren. Beim Interpretieren der Datenstruktu-ren ist immer darauf zu achten, in was für einerOrdnung die Bytes möglicherweise abgelegt sind.Wird das aus den Daten allein nicht ersichtlich,kann es nötig sein, die Werte zu interpretieren undzu schauen, welches Ergebnis am sinnvollsten er-scheint.

Abbildung 5: Unterschiede verschiedener IPL-Datenstrukturen.

Die IPL-Datenstrukturen des WF-2540 startenzum Beispiel allgemein mit dem Magic-Byte EP-SON IPL und scheinen nach einem Vielfachen von16 Bytes zu enden. Auf die Zeichenkette am An-fang folgen ein paar Bytes, deren Funktion nichtganz klar ist. Sie enthalten allerdings an einer Stel-le immer die zwei Zeichen, mit denen der alpha-betische Teil der Versionsnummer beginnt. Bei-spielsweise stehen die Zeichen LJ für die Version48.48.LJ05DC. Die ersten 16 Bytes enden mit ei-nem zwei-Byte-Feld, dass immer genau die Län-ge der Datenstruktur in Bytes enthält. Da die Wer-te im Little-Endian-Format ablegt sind, muss mandie Bytes beim Lesen drehen.

Folgende Beschreibung ist das Ergebnis der Be-trachtung vieler unterschiedlicher Firmwarever-sionen. Wie in Abbildung 5 zu sehen, verbleibennoch 32 weitere unbekannte Bytes. Bei diesen By-tes ist auffällig, dass sich ihre Struktur alle 16 By-tes ähnelt. Ein 16-Byte-Abschnitt scheint mit einerzwei-Byte-Zahl zu starten. Blöcke, die mit der glei-chen Zahl beginnen, besitzen die gleiche Struktur.Wir nennen einen solchen Abschnitt im Folgendeneinen Record. Ein weiteres, auf das erste folgendezwei-Byte-Feld scheint in jeder Firmwareversionanders zu sein. Dieses Feld ist aller Wahrschein-lichkeit nach eine Prüfsumme.

Jeder Record verweist auf einen Abschnitt mitDaten. Die letzten vier Bytes eines Record be-schreiben die Länge eines solchen Abschnittes inBytes. In jeder Firmwaredatei starten die Datendes ersten Record implizit mit $4$kB (0x1000) nachdem ersten Byte der IPL-Datenstruktur. ‚Implizit‘bedeutet hier, dass dieser Abstand nicht explizit



etwa durch ein Feld in der Firmware angegebenist. Die Datenblöcke der Records folgen aufeinan-der. Das Ende eines Blockes markiert den Anfangdes nächsten Blocks: Auf den letzten Datenblockeiner IPL-Struktur folgt also nahtlos eine weitereIPL-Datenstruktur mit neuen Records. Eine grafi-sche Übersicht der analysierten Datenstruktur istin Abbildung 6 zu sehen.

Abbildung 6: Übersicht der IPL-Datenstruktur.

Zum Kern vordringen: Prüfsummenreverse-engineeren

In der IPL-Datenstruktur verbleiben nun noch dieunbekannten Prüfsummen. Noch ist unklar, nachwelchem Algorithmus und über welche Daten siegebildet werden. Um das herauszufinden, habenwir folgende Möglichkeiten:

(1) Verschiedene Algorithmen und Datenberei-che ausprobieren.

(2) Auslesen des Flash-Speichers auf der Hard-ware.

(3) Reverse-Engineering der Updateroutinen.

Im ersten Anlauf probieren wir also einfachKombinationen von Algorithmen und Datenberei-chen aus. Da wir die möglichen Wertebereiche nurschwer eingrenzen können, geben wir wegen dergroßen Anzahl an Kombinationen aber klein beiund schreiten zur aufwendigeren zweiten Mög-lichkeit fort. Ein Update schreibt Teile der Firm-ware auf den Speicher des Druckers. Diese ge-schriebenen Daten werden höchstwahrscheinlichin der Firmware von den Prüfsummen abgedeckt.Wenn wir den Speicher auslesen, können wir dieseDaten vielleicht identifizieren und somit den Be-reich eingrenzen, über den die Prüfsummen ge-bildet werden. Führt auch das nicht zu neuen Er-kenntnissen, bleibt noch die dritte und aufwen-digste Möglichkeit – mittels Reverse-Engineeringdie Updateroutinen identifizieren, um sie zu un-tersuchen.

Abbildung 7: Hauptplatine des Epson WF-2540.

Zunächst versuchen wir aber, den persistentenSpeicher der Hardware auszulesen. Dazu zerle-gen wir das Gerät und entfernen die Hauptplati-ne (Abbildung 7). Auf der Platine befinden sichzwei Flash-Speicherbausteine. Diese ICs werdenüber den SPI-Bus (Serial Peripheral Interface) an-gesteuert. SPI wird von einer ganzen Reihe vonHardware unterstützt. Um den Speicher auszule-sen, reicht daher ein einfacher Einplatinenrechnerwie der Raspberry Pi oder ein günstiger separa-ter Speicherprogrammierer. Wir nutzen Letzteres.Zum Auslesen löten wir Kabel an die Kontakteder ICs und verbinden sie mit dem Programmie-rer (Abbildung 8).

Abbildung 8: Auslesen der Speicherbausteine auf derHauptplatine.

Die ausgelesenen Daten aus dem persistentenSpeicher vergleichen wir mit der Firmware (Abbil-dung 9). Der Vergleich zeigt, dass die Updaterou-tinen Teilbereiche der Firmware eins zu eins aufden Drucker kopieren. Diese kopierten Bereichesind auch genau jene, auf welche die Records derIPL-Datenstrukturen verweisen. Mit den identifi-zierten Datenbereichen erfolgt ein Rückschritt zuListenpunkt 1, indem wir verschiedene Algorith-men ausprobieren. Dadurch erhalten wir die ge-naue Bildungsvorschrift der Prüfsummen: Sie ent-stehen durch Aufsummieren von Bytes als zwei-Byte-Integer ohne Behandlung des Überlaufs. Ab-bildung 10 zeigt die in die Prüfsummen einbezo-genen Daten.



Abbildung 9: Vergleich zwischen Firmware und persis-tentem Speicher.

Abbildung 10: Daten, die in die Prüfsummen einflie-ßen.

Der Erfolg ist das Problem: EigeneFirmware aufspielen

Nun ist der Moment der Wahrheit gekommen. Wirnehmen uns die zuvor erstellte Firmware, die mitder Rootshell auf Netzwerkverbindungen wartet.Wir berechnen neue Prüfsummen und tragen siein die Datenstrukturen ein. Zu unserer Begeiste-rung – oder unserem Erschrecken – führt der Dru-cker das Update mit unserer selbst erstellten Firm-ware ohne Murren durch.

Ein Verbindungsversuch zur Rootshell mittelsnetcat ist ebenfalls erfolgreich. Wir haben nunwährend des Betriebs vollen Rootzugriff auf denDrucker. Weitere Analysen würden nun zur Lauf-zeit auf dem Livesystem erfolgen. Damit wir ei-gene Software auf dem Drucker nutzen können,kann zum Beispiel einen ARM-Cross-Compilereingerichtet werden. Mit diesem lassen sich danneigene Kernelmodule und Programme für denDrucker erstellen.

Die Frage nach der Sicherheit des Epson WF-2540 war der eigentliche Grund, sich mit dessenFirmware zu beschäftigen. Aus der Untersuchunglassen sich folgende sicherheitskritische Problemezusammentragen:

• Die Firmware ist nicht signiert.

• Die Prüfsummen sind schwach.

• Keine Authentifizierung bei Updates.

Aufgrund fehlender Signaturen kann das Ge-rät nicht überprüfen, woher die ihm geliefer-

te Firmware stammt. Damit ist die Unterschei-dung zwischen Schadsoftware und Herstellersoft-ware nicht möglich. Ein weiteres Problem gehtvon den verwendeten Prüfsummen aus. Sie de-cken wichtige Bereiche gar nicht ab, wie etwa dieIPL-Datenstrukturen. Defekte oder auch willent-lich eingefügte Veränderungen gerade der IPL-Bereiche können aber zu defekter Firmware unddamit auch zu defekten Geräten führen. Deswe-gen sollten die Prüfsummen eigentlich verhin-dern, dass beispielsweise Übertragungsfehler zudefekter Firmware führen. Hinzu kommt, dassdie Prüfsummen größere Bereiche mit ungenutz-ten Nullbytes einschließen. Da die Bytes lediglichaufsummiert werden, kann ein Angreifer durchManipulation der Nullbytes beliebige Prüfsum-men erzeugen. Zu allem Überfluss werden Upda-tes auch noch ohne Authentifizierung ausgeführt.Der Drucker kann also nicht bestimmen, wer dasUpdate durchführt, und ob derjenige überhauptdazu berechtigt ist.

Jeder, der physikalischen Zugriff auf den Dru-cker hat oder sich im gleichen lokalen Netzwerkmit ihm befindet, kann diesen also übernehmen.Manipulierte Firmware lässt sich problemlos überUSB, LAN oder auch WLAN aufspielen.

Dieser Zustand lässt sich noch weiter eskalie-ren. Schaut man sich die HTTP-Nachrichten ge-nauer an, so fällt auf, dass das Gerät keine Schutz-vorkehrungen gegen CSRF besitzt (Cross-Site Re-



quest Forgery, siehe Abbildung 11). Ein Angrei-fer muss daher nicht einmal direkt mit dem Ge-rät kommunizieren, um die Firmware zu erset-zen. Nahezu jeder Netzwerkteilnehmer, der sichim gleichen Netzwerk mit dem Drucker befindet,lässt sich dazu missbrauchen.

Dafür muss der Angreifer lediglich Javascriptauf einer Webseite platzieren, die einer der Netz-werkteilnehmer aufruft. Das Javascript führt dannvom Browser des Opfers aus das Update durch.Ein Drucker in meinem lokalen Netzwerk kann al-so durch das bloße Abrufen einer Website infiziertwerden. Sensible Informationen und Dokumente,die der Drucker gedruckt, gefaxt oder kopiert hat,lassen sich nach Belieben auslesen und verändern.Sogar das eingebaute Modem des Druckers kannzur Kommunikation genutzt werden, falls die-ses keine Netzwerkverbindung mehr haben soll-te. Von einem infizierten Gerät aus ist es möglich,weitere Geräte über das Netzwerk oder die USB-Verbindung anzugreifen.

Abbildung 11: Angriffsszenario für eine CSRF-Attacke.

Epson wurde im September 2015 über die ge-wonnen Erkenntnisse informiert. Mangels einesdirekten Ansprechpartners für Sicherheitsproble-me gingen die Information einfach per E-Mail andie Pressestelle des Unternehmens. Im Dezember2015 kam eine Rückmeldung, die ankündigte, dasProblem Ende Januar 2016 durch eine neue Firm-ware zu beheben. Mitte Februar 2016 erschienendann neue Firmwareversionen. Auch wenn nichtjede Untersuchung erfolgreich sein mag, so hofftder Autor dieser Zeilen, den Ansporn zum ge-naueren Hinschauen ab und zu geliefert zu haben.

Links

[1] Epson WF-2540:https://www.epson.de/products/printers/inkjet-printers/microbusiness/epson-workforce-wf-2540wf

[2] Wireshark: https://www.wireshark.org[3] binwalk: https://github.com/devttys0/binwalk

Über Yves-Noel

Yves-Noel Weweler besitzt den Bachelor in der Informatik und studiertaktuell Informatik im Masterstudiengang an der Fachhochschule Müns-ter. Vor seinem Studium hat er eine Ausbildung zum Informationstechni-schen Assistenten abgeschlossen. Er ist Gründungsmitglied und Vorsitzen-der der Studentengruppe der Gesellschaft für Informatik Münsterland.


https://www.epson.de/products/printers/inkjet-printers/microbusiness/epson-workforce-wf-2540wf

https://www.wireshark.org

https://github.com/devttys0/binwalk

UPTIMES SOMMER 2017 FREIWILLIGE FEUERWEHR

Freiwillige FeuerwehrKernel-Regressions bekämpfen

In einem englischsprachigen Vortrag erläuterteHeise-Journalist Thorsten Leemhuis auf der LinuxCon

Europe 2016, was Kernel-Regressions sind, warum esso wichtig ist, sie zu finden, und wie man das macht –ein feuriges Plädoyer, mit dem Löschzug auszurücken.Der folgende deutsche Text entstand mit freundlicherGenehmigung des Vortragenden.

übersetzt von Anika Kehrer

Man kämpft nicht nurmit dem Schwert,sondern auch mit dem Herzen.

Gustav Stresemann

Angenommen, nach einem Kernelupdate funktio-niert etwas an einem Linux-System schlechter alsvorher. Zum Beispiel ist die Performance schlech-ter, der Stromverbrauch höher, oder etwas gehtschlicht nicht mehr. Eine solche Verschlechterungnach einem Update ist eine Regression.

Jede Regression ist ein Bug. Aber nicht jederBug ist eine Regression. Das ist ein entscheiden-der Unterschied. Wie zum Beispiel in einem eige-nen Haus gibt es auch beim Kernel immer irgen-detwas, das nicht funktioniert. Wenn der Klemp-ner kommt, und seine Arbeit zu neuen Problemenführt, wirst du seine Arbeit reklamieren: Du be-zahlst ihn schließlich nicht dafür, etwas schlechterzu machen – das wäre eine Regression. Aber dukannst ihm nicht anlasten, wenn etwas in anderenBereichen schon lange vorher nicht funktionierthat – das wäre ein Bug. Ähnlich wie sich Hausbe-sitzer mit Macken ihrer vier Wände arrangieren,leben auch die Kernelentwickler mit einigen Bugs.Regressions hingegen sind etwas, das sie fürchten.

Und zwar aus folgendem Grund: Die Entwick-ler verändern und verbessern den Linux-Kernelständig. Der Code wächst dabei alle zehn Wochenum rund 300.000 Zeilen. Der Kernelcode besitztStellen, wo Neues hinzukommt. Er besitzt aberauch ungeschliffene Bereiche und Stellen, die niewirklich beendet wurden. Dinge mit einer neuenRelease zu verschlechtern (sprich: eine Regressi-on zu haben), ist gefährlich. Denn jede Regressi-on verprellt ein paar mehr Tester. Das wiederumführt zu noch mehr unerkannten Regressions. Dasverscheucht noch mehr Tester. Das führt zu nochmehr unerkannten Regressions. Das Ganze ist al-so offensichtlich die falsche Richtung.

Wie Regressions zu behandeln sind

Linus Torvalds hat daher seit Anbeginn der Linux-Zeit klar gestellt: Keine Regressions! Wenn einCode-Change eine Regression verursacht, dannwird

(1) entweder die Regression behoben,

(2) oder der Commit mit der Änderung rück-gängig gemacht.

Das klingt soweit einfach und prima. Es funktio-niert auch ziemlich gut beim Linux-Kernel. Es gibtaber ein Problem. Der Auslöser der Regressionmuss bekannt sein, um ihn rückgängig machen zukönnen. Nur das Problem zu beschreiben, reicht inden meisten Fällen daher nicht aus.

Die Losung lautet also: Leg den Finger in dieWunde und spüre den Commit auf, der die Re-gression verursacht. Finde also das Problem in12.000 Commits. Denn das ist die typische Zahlder Änderungen zwischen einem Kernel und derersten Vorabversion des Nachfolgers. Noch einmalrund 1.500 Commits mehr sind es, bis der Nachfol-ger dann fertig ist.

Die Ursache zu finden klingt aufwendig, istes aber gar nicht: Du checkst mit dem Quellco-deverwaltungssystem einfach eine Änderung aus,die sich etwa auf der Hälfte von diesen rund12.000 Commits befindet. Aus diesem Zwischen-stand baust du dann einen Kernel und prüfst, obsich die Regression mit ihm zeigt. Tritt sie auf, ver-fährst du genauso mit der ersten Hälfte der 12.000Commits; tritt sie nicht auf, tust du dasselbe mitder zweiten Hälfte der Commits:

12000÷2÷2÷2÷2÷2÷2÷2÷2÷2÷2÷2÷2÷2÷2 ==< 1



Mit anderen Worten baust du etwa 15 mal einenKernel und schaust jeweils, ob das Problemnoch auftritt. So findest du den schuldigen Com-mit. Man nennt den Prozess bisection, und git

bisect vereinfacht ihn [1].Wichtig dabei ist das Timing. Es ist genau das-

selbe, wenn du die Arbeit des Klempners rekla-mierst: Der lacht dich aus, wenn du 12 oder 24Monate nach seinem Auftrag einen Fehler an einerStelle reklamierst, an der andere Klempner seit-dem gearbeitet haben. Darum ist es wichtig, früh-zeitig und regelmäßig auf Regressions zu testen.Ohnehin wird es mit der Zeit immer schwerer, dasProblem einzugrenzen und zu beheben: Schon derKlempner weiß oft nicht mehr, was er vor ein oderzwei Jahren gemacht hat; ein Programmierer weißes mit Sicherheit nicht mehr. Mithin wird der Heu-haufen größer, in dem du selbst die Nadel suchst.Zwischen Kernelversion 4.4 und 4.8 lagen um die55.000 Commits, und auch Bugs häufen sich an.Vielleicht hast du es ja gar nicht mit einer Regres-sion, sondern mit mehren zu tun – oder ein odermehrere Bugs schießen beim Testen quer. Es wirdwirklich schwer, das auseinanderzuhalten.

Schließlich wird es mit verstreichender Zeit im-mer komplizierter, eine Änderung rückgängig zumachen. Manchmal kann das auch sehr schnellunmöglich werden. Ein Commit, der für die ers-ten Vorabversion von 4.8 vorgenommen wurde,ist normalerweise leicht rückgängig zu machen,bevor Version 4.8 erscheint. Das gilt auch dann,wenn es die Änderung in einer großen Gruppevon Changes ist, denn notfalls wird diese dannkomplett zurück genommen. Aber sobald Versi-on 4.8 draußen ist, geht das nicht mehr so ein-fach. Vielleicht wurde dann schon etwas für Ver-sion 4.9 gemergt, das von dem schuldigen Changeabhängig ist. Oder der schuldige Change besitztein Feature, auf das Leute bereits zählen – dannwürde das Rückgängigmachen dieses Changes so-zusagen eine Regression für diese Leute bedeuten.

Darum ist es wichtig, neue Kernelversionenfrühzeitig zu testen – am besten noch, bevor sieveröffentlicht sind. Darum solltest du Pre-Releases(aka rc) der Kernel testen (zum Beispiel Version4.9-rc2). Und: Nein, es ist nicht so gefährlich, wiees sich vielleicht anhört. Das sehen wir uns gleichmal an.

Beim Testen gilt es zu bedenken: Es gibt Pro-bleme, die keine Regression sind. Du solltest dichzum Beispiel nicht darauf verlassen, dass Device-Namen (sda, sdb, . . . ) gleich bleiben. Du soll-test keine externen Treiber verwenden, die sichnicht im Kerneltree befinden. Aber lass dich da-

von nicht entmutigen. Und vor allem mach dir be-wusst, warum die Mühe für dich ganz persönlichwichtig ist.

Warum man Kernel-Regressionsbekämpfen sollte

Aus bestimmten Gründen ist es für jeden ein-zelnen Linux-Nutzer extrem wichtig, Kernel-Regressions zu bekämpfen. Moderne Computersind extrem komplex. Außerdem gibt es hunder-te Distributionen mit unterschiedlichen Kompo-nenten und Treibern. Dazu kommen etliche Mög-lichkeiten, den Kernel zu konfigurieren und zunutzen. So gibt es alleine diverse Dateisysteme(btrfs, ext4, xfs, . . . ) und verschiedene Storage-Layer (mdadm, crypto, lvm, . . . ), die sich auf viel-fältige Weisen kombinieren lassen. Ähnlich siehtes beim Netzwerksubsystem und anderen Berei-chen aus. Alle diese Kombinationen müssen ge-testet werden, denn manche Regressions tauchenlediglich in bestimmten Kombinationen auf. An-dere Regressions zeigen sich nur mit einer der Zil-lionen von Hardware-Komponenten da draußen.Manches Problem tritt nur in einer ganz bestimm-ten Kombination von Bauteilen auf, oder nur miteiner speziellen Firmware.

Das macht dein Setup höchstwahrscheinlicheinzigartig. Du kannst dich also nicht darauf ver-lassen, dass andere die Regressions finden, die dei-ne Systeme betreffen. Dein Setup ist vielleicht auchdann einzigartig, wenn du bekannte, weitverbrei-tete Systeme benutzt. Linus Torvalds hat zum Bei-spiel jüngst einen Dell XPS 13 gekauft [2]. Mankönnte sich dann denken: Das Notebook müssteja gut funktionieren. Aber die Bezeichnung XPS13 steht für eine ganze Reihe verschiedener Sys-teme, denn ungefähr einmal pro Jahr erscheint einneue Gerätegeneration, die neuere und manchmalsogar ganz anderen Bauteile enthält. Und selbstzwischen den Notebook-Modellen einer Generati-on gibt es oft größere und signifikante Unterschie-de.

Torvalds hat beispielsweise nicht erwähnt, ober das FHD- oder das QHD-Touch-Display ge-nommen hat – und vielleicht tritt eine Regressionnur mit der Konfiguration auf, die der Linux-Vatergerade nicht hat. Manchmal ist auch die Storage-Konfiguration entscheidend. Und übrigens unter-scheiden sich auch die Modelle XPS 13 und dieXPS 13 Developer Edition teilweise. Die Developer-Edition (das ist die, die mit Ubuntu kommt) des2015er-Modells nutzt beispielsweise ein anderesWlan-Modul. Außerdem kam zeitweise auch ei-



ne andere Firmware zum Einsatz, die den Audio-Codec ganz anders konfigurierte.

Alle diese kleinen Unterschiede können eineRegression triggern, die nur auf einer der vielenModell-Varianten auftritt. Das Dell-Notebook istdabei noch ein einfaches Beispiel, denn bei denverbreiteten Lenovo-T- oder -X-Laptops gibt esnoch mehr Modellvarianten. Einige T450-Modellekommen beispielsweise mit integrierter GPU, an-dere mit dedizierter, ganz zu schweigen von Add-ons wie Repeatern oder Dockingstations. Immer-hin ändert sich die Modellnummer mit jeder neu-en der Generation (T450 wird zu T460), statt wiebeim XPS 13 immer gleich zu bleiben.

Wenn du dein Setup nicht testest, wirst du frü-her oder später in eine Regression laufen. Um-zukehren wird dann manchmal schwer oder un-möglich sein: Selbst nach einem kleinen apt-get-Update fehlt vielleicht gerade einfach die Zeit,um den vorher eingesetzten Kernel wieder her-an zu holen. Nach einem größeren Distributions-update ist die Rückkehr zu einem alten Kernelvielleicht immens aufwendig oder auch deswegenkeine wirkliche Option mehr, weil deine alte Dis-tro keinen Sicherheitsupdates mehr bekommt.

Also ist es wichtig, dein spezifisches Setup im-mer wieder auf Regressions zu testen, damit duProbleme früh erkennst, solange du sie noch leichtumgehen und korrigieren lassen kannst. Je weni-ger verbreitet oder älter dein Setup ist, und je exo-tischer deine Distribution und deren Konfigurati-on ist, desto wichtiger ist es. Darum ist es in dei-nem eigenen Interesse, beim Bekämpfen von Re-gressions zu helfen.

Wie man auf Regressions testet

Das ist ganz einfach: Führe den Vorabversionendes Mainline-Kernel aus – also „rc“ oder „Prere-lease“ genannten Kernel-Versionen, wie in Linux4.9-rc1. Nein, das ist nicht gefährlich. Das Risikofür Datenverlust ist etwas höher als bei Distro-Kernels, aber es ist trotzdem klein. Und Backupsmachst du ja sowieso, nicht wahr?

Du benutzt entweder ein schon kompiliertesKernel-Image, oder du baust den Kernel selbst.Beide Varianten sind nicht wirklich schwierig. Imtäglichen Gebrauch ist ein vorkompilierter Ker-nel völlig in Ordnung. Solche findest du in Re-positories, die entsprechende Debian- und RPM-Pakete zur Verfügung stellen. Bei Fedora gibt esdas Vanilla-Repo [3], bei Suse heißt das RepoKOTD (Kernel of the Day), bei Ubuntu gibt es dasLinux-mainline PPA. Einige Distributionen liefern

sogar RC-Kernel, zum Beispiel Fedora Rawhide.Der Nachteil des kompilierten Kernels ist, dass

sie manchmal distributionsspezifische Patchesenthalten. Manchmal sind das sogar ganz schönviele. Es ist also ratsam, eine im Distro-Kernel ge-fundene Regression mit einem Vanilla-Kernel er-neut zu testen. Den Vanilla-Kernel brauchst du al-lerdings sowieso, wenn du den Kernel bisektierenwillst. Einen eigenen Kernel zu kompilieren berei-test du wie folgt vor (Beispiel Fedora):

$ dnf install make gcc git openssl-devel

Dann führst du folgende Kommandos aus:

01 $ git clone \

git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

02 $ make olddefconfg localmodconfg

03 $ make -j 12 bzImage modules

04 $ sudo make modules_install install

Zeile 01 lädt das Git-Verzeichnis mit denKernelquellen herunter. Das kann eine Wei-le dauern. Zeile 02 übernimmt mit der Make-Anweisung olddefconfg die Konfiguration dei-nes Distributions-Kernels und setzt alle noch nichtgesetzten Konfigurationsparameter auf den Stan-dardwert. Das localmodconfg deaktiviert alleModule, die auf deinem System in dem Momentnicht genutzt werden, um die Zeit zum Kompilie-ren zu reduzieren. Dieses Make-Target verursachteine Handvoll Rückfragen. In den allmeisten Fäl-len kannst du hier Enter drücken, um den Stan-dardwert zu übernehmen. Die resultierende Kon-figuration ist nicht perfekt, aber schnell erzeugtund für die meisten Fälle gut genug. Zeile 03 bautschließlich das Kernel-Image und seine Module.Auf einem fünf Jahre alten Lenovo T420 dauertdas übrigens 12 Minuten. Zeile 04 installiert dasGanze, was auf besagtem T420 mit Fedora 75 Se-kunden dauert. Wenn du eine Regression jagst,die in der jüngsten Kernelversion enthalten ist,prüfe die vorangegangene Major-Release, ob dieRegression nicht schon dort auftritt.

Das Ganze ist also nicht wirklich schwer. Nunschaust du, ob alles funktioniert. Wenn nicht,kannst du einfach zu deinem vorigen Kernel zu-rückkehren. Wenn ja, und wenn du nach einigenTagen einen neuen Snapshot des Kernels ziehenwillst, gibst du Folgendes ein:

01 $ git pull

02 $ make olddefconfg

03 $ make -j 12 bzImage modules

04 $ sudo make modules_install install

Wenn du alte Kernel und ihre Moduleloswerden willst, listest du sie mit ls -tr

/lib/modules/ auf. Dann suchst du die Ver-sion, die du löschen willst. Pass dabei aber



auf, dass ein funktionierender Kernel instal-liert bleibt – der Distro-Kernel zum Beispiel.Dann löschst du das Verzeichnis und alle Da-teien in /boot/, die die Versionsnummer deszu löschenden Kernels enthalten. Optional ak-tualisierst du die Grub-Konfiguration mit einemBefehl wie grub-mkconfg oder (bei Ubuntu)update-grub.

Wie man Regressions meldet

Drei Schritte solltest du gehen, um allen das Lebenleicht zu machen (auch dir selbst):

(1) Schicke eine Mail an die passende Mailing-liste und setze die relevanten Entwickler inCC;

(2) Gib ausführliche, aber relevante Informati-on;

(3) Sei hartnäckig! Aber sei auch immer freund-lich und offen für Hinweise.

Wie findet man Kernelmailinglisten und -entwickler? Führe scripts/get_maintainer.plaus den Kernelquellen aus. Sieh dir die Kernel-mailinglisten an [4]. Oder suche im Web, indemdu Worte wie ‚mailing list linux development‘ mitden passenden Themenworten kombinierst, etwa‚usb‘, ‚networking‘, ‚wirless‘ oder ‚wireless intel‘.Im Zweifel nutze die LKML (Linux Kernel MailingList, [5]).

Du kannst deine Regressions auch beim Kernel-Bugzilla [6] melden. Die Betreuer einige Subsys-temen haben den am nicht im Blick und sehenden Fehlerbericht dann nicht. In anderer Subsys-temen funktioniert das aber gut – zum Beispiel fürACPI, PCI und Powermanagement. Manche Ent-wickler benutzen auch andere Bugzilla-Instanzen,zum Beispiel die von freedesktop.org. Wenn du un-sicher bist, frag um Hilfe. Den Vortragenden die-ser Worte zum Beispiel. Aber Vorsicht – er skaliertnicht besonders gut.

Links

[1] Christian Couder: Fighting regressions with git bisect (2009). URL:https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html[2] Torvalds’ Laptopkauf: https://plus.google.com/+LinusTorvalds/posts/VZj8vxXdtfe[3] Vanilla-Kernel bei Fedora: https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories[4] Kernel-Mailinglisten: https://kernelnewbies.org/ML[5] Linux Kernel Mailing List: https://lkml.org[6] Kernel-Bugzilla: https://bugzilla.kernel.org

Über Thorsten

Thorsten Leemhuis ist seit vielen Jahren Redakteur bei c’t und Heise Open,wo er unter anderem das Kernel-Log schreibt (https://www.heise.de/thema/Kernel_Log). Der Fedora-Fan beobachtet die Kernelentwicklung seit überzehn Jahren intensiv. Neuerdings erzeugt er manchmal Listen mit Re-gressions des Mainline-Kernels, um den Kernelentwicklern die Arbeit zuerleichtern. Der schreibende und vortragende Linux-Experte ist auf vie-len Linux- und Open-Source-Veranstaltungen anzutreffen und unter <[email protected]> zu erreichen.


https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html

https://plus.google.com/+LinusTorvalds/posts/VZj8vxXdtfe

https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories

https://kernelnewbies.org/ML

https://lkml.org

https://bugzilla.kernel.org

https://www.heise.de/thema/Kernel_Log

https://www.heise.de/thema/Kernel_Log



UPTIMES SOMMER 2017 EIN GRAL FÜR DEVOPS

Ein Gral für DevOpsInfrastrukturtests automatisieren

Konfigurationsmanagement macht IT-Infrastruktur zuCode. Für Code ist Continuous Integration das Ziel.Mit Serverspec und Kitchen gelingen automatischeTests. Für die Pipeline schließen das Plugin Job DSL

von Jenkins 2.0 und das Jenkinsfile die Lücke, welcheRepo-Anbieter mit inkompatiblen Eigenentwicklungenbisher nur so naja schließen konnten.

von Christopher J. Ruwe

Nur ein schlechter Planerlaubt keine Änderung.

Publilius Syrus

Wenn Konfigurationsmanagement den Aufbauvon IT-Infrastruktur automatisiert, spricht manvon Infrastructure as Code. Solchen Code ent-wickelt und testet jemand, wie jede andere Soft-ware auch. Automatisierte Tests – die Erfahrunglehrt nämlich, ist es nicht automatisiert, wird esignoriert – müssen nah am entwickelten Code lie-gen, und zwar in demselben Code-Repository wiedas Testobjekt. Die Ausführungs-Sequenzen sol-cher Tests sind in so genannten Pipelines spezi-fiziert und werden von bestimmten Operationenauf das Repository (commit, pull, merge, etc.)getriggert.

Das Jenkinsfile ist eine solche Pipeline für denCI-Server Jenkins [1]. Baut man damit die Aus-führung von Infrastrukturtests geschickt, ist nichtnur vollständige Automatisierung des Testablau-fes möglich, sondern auch die Hochskalierungauf VM- oder Cloud-Infrastrukturen. Technischspricht nichts dagegen, die Testausführung ab-schließend um das Deployment zu erweitern – eswinkt Continuous Deployment.

Das Problem: Fehlanzeige beiInfrastrukturtests

Nicht erst seit Meyer [2] fordern progressi-ve Software-Architekten, dass Software modularkonstruiert werden sollte. Dabei wird die Funk-tion einer Applikation aus logisch abhängigen,aber technisch isolierbaren Komposita von Ein-zelkomponenten erbracht, die in der Gesamtheitdie Funktion der Software bereitstellen. Für IT-Infrastruktur drängt sich solch ein Aufbau gerade-zu auf: Moderne Server liefern tausende Prozes-se, deren Zusammenwirken mehrere Dienste de-finiert. Diese wiederum sind üblicherweise übermehrere Hosts verteilt und stellen ein klassischesverteiltes System dar [3].

In der Praxis entspricht aber weder die Metho-dik derjenigen eines modular aufgebauten verteil-ten Systems, sondern eher einer Wucherung. Nochhaben sich Techniken zur Abnahme eines solcher-maßen gebauten Systems etabliert, abgesehen vonbudgetärem Mittelabfluß und Zeitablauf als Maßfür den Projektfortschritt. Egal, ob klassisch manu-ell oder automatisiert gebaut, ähneln die entstan-denen Artefakte nach wenigen Monaten Gebäu-den, die über Jahrhunderte verwittert, erweitertund an ständig wechselnde Bedürfnisse angepasstwurden, ohne es allerdings mit dem Charme pit-toresker Ruinen aufnehmen zu können. Auf einenNachweis der Funktion verzichtet man üblicher-weise – warum auch, der Kunde zahlt ja trotzdem– und überlässt die Korrektheit dem Zufall. Würdeman mit demselben Vorgehen zum Beispiel eineProzess-Strecke in einem chemischen Werk kon-struieren, 1) könnte die Fabrik absolut gar nichtsproduzieren, 2) wären die Verantwortlichen ent-lassen worden und in Haft, 3) wären die betrof-fenen Unternehmen in den nächsten Jahren ex-tremem regulatorischen und aufsichtsrechtlichenDruck ausgesetzt.

Dem Autoren ist aus seiner Consulting-Praxiskein technisches Produkt bekannt, dem zwin-gend eine sauber konstruierte Systemarchitekturzu Grunde liegt (es sei denn, man geht zu Goo-gle oder Netflix). Nimmt man mal an, dass ei-ne IT-Infrastruktur genauso systematisch abzu-testen und abzunehmen wäre wie die Softwa-re, die sie beherbergt, dann erscheint das alsde-facto-Abnahmeverfahren akzeptierte Abwar-ten und mehr oder weniger formalisierte Her-umklicken eher untauglich. Ich habe erlebt, wieeinmal so genannte fachliche Experten den paral-lelen Neuaufbau eines Web-Frontends innerhalbvon 10 Minuten abnickten. Der Load-Balancersteuerte allerdings durch Session-Cookies jeweils



auf die letztbesuchte Strecke. Die testenden ‚Ex-perten‘ leerten grundsätzlich nie Browser-Cacheund Cookie-Store („Es geht dann schneller“). Undnatürlich verhielt sich der alte Aufbau nicht alleindeswegen anders, nur weil es daneben eine neueStrecke gab.

Manuelles Testen ist grundsätzlich nur mithöchster Disziplin reproduzierbar. Selbst dann istes für die im Cloud-Umfeld innerhalb wenigerMinuten horizontal skalierenden Systeme viel zulangsam. Seine Testergebnisse – „Die Webseitegeht nicht“– sind zu unpräzise, zu schwer zu kom-munizieren und decken oft nicht die relevantenDetails ab, die später richtig schmerzhaft werden.

Verloren geben sollte man Infrastrukturtestsdeswegen aber nicht. Automatisierungscode istSoftware. Da liegt es nahe, sich bei den Kollegenaus der Softwareentwicklung zu bedienen. Dorthat man nämlich aus langer und sehr unangeneh-mer Erfahrung mit Fehlern im Produktionspro-zess Toolsets entwickelt, Erzeugnisse bereits vorder Lieferung zu testen. Die Idee, solche Toolsetsauf die Entwicklung von Infrastruktur abzubil-den, erscheint fast schon trivial. Zwar erzwingtdas keine systematische Konstruktion. Aber zu-sätzlich zum Vorteil formaler Nachweisführungresultiert automatisches Testen methodisch früheroder später fast zwingend in einen strukturiertenAufbau.

Methodik zum Testen von IT-Infrastruktur

Tests sollten methodisch strukturiert und syste-matisch entwickelt sein. Man unterscheidet da-für zwischen dem Aufbau des Tests, der Test-ausführung und dem Testablauf (die sogenann-te Pipeline). Bei Anwendungssoftware ist es üb-lich, mehrstufig zu testen: Man beginnt mit derEinzelkomponente, fährt mit logisch zusammen-hängenden Komponenten fort und endet beimGesamtsystem aller Komponenten. Mit steigen-dem Abstraktions- und damit Komplexitätsgradspricht man von Unit-Test (Einzelkomponente),Integration-Test (Komposit) und Acceptance-Test(vollständiges System, siehe Abbildung 1).

Das lässt sich nun analog auf die IT-Infrastruktur abbilden. Beim Unit-Test könnteman die Einzelkomponente als die Konfigurati-on einer bestimmten Software auffassen, etwa ei-nes Webservers. Bei Puppet entspräche das einemmodule, bei Ansible heißt es role (Vorsicht: Der Be-griff role ist bei Puppet und Ansible wechselsei-tig inkompatibel belegt). Puppet – das mehrstufigvorgeht – kompiliert nun aus dem Code einen

so genannten Katalog und appliziert diesen an-schließend automatisch auf den Ziel-Host. DerPuppet-Katalog drängt sich als Testobjekt förm-lich auf. Größeren Puppet-Modulen liegen meist(Katalog-)Tests bei, die aus einer Menge typischerHost-Invarianten wie hostname oder architectureeinen Katalog kompilieren und diesen dann aufKorrektheit prüfen. Ansible appliziert direkt. Hiermüsste man die tatsächliche Applikation auf einenServer testen.

Abbildung 1: Testsystematik mit Unit-, Integration-und Acceptance-Test.

Für den Integration-Test auf der nächsten Stufekönnte man bei Puppet die Komposition eines ausmehreren Modulen bestehenden Konfigurations-katalogs prüfen. Die Funktion eines Webserverswird ja nicht allein durch die Webserver-Softwarebestimmt. Es gibt parallel dazu zum Beispiel noch(Funktions-)User und Gruppen, Rechte, vielleichtlogrotate-Regeln. Interessanter als der Katalog istes aber, die Konfiguration tatsächlich auf einenHost zu applizieren. Dies ist dann auch für Syste-me möglich, die nicht zweistufig kompilieren undapplizieren, also etwa Ansible. Denn hat man er-folgreich auf einen Host appliziert, weiß man nichtnur, dass der Katalog enthält, was er enthaltensoll, sondern auch, dass er auch lauffähig ist. Dar-aufhin lässt sich das Verhalten des Servers prü-fen: Ist der Webserver erfolgreich gestartet? Sindalle Ports offen, die offen sein sollen? Kann derWebserver auf die static files zugreifen? Und soweiter.

Für den Acceptance-Test ergibt sich hierauf auf-bauend methodisch keine wesentliche Änderungmehr. Der Nachweis über die Funktion der Ein-zelkomponenten ist bereits erbracht, und es bleibtzu zeigen, dass die Verbindungen zwischen ihnenkorrekt konfiguriert sind. Etwa: Kann der Webser-ver vom Applikations-Server dynamischen Con-tent abgreifen? Kann der Applikationsserver auf



die Datenbank zugreifen? Sperrt die Firewall Zu-griffe aus dem öffentlichen Internet auf die Daten-bank?

Programmierte Testausführung mitServerspec und Kitchen

Das vorhin verrissene Verfahren, semiformalisiertauf Webinterfaces herumzuklicken, wird durcheinen methodischen Rahmen ein wenig verbes-sert. Es wird aber nicht erheblich verbessert, wennin diesem methodischen Rahmen immer noch Re-produzierbarkeit fehlt, die Geschwindigkeit zu ge-ring ist oder die Kommunikation von Testergeb-nissen nicht gelingt. Stattdessen ist es – wenigs-tens bei den Kollegen Softwareentwicklern – üb-lich, mit speziellen Testframeworks das erwarte-te Verhalten eines Softwaresystems zu spezifizie-ren und dieses erwartete Verhalten programma-tisch abzutesten.

Puppet-Katalogtests prüfen zum Beispiel pro-grammatisch, ob der Code kompiliert und obdie Konfiguration einzelner Softwarekomponen-ten oder komplexerer Softwaremodule so aufge-baut ist, wie es der Absicht des Infrastrukturent-wicklers entspricht. Das folgende Beispiel ist einAuszug aus einem Puppet-Katalogtest für eineEinzelkomponente. Es prüft, ob der Katalog ei-ne Gruppe mit der Spezifikation einer logrotate-Regel enthält. Der Test nutzt die Puppet-Klasselogrotate::rule (Zeilen 04 und 05), die in denZeilen 07 bis 13 durch eine Datei mit den aufge-führten Eigenschaften (Zeilen 11 bis 13) realisiertwird:

01 describe ’logrotate::rule’ do

02 let(:title) { ’nginx’ }

03

04 it { is_expected.to

05 contain_class(’logrotate::rule’) }

06

07 it do

08 is_expected.to

09 contain_file(’/etc/logrotate.d/nginx’)

10 .with({

11 ’ensure’ => ’present’,

12 ’owner’ => ’root’,

13 <...>}

14 end

15 end

Analog zeigt folgendes Beispiel einen Puppet-Katalogtest auf ein Komposit. Es zeigt eine Reihevon Einzelprüfungen (Zeilen 03 bis 06) mit gege-benenfalls weiterführenden Spezifikationen (Zeile07):

01 describe ’role::webserver::devstage’ do

02

03 it { is_expected.to contain_class(’nginx’) }

04 it { is_expected.to contain_nginx__vhost(...) }

05 it { is_expected.to

contain_class(logrotate::rule’) }

06 it { is_expected.to contain_service(’nginx’)

07 .with_ensure(’running’) }

Ein solches Vorgehen stellt einen ersten Fort-schritt dar. Bei der Entwicklung von Puppet-Modulen, die eine bestimmte Software auf k ver-schieden Systemen konfigurieren, ist ein solcherTest unersetzlich.

Höherwertige Integrationstests erreicht manaber erst, wenn man nicht nur die entstehen-den Arbeitsanweisungen in Form des Katalogsprüft, sondern auch das Ergebnis. Im Gegensatzzum ordnungsgemäßen Verwaltungshandeln in-teressiert uns sozusagen nicht nur der Nachweisfehlerfreier Anweisung zum Bau von Flughäfen,etwa ob alle Baupläne da sind – sondern ein Flug-hafen existiert real, und es gibt Flugzeuge, die star-ten und landen. Also prüft man analog zum Bei-spiel, ob der Nutzer mit ID 2036 wirklich angelegtwerden kann, ob die User-IDs nicht bereits kolli-dierend belegt ist, oder ob der Dienst sshd nichtnur theoretisch laufen können sollen müsste, son-dern ob man sich tatsächlich einloggen kann.

Ein bewährtes Verfahren hierzu ist, sich irgend-eine Spielmaschine in der DEV-Umgebung zu su-chen (es setzt sich allmählich durch, nicht sofortam PROD-System herumzuprobieren) und diesekaputt zu fummeln, damit die Kollegen Software-entwickler an der weiteren Arbeit und damit amweiteren Produzieren von Bugs gehindert werden.Geschickter erscheint indes, eine virtuelle Maschi-ne zu erzeugen, deren Ausfall (wirklich!) nieman-den stört, auf diese Maschine die Automatisierungzu applizieren und danach mit einem Testframe-work die Funktionen abzutesten. Nach den Testskann man die Maschine wieder zerstören und so-mit in jeder Iteration unbelastet neu testen.

Aus dem Umfeld von Chef stammt für Infra-strukturtests das Werkzeug Kitchen [4]. Es hat aberviele aktiv entwickelte Plugins, sodass man diesesWerkzeug auch für andere Frameworks wie Pup-pet und Ansible verwenden kann, sowie für lokaleVMs etwa in VirtualBox oder lxd, für VMs auf dedi-zierten Maschinen via VMWare oder sogar in derCloud (EC2, GCE) [5]. Kitchen erzeugt aus einemdeklarativen Datensatz eine lokale virtualisierteUmgebung oder eine Container-isolierte Umge-bung. Automatisierungscode wird darauf schonwährend der Entwicklung iterativ und häufig ap-pliziert und erlaubt so eine Laborsituation.

Folgendes Beispiel zeigt den Auszug aus ei-ner Testhost-Deklaration. Ein provisioner kon-figuriert in den Zeilen 01 bis 08 das Automati-



sierungsframework. Zeilen 10 bis 18 geben überplatforms die Parametrisierung der Testmaschi-ne an. Schließlich binden die suites den Provi-sionierer und die Plattformen für eine spezielleRolle inklusive des dazugehörigen Tests zusam-men:

01 provisioner:

02 name: puppet_apply

03 manifests_path: examples

04 modules_path: ’modules:..’

05 hiera_data_path: hieradata

06 hiera_deep_merge: true

07 puppet_verbose: true

08 puppet_debug: false

09

10 platforms:

11 - name: debian/stretch/lxd-priv

12 driver_plugin: lxd_cli

13 driver_config:

14 image_name: puppet-base-stretch

15 profile:

16 - default

17 - privileged

18 - docker

19

20 suites:

21 - name: webserver

22 provisioner:

23 manifest: nginx/install.pp

Kitchen erzeugt also sozusagen eine Art Testla-bor. Genauso, wie Kataloge programmatisch Testsspezifizieren und ausführen, lässt sich auch dieletztliche Applikation und das Serververhalten indiesem Labor automatisiert testen. Eine Sprachbi-bliothek, die die Tests selbst beschreibt, stellt bei-spielsweise das auf Ruby basierende Serverspec [6]zur Verfügung. Serverspec ist auch für Menschenund fast schon für nicht-Techniker klar verständ-lich und prüft das Verhalten einer Software. In-nerhalb der Ruby-Libraries kann Serverspec be-kannte Unix-Kommandos ausführen (command)und matcht deren Output (stout/stderr) inbekannter Perl- oder Ruby-artiger Syntax gegeneinen regulären Ausdruck. Dies erhöht die Akzep-tanz deutlich. Dazu ist es möglich, Tests mit SSHzu verteilen [7].

Folgendes Beispiel zeigt einen Serverspec-Testauf dem konfigurierten Host. Zeilen 02 bis 05 be-schreiben den Service. Zeilen 07 bis 10 sagen, wasder angegebene Port tun soll. Und Zeilen 12 bis 15spezifizieren, wie die Prozesse des Service ausse-hen sollen:

01 describe ’Check the webserver.’ do

02 describe service(’nginx’) do

03 it { should be_enabled }

04 it { should be_running }

05 end

06

07 describe port(80) do

08 it { should be_listening.with(’tcp’) }

09 it { should be_listening.with(’tcp6’) }

10 end

11

12 describe process(’nginx’) do

13 its(:user) { should eq ’www-data’ }

14 its(:count) { should eq 4 }

15 end

16 end

Nach demselben Schema testet Serverspec dasVerhalten auf einem Client-Host durch Aufruf vonStandardkommandos. Im folgenden Beispiel be-sorgt das das Kommando curl und dessen Aus-gaben:

01 describe ’Check connections from localhost.’ do

02 describe command("curl -I http://www.cruwe.de") do

03 its(:stdout) {should match /HTTP\/1.1 301/}

04 its(:stdout) {should match /Location: https:\/\/<...>/}

05 its(:stdout) {should match /Server: nginx/}

06 its(:stdout) {should match /Content-Type: text\/html/}

07 its(:stdout) {should match /X-Clacks-Overhead:

08 GNU Terry Pratchett/}

09 end

10 end

Einfach aneinandergereiht testet Serverspec dasVerhalten eines Gesamtsystems aus mehrerenHosts:

01 describe ’Check www from localhost.’ do

02 <...>

03 end

04

05 describe ’Check app-server from frontend.’ do

06 <...>

07 end

Damit lassen sich Integrations- und Akzeptanz-tests auf mehrere Systeme mit demselben Tool-set durchführen. Wenn man sich in der Entwick-lung von Tests einigermaßen geschickt anstellt, hatman durch den Test sogar das Monitoring seinerSysteme entwickelt, dessen Notwendigkeit im Ge-gensatz zu Infrastrukturtests nur sehr selten inFrage gestellt wird. Und weil Kitchen angenehmpluggable aufgebaut ist, ist es an dieser Stelle ein-fach, lokale VM-Provider durch Hosts bei einemCloud-Provider (AWS, GCE, Azure) ohne Anpas-sung des sonstigen Testaufbaus zu substituieren,was Integrations- und Akzeptanztest auch hochskalierend automatisierbar und damit reprodu-zierbar macht.

Abhängig vom Grad der Abbildungsgenau-igkeit des Systems und der Vollständigkeit derTests verschiebt ein solches Vorgehen den Überra-schungsmoment – „Geht es, geht es nicht?“– aufeinen Zeitpunkt vor dem tatsächlichen Deploy-ment. Das ist zwar langweilig, erscheint unter Ein-beziehung kardiologischer Gesichtspunkte aller-dings charmant. Alle Maschinen eines größerenverteilten Systems lokal auf dem Entwicklerlaptopzu simulieren, ist jedenfalls nur in einfachen Fällenmöglich. Ein hochverfügbarer Kubernetes-Cluster



mit Weblogic-Applikationsservern übersteigt bei-spielsweise erwiesenermaßen die Leistungsfähig-keit vom Laptop des Autoren, dessen darauffol-gende Anfrage nach einem Gerät mit 2-Sockel-8-Kerner, 128 GByte RAM und Sherpa für die Akkusin der Budgetverhandlung unverständlicherweiseverworfen wurde.

Programmierter Testablauf (Pipeline)

Tests werden in der Praxis in erster Linie auf derlokalen Workstation des Entwicklers ausgeführt.Der manuelle Aufwand lässt sich mit Konstruk-ten analog des altbewährten Makefile auch hin-reichend gut begrenzen. Und manche Betriebe lö-sen das so entstehende Compliance-Problem mitGruppendynamik (vulgo: Code Red). Die Praxiszeigt aber auch, dass noch nicht einmal solcheTests aus Zeitdruck entweder gar nicht oder nurschluderig durchgeführt werden, oder dass Kolle-gen die Testergebnisse nicht verstehen. Natürlichist es wegen der Lokalität der Workstation auchrecht schwierig, eine übergreifende Teamsicht aufdie Testergebnisse herzustellen. Diese Teamsicht

ist aber gerade an Prüf- und Messpunkten im Ent-wicklungsprozess, den sogenannten quality gates,zwingend erforderlich.

Abbildung 2: Beispiel eines Test-Summary von Jenkins.

Also sollte man den Testablauf genauso pro-grammatisch abbilden, wie die einzelnen Testsselbst. Die Softwareentwickler bedienen sich hier-zu sogenannter Continuous-Integration-Serverwie dem weit verbreiteten Jenkins. Ein Jenkins-Server überwacht definierte Code-Repositoriesund führt bei Änderungen am Repo bestimmteProgramme oder Skripte aus, die verschiedeneAufgaben vom Testen bis hin zum Deploymentwahrnehmen. Nach Abschluss aller Schritte pu-bliziert Jenkins die Ergebnisse auf einem Webin-terface tabellarisch und mit URLs (Abbildung 2).Stakeholder können die Ergebnisse abrufen, aus-werten und hoffentlich berichtigen.

Abbildung 3: Konfiguration eines Jenkins-Jobs.

Die Konfiguration der notwendigen Testjobsüber ein Webfrontend (Abbildung 3) passt aller-dings nicht besonders gut zu den Methoden derSoftwareentwicklung. Auch die Bearbeitung vonXML-Files, dem internen Format des Jenkins, eig-



net sich eher als Maßnahme im Outplacement-Prozess (vulgo: Mobbing) denn als zielführen-de Entwicklungsmethode (Abbildung 4, zur Ab-schreckung geeignet).

Sinnvoller ist, die Konfiguration von Testjobsebenfalls im Code-Repository nahe bei den tat-sächlichen Tests zu spezifizieren. Eine Methodehierzu ist das Workflow-Plugin und die Job-DSLvon Jenkins, die beide seit Jenkins 2.0 allgemeinzur Verfügung stehen [8]. Hierbei sind die Arbeits-schritte (Stages) in Groovy in einem sogenann-ten Jenkinsfile programmiert und werden bei be-stimmtem Ereignissen ausgelöst, meist bei einerOperation auf ein Repository. Der Zusammenhangmit der programmierten Testausführung ist alsofolgender: Kitchen beschreibt und erzeugt Labor-umgebungen für Tests. Mit Serverspec lassen sichdie Tests darin beschreiben. Die Jenkins-Job-DSLund das Jenkinfile beschreiben nun den sachlichund zeitlich geordneten Ablauf der Tests in dendazugehörigen Laborumgebungen.

Abbildung 4: Interne XML-Darstellung eines Jenkins-Jobs.

In folgendem Ausschnitt aus einem Jenkinsfi-le ist zu sehen, dass die Arbeitsschritte in Formvon try-catch-finally-Ausdrücken spezifiziert sind(Zeilen 02 und 17). Zeile 03 deklariert die späte-re grafische Darstellung. Zeilen 06 und 08 bauendie Umgebung auf. Die Zeilen 10 bis 14 erzeu-gen (create), provisionieren (converge) undtesten (verify) die Applizierung eines Codes aufeinen simulierten Host, hier mit Docker. Schließ-lich stellt Zeile 18 den durch Kitchen erzeugtenXML-Output dem Jenkins-JUnit-Publisher auf ei-ner Webseite zur Verfügung. Die grafische Darstel-lung der einzelnen Arbeitsschritte (Stages) und dieGesamtzusammenfassung des Tests sind in denAbbildungen 5 und 6 zu sehen.

01 stage(’Integrate’) {

02 try{

03 wrap([$class: ’AnsiColorBuildWrapper’,

’colorMapName’: ’XTerm’]) {

04 sh ’’’#!/bin/bash -l

05

06 rvm use 2.2

07

08 eval "$(ssh-agent)"

09

10 bundle exec kitchen create docker || true

11 ssh-add ./.kitchen/docker_id_rsa

12 bundle exec kitchen create docker

13 bundle exec kitchen converge docker

14 bundle exec kitchen verify docker

15 ’’’

16 }

17 } catch (err){ } finally {

18 junit ’**/reports/xml/serverspec-result.xml’

19 }

20 }

Damit die Testanweisungen nahe an den Testsliegen, die wiederum nahe am Automatiserungs-code liegen sollten, liegt das Jenkinsfile im Code-Repository des Automatisierungscodes. Die Test-anweisungen werden dann bei Registrierung desRepos im Jenkins ausgelesen, iim Wesentlichendurch Angabe eines http(s)-Endpoints für dasRepos. So wird aus dem Repository die zugehö-rige Testkonformation für jeden Branch des Repo-sitories automatisch erzeugt, in dem eine Jenkins-file liegt. Dies erleichtert die Automatisierung derTest- und gegebenenfalls Deployment-Pipeline er-heblich. Und dies bewirkt Reproduzierbarkeit, Ge-schwindigkeit der Ausführung, Verständlichkeitder Tests und ihrer Ergebnisse sowie einen Test-horizont jenseits der kognitiven Froschperspekti-ve des einzelnen Mitarbeiters.

Abbildung 5: Darstellung der Stage-Ergebnisse.

(Keine) Alternative zum Jenkinsfile

Selbstverständlich ließen sich auch andere Tech-niken zur automatischen Durchführung von Testsnutzen. Die Test-Pipeline mit dem Jenkinsfile hatnicht nur zufällig große Ähnlichkeit mit git-hooks



im Repository eines Entwicklungsprojektes. Git-Hooks steuern vor bestimmten Schritten (commit,push, merge) Tests an, die eine bestimmte Code-Qualität im Repo erzwingen und umgekehrt dieVerschmutzung des Repos durch schlechten Codeverhindern. Außerdem gibt es ganze Produkte, dieContinuous-Integration-Pipelines zur Verfügungstellen, zum Beispiel die gitlab-ci von Gitlab.comoder die travis-ci, die durch enge Integration mitGithub.com bekannt ist. Beide sind allerdings aneinen speziellen Git-Repository-Provider gekop-pelt. Man könnte hierbei daher von Git-Hooks aufSpeed sprechen.

Im Wesentlichen ist das Angebot des Jenkins-Workflow-Plugins zu (ausgeprägten) Hooks äqui-valent, somit zu den CI-Pipelines der Repository-Provider. Alle können in der jeweiligen Spra-che der Pipeline beliebige Programme ansteuern,Programm-Output aufbereiten und grafisch dar-stellen. Alle Varianten gewährleisten, dass Testco-de und Testausführung sehr eng am eigentlichenCode entwickelt und fortgeschrieben werden kön-nen.

Git-Hooks haben sich für diese Zwecke al-lerdings nicht durchgesetzt. Am stärksten fehltihnen wohl ein (buntes?) Webinterface zur Pu-blikation von Testergebnissen. Auch die CI-Lösungen der Repository-Provider sieht der Au-tor dieser Zeilen skeptisch: Die Fragmentierungder Pipeline-Lösungen der Repositories ist wirk-lich bemerkenswert. Mit travis.ci für Github.com,gitlab-ci von Gitlab.com und der Bitbucket-Implementierung von Atlassian existieren bereitsdrei miteinander inkompatible CI-Lösungen, je-weils mit vergleichbarem Verbreitungsgrad. ImGegensatz dazu ist Jenkins in fast allen Entwick-lerprojekten anzutreffen. Damit ist Jenkins der de-facto-Standard der CI-Server. Mit der Job-DSL unddem Jenkinsfile löst er sich von grafischer Konfi-guration und schließt somit die Lücke, die vorherdie Repositories mit inkompatiblen Eigenentwick-lungen zu schließen versuchten.

Ohne formale Tests und formale Korrektheits-nachweise ist es schwer sich vorzustellen, wieman die fortschreitende Integration von IT in Ge-schäftsprozesse und in ganze Unternehmen (Stich-wort Industrie 4.0) beherrschbar gestalten soll.Von Qualität und Störungsfreiheit ist dabei nochgar nicht die Rede. Welches Werkzeug zum Ein-satz kommt, ist letzten Endes egal, solange nurendlich automatische Tests auch in der Infrastruk-turentwicklung selbstverständlich werden. Zwarversagen auch in der Softwareentwicklung dieTest- und Abnahmeprozeduren noch zu oft. Siesind aber zumindest selbstverständlich und eta-bliert. Die methodische Konvergenz von Entwick-lung und Operations stimmt hoffnungsvoll, dassauch wir das schaffen werden.

Abbildung 6: Darstellung der gesamten Testergebnisse.



Links

[1] CI-Server Jenkins: https://jenkins.io[2] Bertrand Meyer: Object-Oriented Software Construction. Upper Saddle River, Prentice Hall 1998 (2nded.).[3] Andrew S. Tanenbaum and Maarten van Steen: Distributed Systems; Principles and Paradigms. UpperSaddle River, Prentice Hall 2006 (2nd rev. ed.).[4] Kitchen: https://kitchen.ci[5] Ökosystem von Kitchen: https://github.com/test-kitchen/test-kitchen/blob/master/ECOSYSTEM.md[6] Serverspec: http://serverspec.org[7] Serverspec-Tests mit SSH verteilen: http://serverspec.org/advanced_tips.html[8] Jenkins 2.0: https://jenkins.io/2.0/

Über Christopher

Christopher J. Ruwe (Jahrgang 1928) ist freiberuflicher IT-Consultant mitden Schwerpunkten Unix und DevOps. In den aktuellen Bestrebungenvieler größerer Unternehmungen, IT-Systeme „in die Cloud zu bringen“,berät er technisch und organisatorisch zu Fragen des Deployments, derKonfiguration und des Betriebes von Software in hoch und schnell skalie-renden Umgebungen.


https://jenkins.io

https://kitchen.ci

https://github.com/test-kitchen/test-kitchen/blob/master/ECOSYSTEM.md

http://serverspec.org

http://serverspec.org/advanced_tips.html

https://jenkins.io/2.0/

UPTIMES SOMMER 2017 SHELLSKRIPTE MIT AHA-EFFEKT VIII

Shellskripte mit Aha-Effekt VIIIBash-Arrays

Auch an denjenigen, die schon über 20 Jahre mitder Bash arbeiten, sind Bash-Arrays bisher vielleichtvorbeigegangen. Dieser Artikel zeigt, wie man Arraysauch in der Bash verwenden kann, so wie von Perlund anderen Sprachen bekannt.

von Jürgen Plate

Any sufficiently advanced technology isindistinguishable from magic.

Arthur C. Clarke

Any sufficiently advanced bug isindistinguishable from a feature.

Rich Kulowiec

Arrays ermöglichen, eine geordnete Folge vonWerten eines bestimmten Typs zu speichern undzu bearbeiten. Allerdings erlaubt die Bash nur ein-dimensionale Arrays. Dabei werden zwei grund-legende Typen unterschieden: indizierte und asso-ziative Arrays.

Indizierte Arrays verwenden positive Integer-Zahlen als Index. Die Indizes sind meist sparse, al-so nicht unbedingt zusammenhängend. Wie in Cund vielen anderen Sprachen beginnen die ganz-zahligen Indizes bei 0. Indizierte Arrays gab es zu-erst bei der Bourne-ähnlichen Shell, der ksh. Sietragen immer das Attribut -a.

Assoziative Arrays (manchmal als Hash be-zeichnet) verwenden beliebige nichtleere Zeichen-ketten als Index. Diese Arrays sind immer un-geordnet, sie assoziieren nur Index-Wert-Paare.Wenn man mehrere Werte daraus abruft, kannman sich nicht darauf verlassen, dass sie in dersel-ben Reihenfolge wiedergegeben werden, in der sieeingefügt wurden. Assoziative Arrays tragen im-mer das Attribut -A. Im Gegensatz zu indiziertenArrays müssen sie immer ausdrücklich deklariertwerden.

Indizierte Arrays

Ein indiziertes Array (Feld, Vektor, Reihung) er-möglicht die Verarbeitung mehrerer gleichartigerElemente, wobei auf jedes Element über seinen In-dex eindeutig zugegriffen werden kann. Oft ver-wendet man Arrays in Schleifen, um nicht auf eineReihe von einzelnen Variablen zurückgreifen zumüssen.

Die folgenden Möglichkeiten versehen eine Va-riable mit Array-Attribut, wobei beim indiziertenArray keine Deklaration notwendig ist. Diese er-folgt meist implizit durch die Wertzuweisung:

• ARRAY=() deklariert ein indiziertes Arraynamens ARRAY und initialisiert es als leer.Dies kann auch zum Leeren eines bestehen-den Arrays verwendet werden.

• ARRAY[0]=xxx besetzt das erste Elementeines indizierten Arrays (Wertzuweisung).Wenn noch kein Array namens ARRAY exis-tiert, wird es erzeugt.

• declare -a ARRAY deklariert ein indizier-tes Array namens ARRAY. Ein bereits vor-handenes Array wird dadurch nicht initiali-siert.

Wenn Sie einer Array-Komponenten einen Wertzuweisen wollen, erfolgt dies genauso wie beiden normalen Shell-Variablen. Sie geben ledig-lich noch den Feldindex eingeschlossen in ecki-ge Klammern an. Insofern unterscheidet sich dieBash nicht von C, Perl, Python oder anderen Pro-grammiersprachen. Sie müssen lediglich darandenken, dass rechts und links vom Gleichheits-zeichen kein Leerzeichen stehen darf. Das folgen-de Beispiel belegt die dritte (!) Array-Komponentemit dem String zwo:

array[2]=zwo

Was geschieht in diesem Fall mit den Kompo-nenten array[0] und array[1]? Bei der Bash-Programmierung dürfen Arrays Lücken enthal-ten (wie auch in Perl oder anderen Interpreter-sprachen). Im Unterschied zu anderen Program-miersprachen muss man in der Bash das Arrayauch nicht vor der Verwendung deklarieren. Mansollte es jedoch trotzdem zu tun, denn einerseitskann man damit angeben, dass die Werte inner-halb eines Arrays zum Beispiel als Integer gültigsein sollen (typeset -i array), und anderer-seits lässt sich so ein Array mit Schreibschutz ver-sehen (typeset -r array).



Häufig will man beim Anlegen eines Arraysdieses mit Werten initialisieren. In der Bash erfolgtdies durch Klammern der Werte:

array=(Merkur Venus Erde Mars Jupiter Saturn)

Bei der Zuweisung beginnt der Feldindex au-tomatisch bei 0, also enthält array[0] den WertMerkur. Aber ist es auch möglich, eine Zuwei-sungsliste an einer anderen Position zu beginnen,indem der Startindex angegeben wird:

array=([2]=Pluto Eris ...)

Diese Methode ist jedoch nicht geeignet, neueElemente an ein Array anzuhängen. Ein existie-rendes Array wird immer komplett überschrieben.Die Anzahl der Elemente, die Sie einem Arrayübergeben können, ist bei der Bash beliebig. AlsTrennzeichen zwischen den einzelnen Elementendient das Leerzeichen.

Auch aus einer Datei lässt sich ein Array erzeu-gen. Das Kommando cat und $(...) heben denDateiinhalt auf die Kommandozeile und damit indie Initialisierungsliste:

array=($(cat "datendatei"))

Der Zugriff auf die einzelnen Komponenten ei-nes Arrays erinnert an C oder andere Sprachen. Ererfolgt mittels

${array[index]}

Einziger Unterschied zu anderen Sprachen: Fürdie Referenz auf den Array-Inhalt sind geschweif-te Klammern zu verwenden, da die eckigen Klam-mern ja schon Metazeichen der Bash sind (Bedin-gung analog dem test-Kommando) und sonst ei-ne Expansion auf Shell-Ebene versucht würde.

Alle Elemente eines Arrays lassen sich folgen-dermaßen ausgeben, ähnlich wie bei Kommando-zeilenparametern:

echo ${array[*]}

echo ${array[@]}

Der Unterschied ist der gleiche wie bei denKommandozeilenparametern ($* und "$"). Oh-ne Anführungszeichen expandieren beide Aus-drücke gleich, mit Anführungszeichen expandiert${array[*]} zu allen Elementen in einem, wäh-rend ${array[]} zu den einzelnen Elementen inAnführungszeichen expandiert. Das ist insbeson-dere bei for-Schleifen wichtig, die über die einzel-nen Elemente iterieren.

${!array[*]} listet alle Indizes des Arraysauf. Diese Liste ist interessant, wenn das ArrayLücken bei den Indizes aufweist. Das folgendeBeispiel listet Index und Inhalt auf:

01 for IND in ${!array[*]}

02 do

03 echo "$IND ${array[$IND]}"

04 done

Die Anzahl der belegten Elemente im Array er-hält man wie folgt (auch diese Syntax ähnelt derKommandozeile bzw. der Shell-Variablen $#):

echo ${#array[*]}

Wer feststellen will, wie lang eine Array-Komponente ist, geht genauso vor wie beim Er-mitteln der Anzahl belegter Elemente im Array,nur dass anstelle des Sternchens der entsprechen-de Feldindex zum Einsatz kommt:

echo ${#array[1]}

Array-Beispiele

Jetzt wird es aber Zeit für einige Beispiele. Zu-nächst definieren wir ein Array und füllen es mitWerten. Danach probieren wir einige der oben be-schriebenen Ausgaben:

$ array=(Merkur Venus Erde Mars Jupiter Saturn\

Uranus Neptun)

Fünfte Komponente ausgeben:

$ echo ${array[4]}

Jupiter

Wieviele Planeten sind es (ohne Pluto)?

$ echo ${#array[*]}

8

Wieviele Buchstaben hat das Wort Erde?

$ echo ${#array[2]}

4

Auch Teile eines Array lassen sich selektieren.So liefern die folgenden Ausdrücke verschiedeneSlices des Arrays:

• die Array-Komponenten von ’in-dex’ bis ’index+length-1’ inklusive:${array[@]:index:length}

• die Array-Komponenten von ’0’ bis ’length-1’ inklusive: ${array[@]::length}

• die Array-Komponenten von ’index’ bis zumEnde: ${array[@]:index}

Auch dazu einige Beispiele mit den zugehöri-gen Ausgaben:



$ array=(Merkur Venus Erde Mars \

Jupiter Saturn Uranus Neptun)

$ echo "${array[@]:2}"

Erde Mars Jupiter Saturn Uranus Neptun

$ echo "${array[@]:1:3}"

Venus Erde Mars

$ echo "${array[@]::1}"

Merkur

Löschen, kopieren und konkatenieren

Das Löschen eines Arrays oder einer Komponentesieht genauso aus wie bei den Shell-Variablen. Daskomplette Array löscht unset array. Einen In-dex anzugeben, löscht einzelne Elemente: unsetarray[index]. Das funktioniert aber nicht im-mer, wie folgendes Beispiel zeigt:


Jupiter Saturn Uranus Neptun)

$ INDEX=4

$ echo ${#array[@]}

8

$ echo ${array[$INDEX]}

Jupiter

$ unset ${array[$INDEX]}

$ echo ${#array[@]}

8

Oha! Hier sollte nun eine 7 stehen, weil unsetja den Jupiter gelöscht hat. Mal sehen:

$ echo ${array[$INDEX]}

Jupiter

Der Fehler liegt darin, dass die Bash ein Arrayals sogenannten Hash speichert (sparse). Man kannsich also nicht darauf verlassen, dass eine Kompo-nente nach dem unset tatsächlich weg ist.

Zum Kopieren eines kompletten Arrays kön-nen wir entweder eine Schleife programmieren, inder jede Komponente des einen Arrays dem an-deren Array zugewiesen wird. Es geht aber auchmit weniger Aufwand. Dafür kombinieren wir dasAuflisten aller Elemente des einen Arrays mit demZuweisen einer Liste mit Werten an ein zweitesArray:

array_neu=( ${array[@]} )

Auch hierzu ein Beispiel als interaktive Shell-Sitzung:


Jupiter Saturn)

$ echo ${array[@]}

Merkur Venus Erde Mars Jupiter Saturn

array auf yarra kopieren und yarra ausgeben:

$ yarra=( ${array[@]} )

$ echo ${yarra[@]}

Merkur Venus Erde Mars Jupiter Saturn

Das Aneinanderhängen zweier Arrays geht ge-nauso wie das Konkatenieren von Strings. Wir bil-den einfach eine Initialisierungsliste aus beidenArrays, die wir dann einem neuen Array zuwei-sen:

Gesamt=("${Array1[@]}" "${Array2[@]}")

Zwei Praxisbeispiele

Eine Liste der Dateinamen des aktuellen Verzeich-nisses bekommen wir übrigens mit der folgendenZuweisung:

Dateien=(*)

Zum Abschluss eine praktische Nutzanwen-dung für Arrays. Beim Raspberry Pi müssen dieGPIO-Ports für die parallele Ein- und Ausgabezu Beginn initialisiert werden. Sind es zahlreichePorts, macht man das am besten in einer Schlei-fe. Nur steckt die Schleife meist in den Tiefen desSkripts, und man muss für das Ändern oder Hin-zufügen von Ports erst einmal suchen. Viel war-tungsfreundlicher ist es, die Portzuordnung amAnfang des Skripts (oder sogar in einer Konfigu-rationsdatei) vorzunehmen. Das sieht dann bei-spielsweise folgendermaßen aus – hier ordnen wirPorts LEDs zu:

GPIO=(27 22 19 17 13 6 5)

Die Initialisierung der Ports erfolgt nun in ei-ner Schleife über die Array-Komponenten (Zeile02). Nach Expansion durch die Shell lautet dieseZeile for P in 27 22 19 17 13 6 5, also ei-ne ganz normale Schleifenanweisung. Die Zeilen04 bis 11 sorgen für die Initialisierung der GPIO-Ports. Der genaue Inhalt ist an dieser Stelle nichtso wichtig – hier ist nur die Anwendung der Lauf-variablen P für Port von Belang:

01 SCG=sys/class/gpio

02 for P in ${GPIO[@]}

03 do

04 if [ ! -f /$SCG/gpio${P}/direction ] ; then

05 echo "Initialisiere GPIO $P"

06 echo "$P" > /$SCG/unexport 2> /dev/null

07 echo "$P" > /$SCG/export

08 echo "out" >/$SCG/gpio${P}/direction

09 echo "0" >/$SCG/gpio${P}/value

10 chmod 666 /$SCG/gpio${P}/direction

11 chmod 666 /$SCG/gpio${P}/value

12 fi

13 done



Übrigens ließen sich mit dem BefehlPARAM=($@) auch alle Kommandozeilen-Parameter in einem Array speichern und dannwahlfrei darauf zugreifen. Das ist manchmal ein-facher als andere Methoden des Zugriffs auf dieParameter. Um das Beispiel oben weiterzuspin-nen, soll das folgende Skript für jede LED 0 oder1 angeben und diese Parameter der Reihe nachauf den oben definierten GPIO-Ports ausgeben(also der erste Parameter auf Port 27, der zweiteauf Port 22, und so weiter). Als Laufvariable dientder Index des Parameter-Arrays (Zeile 02). In derSchleife wird dann der I-te Parameter auf den I-tenGPIO-Port ausgegeben (Zeile 04 und 05):

01 PARAM=( $@ )

02 for I in ${!PARAM[@]}

03 do

04 echo ${PARAM[$I]} > \

05 /sys/class/gpio/gpio${GPIO[$I]}/value

06 done

Assoziative Arrays

Seit Version 4 gibt es in der Bash assoziative Ar-rays (manchmal als Hash bezeichnet). Man kannsie sich als Verknüpfung von zwei Arrays vorstel-len, wobei eines die Daten enthält und das ande-re die Schlüssel, welche die einzelnen Elementedes Datenarrays indizieren. Im Gegensatz zu in-dizierten Arrays müssen assoziative Arrays im-mer ausdrücklich deklariert werden. Die Anwei-sung declare -A ARRAY deklariert ein assozia-tives Array namens ARRAY.

Als Index kennen sie beliebige nichtleere Zei-chenketten. Assoziative Arrays sind immer unge-ordnet, sie assoziieren nur Index-Wert-Paare. Wermehrere Werte aus dem Array abruft, kann sichnicht darauf verlassen, dass diese in derselben Rei-henfolge wiedergegeben werden, in der sie einge-fügt wurden.

Einen Wert weisen wir genauso zu wie bei denindizierten Array, nur dass Sie hier keine Ganzzahlals Index verwenden, sondern eine Zeichenkette(Key). Zum Beispiel:

01 declare -A namen

02 namen[Donald]=Duck

03 namen[Daniel]=Düsentrieb

04 namen[Gustav]=Gans

Im Key dürfen auch Leerzeichen oder andereexotische Zeichen auftauchen. Dann ist der Keyaber in Anführungszeichen zu setzen, beispiels-weise:

05 namen["Onkel Dagobert"]=Duck

Elemente des Index können Leerzeichen so-gar am Anfang oder Ende des Strings enthalten.Index-Elemente, die nur aus Leerzeichen beste-hen, sind jedoch nicht zulässig.

Ähnlich wie bei Perl oder PHP lassen sich auchmehrere Elemente in einem Rutsch definieren:

01 declare -A namen

02 namen=(

03 [Donald]=Duck

04 [Daniel]=Düsentrieb

05 [Gustav]=Gans

06 )

Auch beim Zugriff auf den Inhalt assoziativerArrays verfährt man wie bei indizierten Arrays.Dabei sei nochmals darauf hingewiesen, dass dieReihenfolge, in der die Elemente im Array gespei-chert werden, nicht durch die Reihenfolge der Ein-tragung festgelegt ist. Um an den Inhalt eines Has-hes zu gelangen, gibt man den Key an:

echo ${namen[Donald]}

Anstelle eines konstanten Keys lässt sich aucheine Shell-Variable verwenden, zum Beispiel:

$ Key=Gustav

$ echo ${namen[$Key]}

Gustav

Ist die Variable Key nicht definiert, liefert dieBash die Fehlermeldung bad subscript. Es istalso wichtig, dass alle Variablen, die als Indexverwendet werden, auch definiert sind. Ist dage-gen der Index im Array nicht enthalten, liefert${namen[$Key]} einen leeren String. Die Exis-tenz eines Eintrags testet folgendes Skript:

01 if [ ${namen[$Key]+_} ]; then

02 echo "$Key gefunden"

03 else

04 echo "$Key nicht gefunden"

05 fi

Zeile 01 verwendet die Parametersubstitutionder Bash. Wenn das Hash-Element existiert, wer-tet die Bash den Ausdruck als _ aus, andernfallsals Nullzeichenfolge. Wer will, kann auch ‚Jawoll‘oder irgend etwas anderes anstatt des Unterstrichsinnerhalb der geschweiften Klammern verwen-den.

Es gibt noch weitere Möglichkeiten in der Bash,auf Existenz oder Fehlen von Hashes zu testen,wobei sich alle auf die Parametersubstitution stüt-zen. Das folgende Protokoll einer Sitzung zeigtzwei Alternativen:

$ declare -A ax

$ ax[foo]="bar"

$ echo ${ax[foo]:-FEHLT}

bar

$ echo ${ax[nix]:-FEHLT}

FEHLT

$ echo ${ax[foo]:+EXISTIERT}

EXISTIERT



Alle Indexschlüssel (Keys) erhält man mit-tels ${!namen[@]}, und auf die Werte kann mit${namen[@]} zugegriffen werden. Der Befehlecho ${!namen[@]} ergibt dann für das obigeBeispiel:

Daniel Gustav Donald

Die Werte dazu liefert der Befehl${namen[@]}. Man erhält die Ausgabe:

Düsentrieb Gans Duck

Die Länge eines assoziativen Arrays (im Prin-zip ist dies die Anzahl der Schlüssel) erhält manmittels ${#ARRAY[@]}. Im Beispiel von oben er-hält man also den Wert 3.

Am häufigsten wird man aber Schleifenkon-struktionen antreffen, die über Keys oder Werteiterieren. Die for-Schleife in Zeile 01 läuft über dieKeys:

01 for i in "${!namen[@]}"

02 do

03 echo $i

04 done

Ohne das Ausrufezeichen vor dem Array-Namen iteriert die Schleife in Zeile 01 über dieWerte:

01 for w in "${namen[@]}"

02 do

03 echo $w

04 done

Die folgende Schleife gibt in Zeile 03 alle Key-Werte-Paare aus:

01 for i in "${!namen[@]}"

02 do

03 echo "$i --> ${namen[$i]}"

04 done

Startet man das letzte Skript, erhält man alsAusgabe:

Daniel --> Düsentrieb

Gustav --> Gans

Donald --> Duck

Die Reihenfolge entspricht nicht der Reihenfol-ge der Eintragung. Das kann man auch mit einemweiteren Versuch demonstrieren. Fügt man nunnoch den Onkel Dagobert hinzu, liefert das Pro-gramm als Ausgabe:

Onkel Dagobert --> Duck

Daniel --> Düsentrieb

Gustav --> Gans

Donald --> Duck

Demo-Adressverwaltung

Jetzt wird es wieder Zeit für ein etwas längeresBeispiel. Das folgende Programm stellt eine einfa-che Adressverwaltung dar, wobei die Namen denSchlüssel bilden und als Wert dann die Adresse imassoziativen Array eingetragen wird.

Zur Verwaltung des Arrays stehen zwei ein-fache Funktionen zur Verfügung. Nach der De-klaration des Arrays Adresse als Hash in Zei-le 01 definieren die Zeilen 03 bis 07 die FunktionSpeichere_Adresse, die Namen und Adresseals Parameter übernimmt und im Hash ablegt. Diezweite Funktion Suche_Adresse stellt zunächstfest, ob der Name als Schlüssel gespeichert ist, undgibt daraufhin die Adresse aus (Zeilen 09 bis 14).Findet das Skript den Namen nicht, gibt es eineFehlermeldung aus und setzt den Rückgabewertauf 99 (Zeilen 15 bis 19).

Die Zeilen 21 bis 25 lesen die Adressdaten ausder Datei adressen.csv ein. Dort stehen proZeile Name und Adresse getrennt durch ein Se-mikolon. Dieses dient auch nach dem Einlesender Zeile als Trennzeichen für die beiden cut-Befehle (Zeilen 22 und 23), welche die beiden Fel-der an Speichere_Adresse übergeben. Die Zei-len 27 bis 33 fragen dann die Adressdaten mittelsSuche_Adresse ab.

01 declare -A Adresse

02

03 Speichere_Adresse ()

04 {

05 Adresse["$1"]="$2"

06 return $?

07 }

08

09 Suche_Adresse ()

10 {

11 if [ ${Adresse[$1]+_} ]

12 then

13 echo "$1’s Adresse lautet ${Adresse[$1]}."

14 return $?

15 else

16 echo "$1’s Adresse ist nicht vorhanden."

17 return 99

18 fi

19 }

20

21 while read LINE; do

22 NAME=$(echo $LINE | cut -d’;’ -f1)

23 ADDR=$(echo $LINE | cut -d’;’ -f2)

24 Speichere_Adresse "$NAME" "$ADDR"

25 done < adressen.csv

26

27 Suche_Adresse "Donald Duck"

28 Suche_Adresse "Harry Potter"

29 Suche_Adresse "Jules Maigret"

30 Suche_Adresse "Sherlock Holmes"

31 Suche_Adresse "Herman Munster"

32 Suche_Adresse "Thomas A. Edison"

33 Suche_Adresse "John Doe"

Das folgende Listing zeigt die Ausgabe des Pro-gramms:



Donald Duck’s Adresse lautet Flower Road 13, \

Duckburg, Callisota.

Harry Potter’s Adresse lautet Privet Drive 4, \

Little Whinging, UK.

Jules Maigret’s Adresse lautet Boulevard \

Richard-Lenoir 132, Paris, FR.

Sherlock Holmes’s Adresse lautet Baker Street \

221b, London, UK.

Herman Munster’s Adresse lautet Mockingbird \

Lane 1313, Mockingbird Heights, USA.

Thomas A. Edison’s Adresse lautet 37 Christie \

Street, Menlo Parc, NJ, USA.

John Doe’s Adresse ist nicht vorhanden.

Lösch- und Umwandlungsoperationen

Um ein assoziatives Array zu löschen, genügt esnicht, das Array neu zu deklarieren. Diese Re-Deklaration bewirkt eigentlich gar nichts. Das fol-gende Programm gibt zweimal bar aus:

01 declare -A ARRAY

02 ARRAY[foo]=bar

03 echo ${ARRAY[foo]}

04

05 declare -A ARRAY


Stattdessen ist das assoziative Array mittelsunset gänzlich aus dem Gedächtnis der Bash zuentfernen und dann natürlich neu zu deklarieren.Beim Programm kommt so die Zeile 05 hinzu:

01 declare -A ARRAY

02 ARRAY[foo]=bar


04

05 unset ARRAY

06 declare -A ARRAY


Meist will man jedoch nicht das ganze Array lö-schen, sondern nur einzelne Einträge. Dies erfolgtfast auf die gleiche Art und Weise wie oben, je-doch mit dem Unterschied, dass man bei unsetden Schlüssel des zu löschenden Eintrags angibt.Beim folgenden Programm löscht Zeile 11 den Ein-trag zwei:

01 declare -A ARRAY

02 ARRAY=([eins]=one

03 [zwei]=two

04 [drei]=three)

05

06 echo ${ARRAY[eins]}

07 echo ${ARRAY[zwei]}

08 echo ${ARRAY[drei]}

09 echo ""

10

11 unset ARRAY[zwei]

12 echo ${ARRAY[eins]}

13 echo ${ARRAY[zwei]}

14 echo ${ARRAY[drei]}

Enthält der Schlüssel Leerzeichen oder ande-re Sonderzeichen, muss er in Gänsefüßchen oderApostrophe eingeschlossen werden, was auch gilt,

wenn man den Schlüssel als Variable übergibt,zum Beispiel:

unset ["Donald Duck"]

unset [’Donald Duck’]

unset ["$Key"]

Man kann sogar ein assoziatives Array in einindiziertes Array konvertieren – wenn auch mitunvorhersagbarem Ergebnis, was die Reihenfolgebetrifft. Folgendes Beispiel deklariert ein assozia-tives Array,füllt es und gibt es aus (Zeilen 01 bis09). Zeile 11 erzeugt die Zuweisung aus ARRAY einindiziertes Array KEYS. Zu beachten sind die run-den Klammern, die den Effekt bewirken:

01 declare -A ARRAY

02 ARRAY=(["eins"]="one"

03 ["zwei"]="two"

04 ["drei"]="three")

05

06 echo "Ausgabe ARRAY"

07 for K in ${!ARRAY[@]}; do

08 echo "$K --> ${ARRAY[$K]}"

09 done

10

11 KEYS=( ${!ARRAY[@]} )

12

13 echo ""

14 echo "Ausgabe KEYS"

15 for K in 0 1 2; do

16 echo "$K --> ${KEYS[$K]}"

17 done

Die Ausgabe des indizierten Arrays in den Zei-len 14 bis 17 zeigt, dass die Reihenfolge der Spei-cherung im Hash wieder mal nicht der Eingabe-reihenfolge entsprach, und daher das indizierteArray vielleicht nicht ganz den Vorstellungen desProgrammierers entspricht:

Ausgabe ARRAY

zwei --> two

eins --> one

drei --> three

Ausgabe KEYS

0 --> zwei

1 --> eins

2 --> drei

Anwendungen für Hashes

Wofür sind die assoziativen Arrays (Hashes) ei-gentlich wirklich gut? Hashes sind nützlicher alsArrays, wenn man auf ein Element lieber mit ei-ner expliziten Bezeichnung (einem Schlüssel) alsmit einem bloßen numerischen Index zugreifenmöchte. Eine Anwendung ist die Prüfung, ob bei-spielsweise Schlüssel(worte) in einer Datei vor-handen sind. In solche Fällen kommt es nur aufden Schlüssel und nicht auf den Wert an. Ein ty-pisches Beispiel wäre das Erstellen einer Wortlis-te aus einer Datei. Hierbei kommt es nur auf dieWorte an und nicht auf deren Häufigkeit.



Das folgende Programm hat eine ähnlicheFunktion wie das Unix-Kommando uniq. Es spei-chert jedes Wort nur ein mal, egal wie häufiges vorkommt. Das Beispielprogramm geht davonaus, dass in einer Datei jeweils nur ein Wort in je-der Zeile steht.

Die ganze Magie verbirgt sich in Zeile 05. Siespeichert das gelesene Wort als Schüssel, wobeider Wert beliebig sein darf. Ist der Schlüssel neu,bekommt der Hash ein weiteres Element, ist erdagegen schon vorhanden, wird der Hash nichterweitert. Die Ausgabe (Zeilen 08 bis 11) kennenwir nun schon aus anderen Programmen. Diesmalwurde nur eine Sortierung nachgeschaltet.

01 declare -A STAT

02

03 # Worte einlesen

04 while read WORT; do

05 STAT[$WORT]=1

06 done < text

07

08 # Kontrollausgabe

09 for I in ${!STAT[@]}; do

10 echo "$I"

11 done | sort

Es gehört zwar nicht direkt zu Thema, aber viel-leicht fragt sich manch einer, wie man eine norma-le Textdatei so in Worte aufsplittet, dass sich in je-der Zeile genau ein Wort befindet. Hier hilft dasTool tr. Das folgende Skript (ein Einzeiler, der zurErläuterung mehrzeilig geschrieben wird) erstelltaus einer beliebigen Textdatei eine Wortliste. InZeile 01 ersetzt tr mehrere aufeinander folgendeLeerzeichen durch ein einziges. In Zeile 02 entferntes alle Satzzeichen und Zahlen (alles bis auf dieBuchstaben). In Zeile 03 wandelt es die Leerzei-chen zu Newline-Zeichen. Schließlich wird nochsortiert, und dann entfernt uniq die Doubletten:

01: cat $DATEI | tr -s ’ ’ ’ ’ | \

02: tr -d ’ ’-’@’ | \

03: tr ’ ’ ’\n’ | \

04: sort | uniq

Eine weitere typische Anwendung ist das Er-stellen einer Häufigkeitsstatistik. Bei jedem Auf-treten eines Schlüssels wird diesmal der Wert in-krementiert, und schon hat man die Häufigkeitender Schlüssel ermittelt. Das soll eine fiktive No-tenstatistik demonstrieren. Fiktiv ist die Statistikdeshalb, weil die Datendatei per Skript und derRANDOM-Variablen erzeugt entstand. Deshalb gibtes auch keine Normalverteilung.

Zuerst werden die Noten wieder per Schleife inden Zeilen 08 bis 11 eingelesen. Im Gegensatz zumBeispiel oben wird jedoch der Wert inkrementiert(Zeile 09). Deshalb listet die Kontrollausgabe (Zei-len 13 bis 19) diesmal auch Schlüssel und Wert auf.

Womit der gewünschte Zweck eigentlich schon er-füllt wäre.

Weil aber bei der Ausgabe von Häufigkeitengerne ein Histogramm erzeugt wird, ist das Skriptentsprechend gepimpt. Zuerst ermittelt es in denZeilen 21 bis 27 das Maximum der Werte. Dannkann nämlich die Länge der Histogramm-Balkennormiert werden. Die Variable HMAX legt die ma-ximale Länge fest, sie ist in Zeile 04 definiert. Zu-sammen mit dem ermittelten Maximum MAX kanndann die Länge des Balkens für einen bestimmtenWert nach der Formel

LEN =

Wert ∗HMAX

MAX

ermittelt werden. Das wird in der Schleife überalle Schlüssel erledigt (Zeilen 29 bis 38). Um dasHistogramm zu zeichnen, gibt die innere Schlei-fe LEN mal ein Doppelkreuz aus (Zeilen 34 bis 36).Ganz zum Schluss wird das Histogramm nach No-ten sortiert:

01 declare -A STAT

02

03 # Max. Länge eines Histogrammbalkens

04 HMAX=40

05

06 # Noten einlesen

07 COUNT=0

08 while read NOTE; do

09 STAT[$NOTE]=$(( ${STAT[$NOTE]} + 1 ))

10 COUNT=$(( $COUNT + 1 ))

11 done < noten

12

13 # Ausgabe: Note, Anzahl (unsortiert)


15 echo "$I ${STAT[$I]}"

16 done

17

18 # Gesamtanzahl ausgeben

19 echo $COUNT

20

21 # Maximalwert der Anzahlen bestimmen

22 MAX=0


24 if [ ${STAT[$I]} -gt $MAX ]; then

25 MAX=${STAT[$I]}

26 fi

27 done

28

29 # Histogramm ausgeben (sortiert)

30 echo ""


32 echo -n "$I (${STAT[$I]}): "

33 LEN=$(( ${STAT[$I]} * $HMAX / $MAX ))

34 for K in $(seq 1 $LEN); do

35 echo -n "#"

36 done

37 echo ""

38 done | sort

Zum Testen generieren wir 1000 Notenwer-te, die das Skript klaglos schluckt. Die Ausgabezeigt, wie schon erwähnt, nicht die zu erwarten-de Normalverteilung, sondern eine relativ ordent-liche Gleichverteilung:



3,7 81

5,0 82

3,3 76

3,0 86

2,7 87

2,3 76

2,0 81

4,0 70

4,3 65

4,7 61

1,7 71

1,0 81

1,3 83

1000

1,0 (81): #####################################

1,3 (83): ######################################

1,7 (71): ################################

2,0 (81): #####################################

2,3 (76): ##################################

2,7 (87): ########################################

3,0 (86): #######################################

3,3 (76): ##################################

3,7 (81): #####################################

4,0 (70): ################################

4,3 (65): #############################

4,7 (61): ############################

5,0 (82): #####################################

Eine Bemerkung zum Schluss: Wer anfängt, mitder Bash zu spielen, und verzweifelt, weil dasSkript nicht läuft, denkt an den Aufruf bash -vx

skriptname. Hier listet die Bash auf, wie sie beijeder Zeile die Parameter ersetzt und was bei derAusführung dieser Zeile geschieht. Wenn das im-mer noch nicht hilft, macht man es wie früherdie BASIC-Programmierer: Zeile für Zeile einge-ben und ständig das Programm laufen lassen (pro-gramming by try and error).

Über Jürgen

Jürgen Plate ist Professor für Elektro- und Informationstechnik an derHochschule für angewandte Wissenschaften München. Er beschäftigt sich seit1980 mit Datenfernübertragung und war, bevor der Internetanschluss fürPrivatpersonen möglich wurde, in der Mailboxszene aktiv. Unter anderemhat er eine der ersten öffentlichen Mailboxen – TEDAS der mc-Redaktion –programmiert und 1984 in Betrieb genommen.


UPTIMES SOMMER 2017 SUPPORT VERMARKTEN

Support vermarktenDas Thomas-Krenn-Wiki als Beispiel fürContent Marketing

Das in einem Unternehmen vorhandene Wissengehört zu seinem Kapital: Jeder nickt. Dieses Wissenauch zu Marketingzwecken zu nutzen, schlägt zweiFliegen mit einer Klappe: Einige stutzen. DiesesVorgehen kostet Zeit und Geld: Alle gehen. Außer dieThomas Krenn AG, die weiß, wie es geht.

von Anika Kehrer

Es ist Zeitverschwendung,etwas Mittelmäßiges zu machen.

Madonna

Der Begriff Content-Marketing ist erst ein paar Jah-re in Verwendung, die Methode jedoch viel äl-ter. Kundenmagazine sind ein klassisches Beispiel,Unternehmensblogs ein eher neueres. Unter Con-tent Marketing sind nämlich Inhalte (Content) zuverstehen, die bei potenziellen Kunden die Be-kanntheit und wahrgenommene Attraktivität ei-nes Produktes fördern (Marketing).

Das kann auf unterschiedlichste Weise gesche-hen. Prinzipiell kann der in einem gedrucktenPressepublikation veröffentlichte Fachartikel ei-nes Technikmitarbeiters dieses Ziel genauso errei-chen, wie das Glossar eines Marketingmitarbeitersauf der unternehmenseigenen Webseite: Derjeni-ge, der interessanten Content erstellt, kann einenMarketingeffekt für sich oder sein Produkt erzie-len.

Rufen wir uns nun IT-lastige Firmen vor Au-gen. Solche, bei denen wir überwiegend Consul-tants, Ingenieure, Software-Entwickler und viel-leicht noch Produktmanager haben. Wir habenAdmins und Architekten. Wir haben jede erdenk-liche Tonart von Techsprech und jeden erdenk-lichen Grad von Systematik, und wir haben ei-ne Welt von Codezeilen, Konfigurationsinterfa-ces, Kommunikationsprotokollen und Hardware-Specs. Man sollte meinen – und die Autorin ist da-von überzeugt – dass in solche einer Welt zwangs-läufig ein üppiger Garten an Ereignissen undSachverhalten blüht, die für thematisch Interes-sierte von Belang sind, sowohl in der Sache, alsauch als Genuss. Potentielle Inhalte im Sinne desContent-Marketing also.

Solche Inhalte nicht nur zu haben, sondernauch aufzubereiten, stellen sich viele allerdingseher leicht vor. Vielleicht steht dahinter der Me-chanismus, Gewerke zu unterschätzen, die mannicht oder nicht gut kennt. Während Kunden-magazine von Marketingabteilungen mit eini-

gem Aufwand erstellt werden, sieht die Vorstel-lung von Content-Marketing-interessierten Ver-antwortlichen in IT-Firmen eher so aus: Ein paarder Techies schreiben halt was nebenbei. Höchs-tens muss man das dann noch sprachlich ein we-nig geradeziehen.

Diese Auffassung unterschätzt jedoch, dass je-der Autor eine Menge Zeit benötigt, ganz zuschweigen von bestimmten schreiberischen Fä-higkeiten. Wie man Qualitätssicherung eines Tex-tes vornimmt, welche Wirkung man mit welcherSchreibmethode erzielt, oder was ein Leser mög-licherweise überhaupt interessant findet, gehörtnicht zum IT-Handwerk, und auch nicht zwin-gend zur jedermanns Talentrepertoire.

IT-Dokumentation trifft Schreibinteresse

Man kann es also als erstaunlich bezeichnen, dassFirmen manchmal trotzdem der Meinung sind, je-nes andere Handwerk nebenbei mitausführen zukönnen. Umso erbaulicher ist zu sehen, dass man-che es schaffen. Ein Beispiel ist der Serverherstellerund -dienstleister Thomas Krenn AG (Abbildung1) mit seinem Thomas-Krenn-Wiki [1].

Es besteht aus konkreten Anleitungen, wieman sie herkömmlich in einer Support-Datenbankverpacken würde, und ergänzt sie mit Wissens-stücken über Technik und Technologien, die mansie ansonsten in Fachartikeln findet. Mit demNutzwert für den Leser erzielt das Thomas-Krenn-Wiki Erfolg. Bei genauerem Hinsehen verläuft dasaber weder einfach mal so, noch nebenbei. Und ge-plant war es schon gar nicht. Aber es wurde kon-sequent begleitet.



Abbildung 1: Die Thomas Krenn AG im bayerischenFreyung, 2002 gegründet, 160 Mitarbeiter. (Foto: Tho-mas Krenn AG)

Bei Thomas Krenn hat der diplomierte Com-putersicherheitsfachmann Werner Fischer im Jahr2005 nach seinem Studium als IT-Technologe an-gefangen. Gemeinsam mit einem Kollegen hat erzum Beispiel Abläufe automatisiert und monitort.Die Tools, die dabei zum Einsatz kamen, wurdenvon diversen Linux-Distributionen unterstützt. Soentstand beispielsweise der Bedarf zu notieren,welcher Port wo zum Einsatz kommt – ein Fallklassischer IT-Dokumentation. Das war der Ur-sprung des Thomas-Krenn-Wikis, wie ihn Fischerbei einem Vortrag auf dem FFG 2017 berichtet hat[2]. Die Wikistartseite datiert laut Seiteninforma-tionen auf den 22. Februar 2008 [3]. Ein gutes Jahrspäter begann die Firma, neue Wikiartikel untereinem eigenen Account zu twittern [4]. Wieder einJahr später, im Jahr 2010, gab es sogar eine Presse-mitteilung zum Thomas-Krenn-Wiki [5].

Inzwischen arbeitet Fischer im Bereich Com-munications/Knowledge Transfer des Unternehmens.Einen Hang zum Schreiben bringt er offen-sichtlich mit, da er seit 2006 Fachartikel inverschiedenen Medien publiziert. Interessant istdennoch, dass es zum Beispiel zum Thomas-Krenn-Kundenmagazin, das zwischen 2012 und2014 erschienen ist [6], offenbar keinerlei sepa-rate Ankündigung oder Hintergrundinformationgibt. Außerdem existiert auf dem Thomas-Krenn-Webauftritt die Rubrik tkmag [7]. Dahinter verbirgtsich ein Online-Fachmagazin, ebenfalls ohne wei-tere Selbstbeschreibung oder eigene Pressemittei-lung. Es wartet mit eigenen Artikeln auf, wozuauch Darreichungen wie eine kleine SSH-Referenzgehören. Die Wikiartikel blendet es ein und ver-linkt auf sie.

Ohne Zugangshürden

Allerdings muss sich der Leser bei einigen Online-Artikeln des tkmag registrieren. Beim Wiki ist dasnicht der Fall. Wäre auch komisch für ein Wiki.

Aber wie Fischer im Vortrag erklärte, ist das ge-wollt und mit Absicht so: Die Wikiinformationensollen leicht zugänglich sein, Service-Orientierunghabe Vorrang. Es stellt sich natürlich die Frage,warum das bei den tkmag-Artikeln anders seinsollte. Aber viele Unternehmen stellen manche In-halte hinter eine Registration Wall, zumeist Whi-tepaper und Webinare. Ist schließlich ihr gutesRecht. Sie werden ihre Gründe haben, auch wennnicht jeder stets den Sinn erkennen kann.

Zudem hat man mit dem tkmag augenschein-lich etwas anderes im Sinn als mit dem Wiki. Daserwähnte SSH-Sheet (Abbildung 2) ist zum Bei-spiel nicht im Wiki zu finden. Das Wiki besitztim Gegensatz zum tkmag einen eigenen Twitter-feed, der aber im Wiki selbst gar nicht bewor-ben wird. Auch ist das Wiki mehrsprachig, dastkmag nicht. Denkbar und nachvollziehbar ist, dassdas Unternehmen an der Abgrenzung tüftelt, wel-ches Medium wie welchen Zweck am besten er-füllt. Content-Marketing betreibt es jedenfalls be-reits auf recht differenziertem Niveau.

Abbildung 2: SSH Cheat Sheet von Thomas Krenn –nicht im Wiki, aber im tkmag [8]. ( c© Thomas Krenn AG,CC-BY-SA)

Das Thomas-Krenn-Wiki erfuhr jedenfalls imUnterschied zum tkmag viel öffentliche Aufmerk-samkeit – nicht nur vom Unternehmen selbst, son-dern auch von Lesern. Die Zugriffszahlen hättenzum Beispiel schnell die des Shops überstiegen,berichtete Fischer in seinem Vortrag. Die Zahl derInhaltsseiten – der Content also – liegt derzeitbei etwa 1.700. Im Monat Februar 2017 verzeich-nete dieser Content laut Fischers Angaben rund500.000 Seitenaufrufe von etwa 250.000 Usern.Sämtlichen dieser User hat Thomas Krenn einenDienst erwiesen und sein Angebot damit positivin Erscheinung gebracht – sprich: Marketing ge-macht.



Allerdings: Ob der Konsument eines Inhaltswirklich das Gefühl hat, dass ihm ein Dienst er-wiesen wird, hängt davon ab, ob ihm das Ganzeauch etwas bringt. Beim Thomas-Krenn-Wiki hatman sich Nutzwert auf die Fahnen geschrieben(Red Bull oder Coca Cola zum Beispiel setzen statt-dessen auf Unterhaltung). Absicht und Ergebnissind nun nicht immer deckungsgleich. Doch Tho-mas Krenn schafft es. Was bei Fischers Vortrag in-teressant war, ist das Ausmaß der Qualitätssiche-rung, die das Unternehmen dafür in die Wikiarti-kel zu investieren bereit ist.

Mit Qualitätskontrolle

Die Inhalte des Wikis (Abbildung 3), wie sie ur-sprünglich angedacht waren, sind denkbar gera-deheraus: „Information zu Installationen und zubekannten Problemen und Lösungsansätzen“. Soliest es sich auf der Wikistartseite in den erstenVersionen von 2008 (wenn man in die Versionsge-schichte der Seite lugt). Bis 2017 hat sich der Inhaltzu folgendem Umfang gemausert, wie es auf derheutigen Version der Startseite zu lesen ist: „Hierfinden Sie das gesammelte Know-how der Mitar-beiter der Thomas-Krenn.AG. Die Artikel reichenvon Installations- und Konfigurationsanleitungenüber technischen Erklärungen bis hin zu konkre-ten Problemlösungen.“

Eine reife Leistung. Und ein Satz, wie er in ei-nem Content-Marketing-Konzept stehen könnte.Tut er aber nicht – und tat er nie. Das Ergebnis fußtstattdessen auf freier Initiative und überlegter Be-gleitung.

Bei seinem Vortrag friemelte Werner Fischerzum Beispiel ausführlich auseinander, wie er mög-liche Themen und Quellen bewertet – etwa nachAktualität, Zeitersparnis und Technik. Er berichte-te, dass irgendwo gefundene Lösungen für Proble-me stets erst nachgestellt werden, bevor sie – ge-prüft und verifiziert – ins Wiki wandern. Zuletzthat das Wikiteam eine Art Redaktionsplan für Ak-tualisierungsbedarf und Revision eingeführt: An-hand einer Wiki-Kategorie, etwa Review QI 2017,sammeln sie Softwareartikel, von denen sie zumBeispiel wissen, dass eine neue Softwareversionansteht.

Der Referent gab zu, dass sie zwar nicht un-bedingt hinterher kommen. Aber solche zeitlichenRessourcen kann man erst planen, wenn Trans-parenz besteht, was eigentlich zu tun ist. Geradebei Wikis droht bekanntlich ziemlich schnell ei-ne ziemlich tötliche Wucherung der Inhalte, teils

durch Veralterung bedingt. Alte Softwareversio-nen erhalten vom Wikiteam bei Thomas Krenn zurEindämmung einen Hinweis, dass die Info nichtmehr gepflegt wird.

Abbildung 3: Die 20 beliebtesten Artikel im Thomas-Krenn-Wiki.

A propos Wucherung: An welchem Ort inder Themenstruktur ein Artikel landet, entpupptsich im Thomas-Krenn-Wiki als Bestandteil quali-tätsorientierter Content-Produktion. Fischer zähl-te nämlich bewusstes Strukturieren und Einord-nen des Inhalts zu den Punkten, die zu nachhalti-gem Dokumentieren führen – mithin zu einer sau-beren Ablage. Praktisch hat das zum einen den Ef-fekt, einen klaren und vor allem beständigen URLzu gewährleisten („Cool URIs don’t change“, zi-tierte der Referent Tim Berners-Lee). Nicht nurvom Leser, auch von Google würden gleichblei-bende Webadressen honoriert, erklärte Fischer –und die Auffindbarkeit bei Google ist bei einer freizugänglichen Wissensressource nicht nur marke-tingrelevant, sondern vor allem in der Sache das Aund O. Zum anderen zwingt das aber den Schrei-benden, sich Gedanken zu machen, worüber er ei-gentlich schreibt und wie es einzuordnen ist.

Schreiben für den Leser

Fischers Tipps für nachhaltiges Dokumentierenlauten in vielen Teilen genauso, wie sie auch ge-nerell für gutes Schreiben lauten würden. Das istnämlich eine Art zu schreiben, die (mindestens)dem Leser erleichtert, das Geschriebene zu lesenund zu verstehen. Es ist also sozusagen wurscht,ob du für das Thomas-Krenn-Wiki schreibst, oderetwa eine Produkterklärung im Social-Media-Kanal deines Unternehmens. Laut Werner Fischer



führen zum Beispiel folgende Tipps zu nützlicherWissensdarbietung:

• Struktur: Klarer Gegenstand, klares Ziel, kla-rer Kontext.

• Inhalt: Problemlösung, aber auch Grundla-genexkurse, die vielleicht anderswo wiederwichtig werden.

• Aufbau: Einleitung, knappe und informativeÜberschriften, vom Allgemeinen zum Spezi-ellen.

• Stil: Kurze Sätze, Beispiele, Belege.

• Rechtschreibkorrektur.

• Mehraugenprinzip.

Als Extratipp legte der Referent den ZuhörernBilder mit Pfeilen und Erklärungen ans Herz. Erwusste zu berichten, dass eine Grafik schon malzu tagelanger Arbeit ausartet (Abbildung 4) – undschmunzelte dabei. Tatsächlich ist das aber, ver-packt in eine Randbemerkung, ein wesentlicherund oft unterschätzter Mechanismus in der Pro-duktion guter Inhalte: Es dauert nicht nur, dasGanze zu verstehen. Sondern es dauert auch ganzerstaunlich lange, das Ganze sinnvoll aufzuberei-ten.

Einen interessanten Effekt beschrieb der Refe-rent hinsichtlich der Sorgsamkeit bei der Kategori-sierung der Wikiartikel. Es hat, berichtete er, einengroßen Unterschied bedeutet, ob die Wikiautorenfür ein internes oder ein öffentliches Wiki schrie-ben. Eine Zeit lang habe Thomas Krenn nämlichauch ein internes Wiki betrieben. Hierbei sind dieKategorien explodiert – es ist also das passiert,was man als Wucherung kennt. Die Autoren sindoffenbar weniger sorgsam mit der Einordnung ih-rer Beiträge umgegangen. Aber bei dem externenWiki reißen sich die Leute offenbar mehr zusam-men. Als entscheidenden Unterschied vermuteteder Referent außerdem, dass beim externen Wikistets Peer Review stattfand, beim internen nicht.Es lag hingegen nicht daran, wie der Referent aufNachfrage erklärte, dass bei dem internen Wikimehr Autoren zu Gange waren – nach dem Mot-to, viele Köche verderben den Brei. Die Zahl derAutoren war vielmehr in etwa gleich.

Ja, und wer schreibt den Kram?

Die Autoren. Das brisanteste Stichwort beim The-ma Content-Produktion fällt zum Schluss. Plä-ne, Regeln und ausgeklügelte QA-Prozesse nützennichts, wenn niemand da ist, der Texte schreibt

(oder Grafiken erstellt). Die entscheidende Frageist hier, wen im Unternehmen man zum Autorenabstellt, der bitteschön regelmäßig liefern soll. Istes der Consultant? Er sitzt schließlich an der Quel-le immer neuer und interessanter Problemstellun-gen. Ist es ein Opsler? Er kennt die Konfiguratio-nen und hilfreiche Tunes. Ist es die Produktma-nagerin? Die weiß, was der Kunde wirklich will.Oder das Marketing? Hier würde man das tradi-tionell am ehesten ansiedeln.

Abbildung 4: In dieser Grafik stecken mehrere Perso-nentage. ( c© Thomas Krenn AG, CC-BY-SA)

Im Windschatten der Aufmerksamkeit gibt esda aber noch jemanden: den Support. Und beiThomas Krenn sind die Autoren – neben schrei-binteressierten Technikern – tatsächlich der Sup-port. Interessanterweise sind die Supportkolle-gen auch diejenigen, die von der reinen IT-Dokumentation als Quelle enorm unterschätztwerden. Das lernt man zumindest, wenn manKonferenzen besucht, die sich mit Technischer Do-kumentation befassen. Ein Vortrag auf einer sol-chen Konferenz gab mal Folgendes zu bedenken,sinngemäß wiedergegeben, zugespitzt auf einenverzeifelten Ausruf: ‚Der Support hört die Proble-me und Fragen der Kunden jeden einzelnen Tag.Nutzt das doch! Im Büro sitzt der Support oft amanderen Ende des Flurs von Entwicklung und Do-kumentation. Warum nur, ach, warum? ‘



Abbildung 5: Glückliche Leser sind potenzielle Kunden.

Bei Thomas Krenn funktioniert es offenbar er-staunlich gut, dass die Supportleute Artikel schrei-ben. Es ist aber auch so, dass sie einen Bonus be-kommen, wenn ihr Artikel viel angeklickt wird,wie der Referent dankenswerterweise verriet.

Als Verantwortlicher rümpft man nun vielleichtdie Nase und wirft die Hände hoch, warum dennimmer alles vom Geld abhängen muss. Aber wo-von denn sonst? Wir gehen schließlich arbeiten,um Geld zu verdienen – und zwar in der Arbeits-zeit, nicht in unbezahlten Überstunden. Die Zeit,die das Schreiben kostet, halst sich niemand auf,der nicht muss (und dann wird es verständlicher-weise nicht besonders gut) oder keinen besonde-ren Anreiz dafür hat. Allerdings liegt auch ein ei-gentlich ziemlich naheliegender Trick darin, die-jenigen zum Schreiben zu ermuntern, die sowie-so schon den ganzen Tag Dinge erklären. Wenndann noch Einzelne aus anderen Abteilungen hin-zukommen, die einfach gern schreiben, sollte dieAutorenzahl brauchbar werden.

Vielleicht spielt auch Folgendes eine Rolle: DasGanze läuft nicht unter Marketing. Wenn Wer-ner Fischer Vorträge über das Thomas-Krenn-Wikihält, hört man nichts von „Vorteilen“, dass alles„einfach“ sei oder das irgendjemand von irgendet-was „profitiert“ – blumige Begriffe, die mit Duftlocken wollen, aber dann eben leider auch oft luf-tig bleiben, weil sie den behaupteten Mehrwertzwar behaupten, aber nicht belegen. Stattdessenist bei Fischer von „Dokumentation“, „Relevanz“und „Support“ die Rede.

Wenn man Marketing also tatsächlich am Inhaltaufhängt, ist es auch kein Wunder, dass man ihn

stolz öffentlich bewerben kann, ohne dass es ko-misch wirkt. Wissen und Problemlösung als Ser-vice gehört in die Kategorie Tue Gutes und rede dar-über. Dass jeder Leser ein potenzieller Kunde ist,ist die Triebfeder des Ganzen, wirkt aber nicht sobemüht wie so manche Produktbroschüre, und er-zeugt auch kein solches Hintenrumgefühl wie Ad-vertorials oder Native Ads.

Die Früchte erntet das Unternehmen ThomasKrenn sichtbar in Form von klassischen Leserstim-men (Abbildung 5). Seit 2015 sammelt die Über-Seite des Wikis Feedback [9]. Jeder Autor würdesich baden in Wertungen wie dieser: „Das ist eineder besten Zusammenfassungen zu dem Thema,die ich bislang gelesen habe.“ Und war da nichtauch was mit Marketing, also zum Beispiel Mar-kenbildung und Image-Pflege? Dafür ist es wich-tig, dass der Name fällt. Und, ah, sieh mal an:„Es ist immer wieder eine Freude, auf thomas-krenn.com Einführungen in die verschiedenstenThemen zu lesen“, setzt der Kommentator nocheinen drauf. Da wird der Unternehmensname inein denkbar positives Licht gerückt. Mission ac-complished.

Offenlegung von Interessenverflechtungen: Die Au-torin kennt das Unternehmen, das Gegenstand diesesArtikels ist, sowie den im Artikel erwähnten Vortrags-referenten in ihrer Eigenschaft als LinuxTag-Mitglied.Sie hat ihm im Jahr 2013 persönlich die Ehrung ‚Linux-Tag Hero‘ überreicht, die sie ihm für Thomas Krennswiederholte Open-Source-Förderung auf dem LinuxTagverliehen hat. Vom Thomas-Krenn-Wiki waren dieseBegegnungen unabhängig: Auf das Thema des Wikisstieß die Autorin durch Werner Fischers Vortrag aufdem FFG 2017.



Links

[1] Startseite des Thomas-Krenn-Wikis: https://www.thomas-krenn.com/de/wiki/Hauptseite[2] Werner Fischers Vortrag auf dem FFG 2017: https://guug.de/veranstaltungen/ffg2017/abstracts.html#4_4_1[3] 2008-er Version der Wikistartseite:

https://www.thomas-krenn.com/de/wikiDE/index.php?title=Hauptseite&dir=prev&action=history[4] Twitterfeed des Thomas-Krenn-Wikis: https://twitter.com/tkwiki[5] 2010-er Pressemeldung zum Thomas-Krenn-Wiki:

https://www.thomas-krenn.com/de/unternehmen/presse/pressemeldung.werner-fischer-technology-specialist-praesentiert-das-thomas-krenn-wiki.html[6] Thomas-Krenn-Kundenmagazin: https://www.thomas-krenn.com/de/tkmag/tk-insights/kundemagazine/[7] tkmag: https://www.thomas-krenn.com/de/tkmag/[8] SSH Cheat Sheet von Thomas Krenn:

https://www.thomas-krenn.com/de/tkmag/allgemein/ssh-tricks-und-tipps-im-ssh-cheat-sheet/[9] About-Seite des Thomas-Krenn-Wikis mit Leserstimmen:

https://www.thomas-krenn.com/de/wiki/Thomas-Krenn-Wiki:Über


https://www.thomas-krenn.com/de/wiki/Hauptseite

https://guug.de/veranstaltungen/ffg2017/abstracts.html#4_4_1

https://www.thomas-krenn.com/de/wikiDE/index.php?title=Hauptseite&dir=prev&action=history

https://twitter.com/tkwiki

https://www.thomas-krenn.com/de/unternehmen/presse/pressemeldung.werner-fischer-technology-specialist-praesentiert-das-thomas-krenn-wiki.html

https://www.thomas-krenn.com/de/unternehmen/presse/pressemeldung.werner-fischer-technology-specialist-praesentiert-das-thomas-krenn-wiki.html

https://www.thomas-krenn.com/de/tkmag/tk-insights/kundemagazine/

https://www.thomas-krenn.com/de/tkmag/

https://www.thomas-krenn.com/de/tkmag/allgemein/ssh-tricks-und-tipps-im-ssh-cheat-sheet/

https://www.thomas-krenn.com/de/wiki/Thomas-Krenn-Wiki:�ber

UPTIMES SOMMER 2017 HILFREICHES FÜR ALLE BETEILIGTEN

Hilfreiches für alle BeteiligtenAutorenrichtlinien

Selbst etwas für die UpTimes schreiben? Aber ja!Als Thema ist willkommen, was ein GUUG-Mitgliedinteressiert und im Themenbereich der GUUG liegt.Was sonst noch zu beachten ist, steht in diesenAutorenrichtlinien.

Der Schriftsteller ragt zu den Sternen empor,Mit ausgefranstem T-Shirt.Er raunt seiner Zeit ihre Wonnen ins Ohr,Mit ausgefranstem T-Shirt.

Frei nach Frank Wedekind, Die Schriftstellerhymne

Wir sind an Beiträgen interessiert. Wir, das ist die-jenige Gruppe innerhalb der GUUG, die dafürsorgt, dass die UpTimes entsteht. Dieser Prozesssteht jedem GUUG-Mitglied offen. Der Ort dafürist die Mailingliste <[email protected]>.

Welche Themen und Beitragsarten kannich einsenden?

Die UpTimes richtet sich als Vereinszeitschriftder GUUG an Leser, die sich meistens beruflichmit Computernetzwerken, IT-Sicherheit, Unix-Systemadministration und artverwandten The-men auseinandersetzen. Technologische Diskus-sionen, Methodenbeschreibungen und Einführun-gen in neue Themen sind für dieses Zielpublikuminteressant, Basiswissen im Stil von Einführung indie Bourne Shell hingegen eher nicht. Wer sich nichtsicher ist, ob sein Thema für die UpTimes von In-teresse ist, kann uns gern eine E-Mail an <[email protected]> schicken.

Neben Fachbeiträgen sind Berichte aus demVereinsleben, Buchrezensionen, Konferenzberich-te, humoristische Formen und natürlich Leserbrie-fe interessant. Auch Notizen aus einem Vortragoder Seminar, die Du besucht hast, eignen sichals Grundlage für einen eigenen kleinen Text dar-über. Wer nicht gleich mehrseitige Artikel schrei-ben möchte, beginnt also einfach mit einem klei-neren Text.

Auch Übersetzungen sind von Interesse. Oftstößt man zum Beispiel auf englischsprachige Bei-träge anderswo, die man interessant findet. Sol-che Beiträge kannst Du wie einen eigenen Arti-kel als Übersetzung der UpTimes vorschlagen. Dustehst dann als Übersetzer über dem Artikel, derOriginalautor erhält – wenn möglich – einen Au-torenkasten. Bevor Du Übersetzungen einreichst,kontaktierst Du den Originalautoren und bittest

ihn um Erlaubnis zur Übersetzung und Veröffent-lichung in der UpTimes. Dieser Schritt ist wichtig,denn die UpTimes benötigt das Nutzungs- undBearbeitungsrecht für die Veröffentlichung, unddiese Rechte muss man sich qua Erlaubnis sepa-rat und explizit einholen. Für den Autorenkastenbittest Du den Originalautoren entweder um ei-ne Kurzbeschreibung, oder recherchierst sie selbst.Beispiele, wo wir Beiträge Dritter für die UpTi-mes verarbeitet haben, sind die Artikel OpsReport-Card – Fragen für Sysadmins in Ausgabe 2014-2,IT-Sicherheit als Realpolitik in Ausgabe 2015-2 oderKernel-Regressions bekämpfen in Ausgabe 2017-1.

Fachbeiträge sind sachbezogen, verwendenfachsprachliches Vokabular und klärende Erläute-rungen, besitzen technische Tiefe und ggf. auchExkurse. Berichte aus dem Vereinsleben greifenaktuelle Themen auf oder legen Gedankengän-ge rund um die GUUG und ihre Communitydar. Konferenzberichte zeigen, welche Veranstal-tungen jemand besucht hat, was er/sie dort erfah-ren hat und ob die Veranstaltung nach Meinungdes Autoren beachtenswert oder verzichtbar war.Unterhaltsame Formen können ein Essay oder ei-ne Glosse sein, aber auch Mischformen mit Fachar-tikeln (Beispiel: der Winter-Krimi in Ausgabe 2013-3). Auch unterhaltsame Formen besitzen jedochinhaltlichen Anspruch. Denn die UpTimes ist undbleibt die Mitgliederzeitschrift eines Fachvereines.

In der UpTimes legen wir daher auch Wert aufformale publizistische Gepflogenheiten und ein-heitliche Schreibweisen. Dafür sorgt zum Beispielein einheitliches Layout der Artikel, oder etwa diegrundsätzliche Vermeidung von Worten in Groß-buchstaben (entspricht typografisches Schreien)oder von Worten in Anführungsstrichen zum Zei-chen der Uneigentlichkeit (entspricht Distanzie-rung von den eigenen Worten). Wichtig sind au-ßerdem beispielsweise Quellenangaben bei Zita-






ten, Kenntlichmachung fremder Gedanken, Nach-vollziehbarkeit der Argumentation sowie Infor-mationen zum Autor nach dem Artikel.

In welchem Format soll ich meinen Artikeleinsenden?

ASCII: Am liebsten blanke UTF8-Texte. Gern mitbeschreibenden Anmerkungen oder Hinweisen,die nicht zum eigentlichen Text gehören (kenntlichgemacht zum Beispiel mit Prozentzeichen).

LATEX: Wir setzen die UpTimes mit LATEX. Ei-ne Vorlage mit den von uns verwendeten Aus-zeichnungen für Tabellen, Kästen und Abbil-dungen gibt es unter http://www.guug.de/uptimes/artikel-vorlage.tex. Mit dieser Vorlage kann derAutor selbst seinen Artikel mit den UpTimes-spezifischen Bestandteilen und Formatierungenkonzipieren. Die Einsendung erfolgt dann mitsämtlichem Text in dieser .tex-Quelldatei (keinPDF), die dem weiteren Prozess zu Grunde liegt.Andernfalls überführen wir die Einsendung selbstin das UpTimes-Format. Weil wir – wie es sichbeim Publizieren gehört – mehrspaltig setzen undein homogenes Erscheinungsbild anstreben, ver-wenden wir für die UpTimes bestimmte, wieder-kehrende Formatierungen. Einige sind obligato-risch (etwa der Artikelkopf), andere müssen nichtverwendet werden (zum Beispiel der Exkurskas-ten). Es gibt daher innerhalb des homogenen Er-scheinungsbildes einen gewissen Freiheitsgrad fürden Autor. Es ist nicht erwünscht, vom Formatka-talog abzuweichen oder eigene Layoutanweisun-gen einzusenden. Wir behalten uns vor, Texte fürdie Veröffentlichung in der UpTimes umzuforma-tieren.

Listings: Der mehrspaltige Druck erlaubt maxi-mal 45 Zeichen Breite für Code-Beispiele, inklusi-ve 1 Leerzeichen und einem Zeichen für den Zeile-numbruch innerhalb einer Code-Zeile (Backslash).Breitere Listings formatieren wir um, verkleinerndie Schriftgröße oder setzen sie als separate Abbil-dung. Listingzeilen werden in der UpTimes num-meriert und im Artikeltext mit Bezug auf dieseZeilennummern erläutert. Wir halten das für höf-lich und nützlich gegenüber dem Leser. Es hilft,die Listings so auszuwählen und zu präsentieren,dass sie dem Leser maximale Erkenntnis bringen.

Bilder: Wir verarbeiten gängige Bildformate,soweit ImageMagick sie verdaut und sie hochauf-lösend sind. Am besten eignen sich PNG- oderPDF-Bilddateien. Bei längeren Artikeln ist zur Ver-meidung von Textwüsten ungefähr mit 1 Abbil-dung pro 3000 Zeichen zu planen. Das müssen

nicht Bilder sein, sondern auch Tabellen, Listingsoder ein Exkurskasten lockern den Text auf. Ver-seht Eure Bilder nicht mit Rahmen oder Verzie-rungen, weil die Redaktion diese im UpTimes-Stilselbst vornimmt.

Wie lang kann mein Artikel sein?

Ein einseitiger Artikel hat mit zwei Zwischentitelnum die 2.700 Anschläge. Mit etwa 15.000 Anschlä-gen – inklusive 3 Abbildungen – landet man aufrund vier Seiten. Wir nehmen gern auch achtseiti-ge Artikel, achten dabei aber darauf, dass der Zu-sammenhang erhalten bleibt und dass es genugBilder gibt, damit keine Textwüsten enstehen.

Wer Interesse hat, für die UpTimes zu schrei-ben, macht sich am besten um die Zeichenzahlnicht so viele Gedanken – auch für kurze oderlange Formate finden wir einen Platz. Die Re-daktion ist bei der konkreten Ideenentwicklunggern behilflich. Für eine Artikelidee an <[email protected]> reicht es, wenn Ihr ein bestimmtesThema behandeln wollt.

Wohin mit meinem Manuskript?

Am einfachsten per E-Mail an <[email protected]>. Das ist jederzeit möglich, spä-testens jedoch vier Wochen vor dem Erscheinender nächsten UpTimes. Zum Manuskript ist einkleiner Infotext zum Autor wichtig, ein Bild wün-schenswert.

Nützlich ist, wenn der Text vor Einsendungdurch eine Rechtschreibkorrektur gelaufen ist.aspell, ispell oder flyspell für Textdateiensowie die von LibreOffice bieten sich an. Wenn IhrEuren Text an die Redaktion schickt, solltet Ihr al-so weitestmöglich bereits auf die Rechtschreibunggeachtet haben: Nach der Einschickung ist Recht-schreibung und Typo-Korrektur Aufgabe der Re-daktion. Die Texte in der UpTimes folgen der neu-en deutschen Rechtschreibung.

Wie verlaufen Redaktion und Satz?

Wir behalten uns vor, Texte für die Veröffentli-chung in der UpTimes zu kürzen und zu redi-gieren. Das bedeutet, dafür zu sorgen, dass derArtikel nicht ausufert, versehentliche Leeraussa-gen wegfallen, Syntax und Satzanschlüsse geglät-tet werden, dass Passiva und Substantivierungenverringert und Unklarheiten beseitigt werden (die


http://www.guug.de/uptimes/artikel-vorlage.tex







zum Beispiel Fragen offen lassen oder aus Passiv-konstruktionen resultieren, ohne dass der Schrei-bende das merkt). Manchmal ist dieser Prozess mitNachfragen an den Autoren verbunden.

Die endgültige Textversion geht jedem Autorenam Ende zur Kontrolle zu. Dabei geht es um die in-haltliche Kontrolle, ob durch den Redaktionspro-zess Missverständnisse oder Falschaussagen ent-standen sind. Danach setzt die Redaktion die Arti-kel. Wenn der Satz weitgehend gediehen ist – alsoein Release Candidate der UpTimes als PDF vorliegt– erhalten die Autoren als erste diesen RC. Danachwird die UpTimes dann veröffentlicht.

Gibt es Rechtliches zu beachten?

Die Inhalte der UpTimes stehen ab Veröffentli-chung unter der CC-BY-SA-Lizenz, damit jederLeser die Artikel und Bilder bei Nennung derQuelle weiterverbreiten und auch weiterverar-beiten darf. Bei allen eingereichten Manuskrip-ten gehen wir davon aus, dass der Autor sieselbst geschrieben hat und der UpTimes ein nicht-exklusives, aber zeitlich und räumlich unbegrenz-tes Nutzungs- und Bearbeitungsrecht unter der

CC-BY-SA einräumt.Bei Fotos oder Abbildungen Dritter ist es recht-

lich unabdingbar, dass der Autor sich bei demUrheber die Erlaubnis zu dieser Nutzung ein-holt, und fragt, wie die Quelle genannt zu werdenwünscht. Die Frage nach der CC-BY-SA ist hierbeibesonders wichtig.

An Exklusivrechten, wie sie bei kommerziel-len Fachzeitschriften üblich sind, hat die UpTimeskein Interesse. Es ist den Autoren freigestellt, ihreArtikel noch anderweitig nach Belieben zu veröf-fentlichen.

Bekomme ich ein Autorenhonorar?

Für Fach- und literarische Beiträge zahlt dieGUUG dem Autor nach Aufforderung durch dieRedaktion und Rechnungstellung durch den Au-tor pro Seite 50 e zuzüglich eventuell anfallenderUSt. Bei Übersetzungen erhalten Übersetzer undOriginalautor je die Hälfte. Beiträge für die Ru-brik „Vereinsleben“, Buchrezensionen und Artikelbezahlter Redakteure sind davon ausgenommen.Gleiches gilt für Paper, wenn die UpTimes die Pro-ceedings der Konferenz enthält.

Für die nächste redaktionelle Ausgabe wird ein Chefredakteur gesucht:UpTimes 2017-2, Winterausgabe

• Redaktionsschluss: N.N.

• Erscheinung: N.N.

• Gesuchte Inhalte: Fachbeiträge über Unix und verwandte Themen, Veranstaltungsberichte, Rezen-sionen, Beiträge aus dem Vereinsleben.

• Manuskript-Template für UpTimes-spezifische Formate: http://www.guug.de/uptimes/artikel-vorlage.tex

• Fragen, Artikelideen und Manuskripte an: Redaktionsmailingliste <[email protected]>





UPTIMES SOMMER 2017 ÜBER DIE GUUG

Über die GUUGGerman Unix User Group e.V.

Vereinigung deutscher Unix-Benutzer

Die Vereinigung Deutscher Unix-Benutzer hat ge-genwärtig rund 700 Mitglieder, davon etwa 90 Fir-men und Institutionen.

Im Mittelpunkt der Aktivitäten der GUUG ste-hen Konferenzen. Ein großes viertägiges Eventder GUUG hat eine besondere Tradition undfachliche Bedeutung: In der ersten Jahreshälf-te treffen sich diejenigen, die ihren berufli-chen Schwerpunkt im Bereich der IT-Sicherheit,der System- oder Netzwerkadministration haben,beim GUUG-Frühjahrsfachgespräch (FFG).

Seit Oktober 2002 erscheint mit der UpTimes– die Sie gerade lesen – eine Vereinszeitung.Seit 2012 erscheint die UpTimes einerseits zu je-dem FFG in Form einer gedruckten Proceedings-Ausgabe (ISBN), und andererseits im Rest des Jah-res als digitale Redaktionsausgabe (ISSN). Dane-ben erhalten GUUG-Mitglieder zur Zeit die Zeit-schrift LANline aus dem Konradin-Verlag kosten-los im Rahmen ihrer Mitgliedschaft.

Schließlich gibt es noch eine Reihe regionalerTreffen (http://www.guug.de/lokal): im Rhein-Ruhr-und im Rhein-Main-Gebiet sowie in Berlin, Ham-burg, Karlsruhe und München.

Warum GUUG-Mitglied werden?

Die GUUG setzt sich für eine lebendige und pro-fessionelle Weiterentwicklung im Open Source-Bereich und für alle Belange der System-, Netz-werkadministration und IT-Sicherheit ein. Wirfreuen uns besonders über diejenigen, die bereitsind, sich aktiv in der GUUG zu engagieren. Dadie Mitgliedschaft mit jährlichen Kosten

Fördermitglied 350 epersönliches Mitglied 70 ein der Ausbildung 30 e

verbunden ist, stellt sich die Frage, welche Vorteiledamit verbunden sind?

Neben der Unterstützung der erwähnten Zie-le der GUUG profitieren Mitglieder auch finanzi-ell davon, insbesondere durch die ermäßigten Ge-bühren bei den Konferenzen der GUUG und de-nen anderer europäischer UUGs. Mitglieder be-kommen außerdem c’t und iX zum reduziertenAbopreis.

Wie GUUG-Mitglied werden?

Füllen Sie einfach das Anmeldeformular unterhttps://www.guug.de/verein/mitglied/ aus und schi-cken Sie es per Fax oder Post an die unten auf demFormular angegebene Adresse.


http://www.guug.de/lokal

https://www.guug.de/verein/mitglied/

UPTIMES SOMMER 2017 ÜBER DIE GUUG

Impressum

Uptimes – Mitgliederzeitschrift derGerman Unix User Group (GUUG) e.V.Herausgeber: GUUG e.V.Antonienallee 145279 EssenE-Mail: <[email protected]>Internet: http://www.guug.de/uptimes/

Autoren dieser Ausgabe: Ingo Wichmann und Nils Magnus, AnikaKehrer, Yves-Noel Weweler, Christopher J. Ruwe, Jürgen PlateV.i.S.d.P: Ingo Wichmann, VorstandsvorsitzenderAnschrift siehe Herausgeber.Chefredaktion: Anika KehrerRedaktion: Mathias WeidnerLATEX-Layout (PDF): Robin DärmannXHTML-Layout (ePub): Mathias WeidnerTitelgestaltung: Hella BreitkopfBildnachweis: Titelbild kabibo-Roboter folgt dem Licht von Hella Breit-kopf. Comicreihe geek & poke von Oliver Widder, CC-BY-SA, mitzusätzlicher freundlicher Genehmigung von Oliver Widder. AndereQuellennachweise am Bild, sofern nicht unter CC BY SA.Verlag: Lehmanns Media GmbH, Hardenbergstraße 5, 10623 BerlinISSN: 2195-0016

Für Anzeigen in der UpTimes wenden Sie sich bitte an <[email protected]>.

Alle Inhalte der UpTimes stehen, sofern nicht anders angegeben, unter der CC BY SA(https://creativecommons.org/licenses/by-sa/3.0/de/).

Alle Markenrechte werden in vollem Umfang anerkannt.



http://www.guug.de/uptimes/


https://creativecommons.org/licenses/by-sa/3.0/de/

· Ceph Lars Marowsky-Bree (Abbildung 3) arbeitet seit ... Zeitpunkt Ende März) angab, dass...

Documents

Transcript of · Ceph Lars Marowsky-Bree (Abbildung 3) arbeitet seit ... Zeitpunkt Ende März) angab, dass...