Schlagwort-Archive: Planet

Tag für den Ubuntuusers.de Planeten.

logo_clt2019

Zu Besuch bei den Chemnitzer Linux Tagen 2019

Auch in diesem Jahr haben die Chemnitzer Linux Tage wieder in das zentrale Hörsaal- und Seminar-Gebäude der Technischen Universität Chemnitz eingeladen. Das Motto lautete diesmal „Natürlich intelligent“ und so wundert es nicht, dass sich eine Vielzahl von Vorträgen den Themen Künstliche Intelligenz und Maschinelles Lernen widmeten. Darüber hinaus gab es interessante Vorträge zu den Themen IoT, Container, Sicherheit, Einsteiger, Datacenter, usw. Alles in allem wurde wie im letzten Jahr ein vielseitiges Programm geboten.

Anreise am Freitag

Wie im vergangenen Jahr bin ich auch dieses Mal wieder mit dem Auto angereist, denn 4,5 Std. Fahrt sind mir doch lieber, als 6-7 Std. Reisezeit mit der Bahn (laut Fahrplan). So kam ich Freitag Abend rechtzeitig an, um das Social Event im Turmbrauhaus zu besuchen. Es war ein schöner Abend mit freundlichen Menschen bei interessanten Gesprächen und natürlich 1..n Hopfenkaltschalen.

Ich habe mich gefreut, bekannte Gesichter von ubuntuusers.de wieder zu sehen und neue Gesichter hinter einigen Blogs kennen zu lernen, die ich regelmäßig lese.

Auftakt am Samstag

Punkt 7.00 Uhr Frühstück im Hotel, 8.00 Uhr Einlass bei den Chemnitzer Linux Tagen und ab 9.00 Uhr öffnete die Ausstellerfläche und das Vortragsprogramm startete. Ich selbst lernte an diesem Tag etwas über Präsentationen mit XeLaTeX (Beamer), NVMe, NVMe over Fabrics und erfuhr die ein und andere Neuigkeit im persönlichen Gespräch mit alten und neuen Bekannten. Mein persönliches Zitat des Tages stammt von D. Menzel und lautet: „NVMe over Fabric ist wie iSCSI auf Steroiden.“ :-D

Ausklang am Sonntag

Auch der Sonntag begann früh mit dem Frühstück um 7.00 Uhr. Um 9.00 Uhr war bereits alles für die Abreise gepackt und die Chemnitzer Linux Tage öffneten ihre Halle für den zweiten Veranstaltungstag. Dieser startete für mich mit einigen Standbesuchen, um Informationen über mögliche Schulungsangebote und Tipps für den Einsatz von Ansible einzusammeln, bevor es dann um 10.00 Uhr in den ersten Vortrag, den Samba Status Report, ging.

Laut dem zuvor genannten Vortrag tritt SMB2 an, um NFS zu töten. Naja, ich persönlich glaube, Totgesagte leben länger.

Der Storage Track endete mit einem Vortrag von Kai Wagner, welcher über die Neuigkeiten im neuen Ceph Release Nautilus berichtete. In hohem Tempo führte Kai durch eine Folienschlacht, um keine coole Neuerung zu vergessen. Bei den vielen lang erwarteten Neuerung kann ich gut verstehen, dass Kai keine davon unterschlagen wollte. Dennoch hat Kai hier einen tollen und unterhaltsamen Talk gehalten. Danke hierfür.

Der letzte Vortag für mich an diesem Tage war Open Source und Medizin, welcher einen interessanten Einblick in die Forschung mit Medizindaten bot.

Im Anschluss wurden die Vorträge noch in kleinen Gruppen diskutiert, bevor ich mich verabschiedete, um mich auf den Heimweg zu machen.

Es war mal wieder ein schönes Wochenende und tolle Chemnitzer Linux Tage 2019. Bis zum nächsten Jahr.

RHEL Spiegelserver für arme Admins

Es muss nicht immer gleich der Red Hat Sattelite Server sein, um einen lokalen Spiegelserver für die Installation von RPM-Paketen bereitzustellen.

Auf GitHub habe ich im Repository „Poor man’s RHEL mirror“ eine kleine Sammlung von Bash-Skripten zusammengestellt, mit denen sich ein Spiegelserver für RHEL-Repositories aufbauen lässt. Mit diesem können RHEL-Repositories, für welche man eine gültige Subskription besitzt, auf einen Host im lokalen Netzwerk synchronisiert und deren Pakete anderen RHEL-Servern im LAN zur Verfügung gestellt werden.

Neben der reinen Spiegelung können mit den auf GitHub bereitgestellten Skripten weitere lokale Stage-Repositories eingerichtet werden, mit denen sich die Verfügbarkeit von Paketen für einzelne Stages steuern lässt. Zusätzlich bietet das Projekt Skripte, um eigene YUM-Repositories zu erstellen, um zum Beispiel eigene Pakete darüber bereitstellen zu können. Des Weiteren wurde die Möglichkeit berücksichtigt, die Red Hat Errata Informationen in die lokalen RHEL-Repositories zu integrieren, um die --advisory Option für YUM auch auf Systemen nutzen zu können, die über keine eigene Verbindung zum Internet verfügen.

Warum ist dieses Projekt nützlich?

  • Es schont die eigene Internetverbindung, da Pakete nur einmal aus dem Internet heruntergeladen und anschließend im LAN zur Verfügung gestellt werden.
  • Es unterstützt bei der Erstellung eines YUM-Repositories zur Bereitstellung von RPM-Paketen.
  • Es unterstützt das Staging-Konzept, in dem es die Möglichkeit bietet, stage-spezifische Repositories bereitzustellen.
  • Es implementiert die Red Hat Errata Informationen in die gespiegelten RHEL-Repos, so dass diese von angebundenen Servern genutzt werden können, die über keine eigene Internetverbindung verfügen.
  • Es entstehen keine Zusatzkosten, da alle notwendigen Werkzeuge in den Repos einer RHEL-Standard-Subskription enthalten sind.

Wer kann dieses Projekt nutzen?

Das Projekt selbst steht unter der MIT-Lizenz und kann unter deren Bedingungen frei genutzt, modifiziert und weiter verteilt werden.

Für den Betrieb des Spiegelservers ist der Besitz einer gültigen RHEL-Subskription Voraussetzung. Denn es können nur jene Repos gespiegelt werden, für die eine gültige Subskription vorhanden ist. Auch alle an den Spiegelserver angeschlossenen Systeme müssen über eine entsprechende und gültige Subskription verfügen.

Bei Fragen zu Subskriptionen helfen die folgenden Seiten weiter:

Um mit diesem Projekt einen Spiegelserver aufsetzen und betreiben zu können, sind gewisse Kenntnisse erforderlich. Zu diesen zählen die Installation eine RHEL-Systems inkl. Registrierung, das Hinzufügen von Subskriptionen und die Installation von Paketen. Informationen hierzu bietet die Product Documentation for Red Hat Enterprise Linux 7.

Wie ist das GitHub-Repository zu diesem Projekt aufgebaut?

Das GitHub-Repository beinhaltet ein README, welches einen Überblick über das Projekt und eine Kurzbeschreibung der einzelnen Skripte in englischer Sprache beinhaltet. Im Master-Branch befindet sich die letzte stabile Version des Projekts. Weiterentwicklungen und Fehlerkorrekturen werden im Dev-Branch gepflegt und nach einer Testphase in den Master-Branch übernommen.

Sorgen, Nöte und Anträge sowie gefundene Fehler dürfen gern über die Issue-Funktion oder in den Kommentaren zu diesem Beitrag gemeldet werden.

An dieser Stelle folgt eine Beschreibung in deutscher Sprache, wie ein Spiegelserver mit diesem Projekt aufgebaut werden kann. Dabei handelt es sich um keine Schritt-für-Schritt-Anleitung und es werden grundlegende Kenntnisse über den Betrieb eines RHEL-Servers und die Installation sowie Konfiguration von Paketen vorausgesetzt.

Einrichtung eines Spiegelservers für arme Sysadmins

Um das Projekt nutzen zu können, benötigt man eine RHEL-Installation mit gültiger Subskription, auf welcher mindestens die folgenden Pakete installiert sein müssen:

  • reposync und createrepo, um RHEL-Repos synchronisieren und eigene Repos erstellen zu können
  • git zum Klonen des hier beschriebenen Projekts
  • Die Gruppe Basic Web Server oder einen anderen Webserver eurer Wahl, um die gespiegelten Repos über HTTP im LAN bereitstellen zu können

Zu Beginn sind die Dateien aus dem oben genannten GitHub-Repository in einem Verzeichnis auf dem lokalen Host bereitzustellen. Anschließend ist das Projekt zu konfigurieren. Die dazu notwendigen Schritte werden in den folgenden Abschnitten erläutert.

CONFIG.SAMPLE

Hierbei handelt es sich um die Hauptkonfigurationsdatei. Diese ist in CONFIG umzubenennen bzw. zu kopieren und zu editieren. In dieser Datei werden die Variablen gesetzt, die von den verschiedenen Shell-Skripten verwendet werden. Darunter sind z.B. Angaben, welche Repos gespiegelt werden und wo die Dateien gespeichert werden sollen.

Die Datei ist mit Kommentaren versehen und sollte weitgehend selbsterklärend sein (was für alle weiteren Dateien gilt).

create_yum_repo.sh

Dieses Skript kann genutzt werden, um ein eigenes YUM-Repository zu erstellen, über welches RPM-Pakete bereitgestellt werden können. Der Name des zu erstellenden Repos kann dem Skript als Parameter übergeben werden.

do_reposync.sh

Dies ist das Herzstück des Projekts. Es kümmert sich um die Spiegelung der RHEL-Repos. Die notwendigen Parameter werden in der Datei CONFIG konfiguriert.

Das Skript lädt nur die aktuellen Pakete aus den Repos herunter, löscht aus den Upstream-Repos entfernte Pakete jedoch nicht automatisch auf dem lokalen Host. Dies ist meinen persönlichen Anforderungen geschuldet. Es ist nicht ausgeschlossen, dass ich diese Parameter in Zukunft ebenfalls konfigurierbar gestalte.

Einen Überblick über den Speicherbedarf ausgewählter RHEL-Repos findet ihr hier: How much disk space do I need for reposync?

Um die heruntergeladenen Pakete im LAN zur Verfügung zu stellen, muss das BASEDIR (siehe CONFIG) über einen Webserver zugreifbar gemacht werden.

refresh_repo.sh

Werden einem Repo neue RPM-Dateien hinzugefügt, muss die Metadaten-Datenbank aktualisiert werden, damit Klienten die neuen Pakete auch finden können. Um diese Aktualisierung kümmert sich eben dieses Skript.

rsync_repo.sh

Mit diesem Skript lassen sich Repos auf dem lokalen System synchronisieren. Dabei werden die Dateien jedoch nicht 1:1 kopiert, sondern Hardlinks erstellt. Dies spart bei der Verwendung mehrerer Repos für unterschiedliche Stages Speicherplatz.

Neben dem kompletten Sync eines Repos ist es auch möglich, dem Skript eine Datei zu übergeben, welche die Namen der Pakete enthält, welche in ein weiteres Repo „transportiert“ werden sollen.

Wrapper-Scripts

In meiner Umgebung arbeiten wir mit bis zu vier verschiedenen Stages (E, I, Q und P). Für jede dieser Stages wird ein eigenes Stage-Repo des Upstream rhel-7-server-rpms erzeugt. Um diese Stage-Repos zu aktualisieren, werden die folgenden Skripte verwendet:

  • update_rhel-e-stage.sh
  • update_rhel-i-stage.sh
  • update_rhel-q-stage.sh
  • update_rhel-p-stage.sh

Jede Stage wird mit den Paketen aus der vorhergehenden aktualisiert. So ruft z.B. update_rhel-e-stage.sh das Skript rsync_repo.sh, um die Pakete aus dem lokalen Spiegel des Upstreams rhel-7-server-rpms zu importieren. update_rhel-i-stage.sh verwendet dementsprechend die rhel-e-stage als Quelle usw.

Diese Konfiguration ist für meinen Anwendungsfall optimiert. Die Verwendung der Skripte ist optional. Der Spiegelserver funktioniert auch ohne diese Wrapper-Scripts.

update_mirror_packages_and_erratas.sh

Dieses Skript aktualisiert die Pakete in den Repos des lokalen Spiegelservers inkl. der Red Hat Errata Informationen. Letztere ermöglichen es, die Erratas (RHSA, RHBA und RHEA) auch Systemen verfügbar zu machen, welche über keine Verbindung zum Internet verfügen.

Das Skript ist in der Standardeinstellung auf meinen Anwendungsfall optimiert und aktualisiert am Ende alle vorhandenen RHEL-Stage-Repos. Wer diese Funktion nicht benötigt, kann sie durch Auskommentieren der Zeilen 45 und 46 im Skript deaktivieren.

Anschließend kann ein Cronjob erstellt werden, welcher das Skript ausführt, um den Spiegelserver regelmäßig gemäß der eigenen Anforderungen zu aktualisieren.

Die gespiegelten Repos verfügbar machen

Hat man die Repos seiner Wahl gespiegelt, ergibt sich je nach Konfiguration eine Verzeichnisstruktur ähnlich der folgenden.

$ tree -L 2
.
├──  rhel-7-test-mirror
│   ├── rhel-7-server-extras-rpms
│   ├── rhel-7-server-optional-rpms
│   ├── rhel-7-server-rpms
│   ├── rhel-7-server-supplementary-rpms
│   ├── rhel-e-stage
│   ├── rhel-e-stage.repo
│   ├── rhel-i-stage
│   ├── rhel-p-stage
│   ├── rhel-q-stage
│   └── rhel-server-rhscl-7-rpms

Das Verzeichnis rhel-7-test-mirror aus obigen Beispiel enthält die gespiegelten Repos als Unterverzeichnisse. Dieses Verzeichnis sollte über einen Webserver zugreifbar gemacht werden, um die Pakete den Clients im lokalen Netzwerk verfügbar zu machen.

Im obigen Listing ist eine Datei namens rhel-e-stage.repo zu sehen. Dabei handelt es sich um eine Repo-Datei, welche heruntergeladen und im Verzeichnis /etc/yum.repos.d/ platziert werden kann, um wie in diesem Beispiel das Repo rhel-e-stage zu aktivieren.

Aufbau einer Repo-Datei

Das folgende Listing zeigt die kommentierte Repo-Datei aus dem vorstehenden Abschnitt. Sie kann als Muster für weitere eigene Repo-Dateien dienen.

[rhel-e-stage] # Repo ID
baseurl = http://example.com/rhel-7-test-mirror/rhel-e-stage/
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
name = Repo for rhel-7-server-rpms (Test)

Fragen, Sorgen, Nöte und Anträge

Das Projekt und die enthaltene Software werden so wie sie sind unter der angegebenen Lizenz zur Verfügung gestellt.

Fragen, Sorgen, Nöte und Anträge können sowohl hier in den Kommentaren zum Artikel, als auch auf Github hinterlassen werden.

Ich hoffe, dass dieses Projekt euch (weiterhin) nützlich ist und freue mich über Rückmeldungen, wie es euch gefällt.

Kommentar zu Docker – Genauso schlimm wie befürchtet

Marius hat gestern in Braunschweig darüber gebloggt, dass Docker – Genauso schlimm wie befürchtet ist. Bis Marius zu seiner Analyse kommt, stimme ich ihm voll und ganz zu. Auch ich gehöre zu den ewig gestrigen, den Nörglern, Pessimisten und Schwarzsehern, welche es von Anfang an gesagt haben. Und unsere düstere Vorsehung ist eingetreten. Welch Überraschung.

Wo ich Marius nicht mehr zustimme, sind die Ergebnisse seiner Analyse, welche er in der zweiten Hälfte seines Artikels vornimmt. So schreibt er dort:

Der sicherere Ansatz ist und bleibt, daß jemand das OS vorgibt und sich die Apps an die Umgebung anpassen müssen. Damit sind die gezwungen Updates zu machen und das dient dann der allgemeinen Sicherheit.

URL: https://marius.bloggt-in-braunschweig.de/2019/02/27/docker-genauso-schlimm-wie-befuerchtet/

Diese Aussage ist in meinen Augen falsch. Denn niemand wird gezwungen, Updates für die in einem Betriebssystem installierten Anwendungen zu veröffentlichen. Folgende Beispiele sollen dies verdeutlichen.

Man nehme ein herkömmliches Betriebssystem, sagen wir Ubuntu oder Red Hat Enterprise Linux. Unter beiden Betriebssystemen kann ich mir nun eine Anwendung als DEB- bzw. RPM-Paket oder auch ganz klassisch als TAR-Archiv aus dem Internet herunterladen und auf meinem Betriebssystem installieren. Habe ich nun eine Garantie, dass ich Sicherheitsupdates für diese Software erhalte? Die Antwort lautet: Nein.

Verwendet man eine nach obigem Muster installierte Software und nutzt diese gemeinsame Bibliotheken, mag man das Glück haben, dass die Software nach der Aktualisierung eben dieser Bibliotheken nicht mehr funktioniert. Ob man dies als Sicherheitsgewinn wertet oder es doch nur ein Ärgernis ist, sei einmal dahingestellt.

Im Ubuntuversum soll die Paketquelle universe als abschreckendes Beispiel dienen. In dieser befindet sich so viel alte und nicht mehr gepflegte Software, dass man auch hier die Chance hat, Anwendungen mit ein oder mehreren Sicherheitslücken zu finden.

Zugegeben, mit einer zentralen Paketverwaltung ist es einfacher, sein System aktuell zu halten, um es vor Sicherheitslücken zu schützen. Eine Garantie ist es nicht und kein Sysadmin sollte sich darauf ausruhen.

Abzulehnen ist also alles, was eine App installiert, die mit eigener Umgebung kommt, sowas wie FlatPak, Docker und Snap.

URL: https://marius.bloggt-in-braunschweig.de/2019/02/27/docker-genauso-schlimm-wie-befuerchtet

Marius schließt seinen Beitrag mit obigem Satz. Dieser ist mir zu pauschal. Denn FlatPak, Docker und Snap sind nicht per Definition unsicher. Wer sich jedoch ohne lange nachzudenken, den erstbesten Container vom Docker Hub herunterlädt ist selber schuld.

Es gibt jedoch auch die Möglichkeit eine eigene Registry für Container aufzusetzen und zu betreiben, um nur Container zu verwenden, die man selbst geprüft bzw. gebaut hat. Oder man nutzt die Registries der Enterprise Distributionen wie z.B. Red Hat OpenShift, welche sich gegen Entgelt um die Bereitstellung geprüfter Container-Images kümmern. Auch dies ist keine Garantie für (absolute) Sicherheit und Aktualität. Doch hat hier wenigstens jemand den Sicherheitsaspekt im Auge und arbeitet an diesem Thema. Dies ist im Vergleich zur völlig freien, unkontrollierten und schwer prüfbaren Müllhalde ein großer Vorteil.

Ähnliches gilt für FlatPak und Snap. Letztlich stehen und fallen die kommerziellen Angebote damit, wie gut ihr Anbieter seinen Job macht. Auch hier wurden schon Pakete gefunden, die neben ihrer eigentlichen Aufgabe noch einen Zweitjob (Crypto currency mining) hatten.

Für pauschale bzw. absolute Aussagen ist es in meinen Augen noch zu früh. Wir werden noch eine Weile abwarten müssen, wie sich die einzelnen Projekte weiterentwickeln. Als Sysadmin sollte man weiterhin stets auf der Hut sein und seinen gesunden Menschenverstand benutzen.

Erfahrungsbericht vom OpenStack Summit 2018 in Berlin

Der OpenStack Summit 2018 fand vom 13.11.-15.11. im CityCube Berlin statt. Es war der erste Summit in Deutschland und ich nutzte die Gelegenheit, den Summit erstmals zu besuchen. Hier folgt nun ein Erfahrungsbericht.

Motivation

Privat interessiere ich mich bereits seit vielen Jahren für diverse Themen rund um Open Source Hard- und Software. Beruflich bin ich aktuell in ein Projekt involviert, welches sich inhaltlich mit der Speicher-Lösung Ceph [1], [2] und der Cloud-Umgebung OpenStack [3], [4] beschäftigt.

Bei beiden handelt es sich um äußerst komplexe Open Source Technologien und die Einstiegshürde liegt entsprechend hoch. Dies liegt unter anderem daran, dass man hier kein fertiges Produkt bekommt, sondern eher ein Framework, welches sich flexibel für diverse Anwendungsfälle eignet.

Mit dem Summit bot sich eine gute Gelegenheit, die Community kennenzulernen, Vorträge über Fallstudien und Neuentwicklungen zu hören sowie an Workshops zur weiteren Entwicklung teilzunehmen.

Der Ceph Day Berlin

Im Vorfeld des OpenStack Summits fand ebenfalls im CityCube Berlin der Ceph Day [5] statt. Eröffnet wurde dieser von Sage Weil, welcher einen Überblick über den aktuellen Entwicklungsstand und neue Funktionen im kommenden Release gab.

Es folgten Vorträge über die neuen Management- und Monitoring-Funktionalitäten des überarbeiteten Dashboards, eine Fallstudie vom MeerKAT Radio-Teleskop und noch einige mehr. Begleitend wurden die Teilnehmer mit Kaffee, Kaltgetränken und kleinen Snacks versorgt.

Besonders gefallen haben mir die Vorträge über den Entwicklungsstand, die Neuerungen und wie man mit Upmap das Backfilling bzw. Rebalancing in den Griff bekommt. Darüber hinaus habe ich die Gelegenheit genutzt, in den Pausen mit anderen Teilnehmern, über deren Anwendungsfälle und  Erfahrungen mit Ceph zu sprechen. Auch in diesen Gesprächen gab es sowohl neue Einblicke, als auch Bestätigung für Dinge, die ich mir bisher aus der Literatur angelesen und in einem kleinen Proof of Concept erfahren habe.

Alles in allem war es ein guter Tag, welcher Lust auf die weiteren Tage machte.

Der OpenStack Summit

Am Dienstag startete dann der OpenStack Summit mit einer Reihe von Keynotes. Erste Erkenntnis: Da es auf diesem Summit nicht nur um OpenStack geht, wird sich die Veranstaltung einen neuen Namen geben und sich zukünftig Open Infrastructure Summit nennen.

Ganz grob lässt sich der Summit in das Vortragsprogramm, den Marktplatz und die Flurgespräche unterteilen.

Das Vortragsprogramm

Es gab ein reichhaltiges und abwechslungsreiches Vortragsprogramm [6]. Aufgrund des internationalen Publikums wurden sämtliche Vorträge in englischer Sprache gehalten.

Die Vorträge ließen sich erneut in Fallstudien, Projektvorstellungen, Neuigkeiten und Sponsoren-Vorträge unterteilen. Es gab ein breites Spektrum sowohl an Themen, als auch an deren Qualität.

Bei den vielen parallelen Strängen und interessanten Themen war es unmöglich, alle interessanten Vorträge zu besuchen. Zum Glück wurden sehr viele Vorträge aufgezeichnet, so dass man sie sich auch im Nachgang noch auf Video ansehen kann [7].

Eine interessante Erfahrung für mich war die Teilnahme an den Arbeitstreffen einiger Gruppen, welche sich unter anderem um die Weiterentwicklung der verschiedenen Deployment-Werkzeuge für OpenStack drehten. Die Teilnehmer hielten die Agenda in öffentlich zugänglichen Etherpads [8] fest und sammelten in diesen sowohl Fragen, Vorschläge als auch Antworten zu den gestellten Fragen.

Insgesamt wirkten diese Treffen zwar nicht sehr effizient, doch habe ich auch keine Idee, wie man ein Treffen mit so vielen Teilnehmern effizienter gestalten kann. Ich hoffe nun auf die Ergebnisse, da diese einem Neueinsteiger die Wahl eines geeigneten Deployment-Tools entscheidend vereinfachen könnten.

Der Marktplatz

Als Marktplatz wurde die Ausstellerfläche der Sponsoren im CityCube bezeichnet. Hier ergab sich die Gelegenheit, mit den Firmen in Kontakt zu treten, welche aktiv an der Entwicklung von Ceph und OpenStack beteiligt sind und ergänzende kommerzielle Lösungen und Support für diese anbieten.

Als SysAdmin habe ich mit großer Freude zur Kenntnis genommen, dass hier vor allem Techniker vor Ort waren und keine Vertriebsmitarbeiter. So konnte man sich darüber austauschen, was ein Produkt wirklich kann, wie es funktioniert und was davon zu erwarten ist. Und sind wir mal ehrlich, einen Preis dafür kann man immer noch anfragen. Dies gelingt in den meisten Fällen deutlich einfacher, als einen technisch versierten Ansprechpartner zu finden.

Selbstverständlich konnte man hier auch das ein oder andere Souvenir in Form eines T-Shirts, einer Tasse oder eines Huts abstauben. So war auch für Souvenir-Jäger gesorgt.

Flurgespräche

Flurgespräche nenne ich die vielen Gelegenheiten, die sich boten, um mit Menschen aus der Community Gespräche über verschiedenste Themen zu führen. Häufig sind diese informellen Gespräche genauso informativ, wenn nicht sogar noch erkenntnisreicher, als so mancher Vortrag.

Darüber hinaus besitzen sie selbstverständlich auch einen gewissen Unterhaltungswert. Am Dienstag Abend saß ich mit einem US-Amerikaner und einem Russen zusammen. Wir tauschten uns über kulturelle Unterschiede und Herangehensweisen beim Betrieb von Rechenzentren aus. Und wir hatten eine Menge Spaß dabei.

Grundsätzlich besitzen Ceph und OpenStack eine recht offene und freundliche Community. Man konnte schnell Anschluss finden und auch für die vermeintlich naiven Fragen eines Einsteigers nahm man sich Zeit, um diese ausführlich zu diskutieren.

Mein größter Dank gilt der Teilnehmerin oder dem Teilnehmer, welche/r mein verlorenes Portemonnaie gefunden und abgegeben hat. VIELEN DANK an die bzw. den Unbekannte/n!

Fazit

Ich persönlich ziehe ein gemischtes Fazit. Der Ceph Day sowie der OpenStack Summit waren toll. Sowohl das offizielle Programm als auch die Menschen waren spitze. Es war eine tolle Erfahrung, dabei zu sein. Ich hoffe, dass sich mir diese Möglichkeit noch einmal bietet.

Bezüglich Ceph und OpenStack habe ich viele Anwendungsszenarien kennengelernt und einen guten Einblick in diverse Projekte gewonnen. Deutlich wurde dabei jedoch auch, dass OpenStack noch lange nicht fertig ist und es vermutlich auch nie sein wird. Die Entwicklung wird in alle möglichen Richtungen weitergehen. Mit dabei sind eine Menge Haken, Ösen und Dinge, die einfach noch nicht ausgereift sind.

Doch muss man sich von diesen lebendigen Projekten nicht abschrecken lassen. Die Fallstudien bspw. des CERN, des MeerKAT oder des Human Brain Projects zeigen, dass man diese Projekte mit den richtigen Voraussetzungen sehr erfolgreich betreiben kann.

Was wir in unserer Einrichtung daraus machen, wird die Zukunft zeigen.


  1. Ceph Project Homepage: https://ceph.com/
  2. Ceph – Wikipedia: https://de.wikipedia.org/wiki/Ceph
  3. OpenStack Project Homepage: https://www.openstack.org
  4. OpenStack – Wikipedia: https://de.wikipedia.org/wiki/OpenStack
  5. Ceph Day Berlin 2018: https://ceph.com/cephdays/ceph-day-berlin/
  6. Full Schedule 2018: https://www.openstack.org/summit/berlin-2018/summit-schedule/full/
  7. Aufgezeichnete Tracks: https://www.openstack.org/summit/berlin-2018/summit-schedule/#day=2018-11-13&recorded=true
  8. Etherpad – Wikipedia: https://de.wikipedia.org/wiki/Etherpad

Linux: Hotplugged SATA/SAS/SCSI-Festplatten ohne Neustart erkennen

Unter VMware vSphere lassen sich neue Festplatten im laufenden Betrieb zu einer virtuellen Maschine hinzufügen. Damit man diese neuen Festplatten im Gastbetriebssystem auch verwenden kann, müssen sie dem Kernel jedoch noch bekannt gemacht werden. Wie dies ohne Neustart geht, möchte ich in diesem Artikel dokumentieren.

Um die neuen Festplatten zu erkennen, muss man den Kernel veranlassen die vorhanden Speicher-Adapter (SATA/SAS/SCSI) nach neuen Geräten abzusuchen. Leider habe ich dafür kein einfaches Kommando gefunden, weswegen ich folgendes Verfahren anwende.

Unter /sys/class/scsi_host findet man die dem Kernel bekannten Speicher-Adapter des Systems:

$ ls /sys/class/scsi_host
host0  host1  host2

Um einen Speicher-Adapter nach neuen Geräten abzusuchen, führt man folgendes Kommando auf dem entsprechenden Adapter aus:

# echo '- - -' > /sys/class/scsi_host/host0/scan

Ist man sich nicht sicher, an welchen Speicher-Adapter die neuen Festplatten angeschlossen wurden, können alle Adapter mit der folgenden kleinen Schleife abgesucht werden:

# for f in /sys/class/scsi_host/host*; do echo '- - -' > $f/scan; done

Anschließend tauchen die neuen Festplatten in der Ausgabe von parted -l oder fdisk -l auf und können wie gewohnt formatiert und genutzt werden.

Empfehlungen für Raumklimaüberwachung erwünscht

Eines der beliebtesten Hobby-, Wochenend- bzw. Smart-Home-Projekte scheint die Überwachung von Temperatur und Luftfeuchtigkeit im In- und Außenbereich zu sein. Eine Internetrecherche zu diesem Thema liefert eine schier überwältigende Anzahl an Treffern zurück.

Auch ich habe mich in der Vergangenheit bereits mit diesem Thema befasst (siehe Beitrag „Wer viel misst, misst viel Mist“). Leider habe ich mit meinen bisherigen Versuchen noch kein zufriedenstellendes Ergebnis erreicht und bei den zahllosen Lösungsmöglichkeiten, die ich im Internet gefunden habe, den Überblick verloren. Daher möchte ich im Folgenden meine Anforderungen beschreiben und euch um eure Mithilfe in Form von Empfehlungen für mögliche Lösungen bitten.

Zielsetzung

In jedem Raum eines Hauses sollen Messstationen mit Sensoren zur Messung von relativer Luftfeuchtigkeit und Temperatur platziert werden, welche die gemessenen Werte über eine Funkverbindung an ein zentrales Gerät zur weiteren Verarbeitung übertragen. Als zentrale Datenverarbeitungsstelle soll ein Raspberry Pi dienen, welcher die Daten speichert und auf einer Webseite visualisiert.

Das ganze System soll zur Umsetzung und Überwachung eines Lüftungskonzepts dienen.

Beschreibung der Anforderungen

Um die beschriebene Zielsetzung zu erreichen, soll jeder Sensor bzw. jede Messstation folgende Anforderungen erfüllen. Optionale Anforderungen werden dabei als solche gekennzeichnet.

  1. Die Messstation soll frei im Raum platziert werden können.
  2. Die Stromversorgung erfolgt über Batterie, Akku oder Powerbank. Ein Anschluss an eine Steckdose ist nicht erforderlich.
  3. Die Messstationen übertragen die Messwerte über eine Funkverbindung (z.B. WLAN, Bluetooth, 433 MHz, etc.) an eine zentrale Empfangsstation.
  4. Die Empfangsstation muss an einem Raspberry Pi betrieben werden können, da dieser die Messdaten weiterverarbeiten soll.
  5. Die Verwendung freier und offener Standards/Protokolle wird bevorzugt.
  6. Messbereich für die Temperatur mindestens 0-70 °C bei einer Genauigkeit von +/- 0,5 °C.
  7. Messbereich für die Luftfeuchtigkeit mindestens 0-100% relative Luftfeuchtigkeit (RH) bei einer Genauigkeit von +/- 5% RH.
  8. Fühler für Temperatur und Luftfeuchtigkeit können in einem gemeinsamen oder in getrennten Sensoren untergebracht sein.
  9. Frei konfigurierbares Messintervall von 10-86400s.
  10. Frei wählbare Anzahl Messstationen. Es müssen jedoch mindestens 32 Sensoren an die zentrale Empfangsstation angebunden werden können.
  11. Unterstützung von Linux zur Entwicklung und Programmierung der Lösung.

Optionale Anforderungen

  1. Die Messstationen können mit einem Display zum Ablesen der Messwerte ausgestattet werden.
  2. Die Displays verfügen über eine per Knopfdruck zuschaltbare Displaybeleuchtung.
  3. Die Messstationen besitzen einen guten WAF.

Vorhandene Infrastruktur und Fähigkeiten

Ein IP-basiertes Heimnetzwerk (IPv4 und IPv6) mit WLAN (2,4 und 5 GHz) ist vorhanden. Grundlegende Programmierkenntnisse in C und Python ebenso. Andere Sprachen stellen kein Ausschlusskriterium dar. Die grundlegende Fähigkeit zur Benutzung von Multimeter und Lötkolben ist ebenfalls vorhanden. Jedoch arbeite ich hier eher auf dem Niveau eines Grobschmieds denn eines Chirurgen. Ich bin also nicht traurig, wenn hier nur wenig gebastelt werden muss.

Die Lösung

Tja, ich habe noch keine. Falls ihr jedoch eine Lösung kennt oder sogar selbst umgesetzt habt, welche die oben genannten Anforderungen erfüllt, freue ich mich sehr, wenn ihr in den Kommentaren zu diesem Beitrag darüber berichten mögt und eure Empfehlungen und Erfahrungen hier teilt.

20 Jahre LinuxDay AT

LinuxDay 2018 am 13. Okt in Dornbirn

Am 13. Oktober 2018 findet zum zwanzigsten Mal der LinuxDay in der HLT Dornbirn in Österreich statt.

Auf der Webseite der Veranstaltung findet sich in diesem Jahr daher neben reichlich Informationen zur Veranstaltung auch ein Abriss ihrer Geschichte.

Auch das Vortragsprogramm ist wieder gut gefüllt. Einen Überblick, über die geplanten Vorträge findet ihr unter: https://www.linuxday.at/vortraege/2018

Der Eintritt ist frei. Also packt eure Sachen und schaut vorbei. ;-)

Ein Gnuplot-Tutorial

Gnuplot (Eigenschreibweise: gnuplot) ist ein skript– bzw. kommandozeilengesteuertes Computerprogramm zur grafischen Darstellung von Messdaten und mathematischen Funktionen (Funktionenplotter). Das Projekt Gnuplot wird seit 1986 kontinuierlich von einem internationalen Team ehrenamtlicher Entwickler vorangetrieben. Der Quellcode wird seit 2000 über SourceForge verwaltet.

Wikipedia (letzter Abruf: 04.08.2018)

Da die auf der offiziellen Projekt-Homepage verlinkten deutschsprachigen Tutorials allesamt auf eine Fehlerseite (404 – Page Not Found) führen, möchte ich hier ein eigenes Tutorial in deutscher Sprache anbieten. Darin werde ich zeigen, wie Messdaten aus Text- bzw. CSV-Dateien grafisch dargestellt und in den Formaten EPS, PNG und SVG ausgegeben werden können. Das Tutorial schließt mit einem Beispiel zur Histogramm-Erstellung.

Voraussetzungen

Um die Inhalte dieses Tutorials nachvollziehen zu können, benötigt Ihr eine gnuplot-Installation auf dem eigenen Rechner.

Benutzer von Linux können gnuplot für gewöhnlich über die Paketverwaltung ihrer Distribution installieren. Benutzer von Windows und anderer Betriebssysteme können unter gnuplot download nachschauen.

Die in diesem Tutorial verwendeten Beispiel-Dateien können direkt von dieser Seite heruntergeladen werden, um die Beispiele nachzuvollziehen.

Beispiel 1: Darstellung der Energiekostenentwicklung

Um dieses Beispiel nachvollziehen zu können, wird folgende Datei benötigt:

# Energiepreise_Heizoel_Strom.csv
# https://www.destatis.de/DE/Publikationen/Thematisch/Preise/Energiepreise/Energiepreisentwicklung.html
# Elektrischer Strom in Cent/kWh inkl. Steuern
# Leichtes Heizöl Cent/l inkl. Mineralölsteuer und Erdölbevorratungsbeitrag, ohne Mehrwertsteuer
# Jahresdurchschnitt
# Berichtsjahr;leichtes Heizöl;Strom
2000;35,30;
2001;32,06;
2002;30,27;
2003;30,75;
2004;34,41;
2005;45,11;
2006;50,32;
2007;49,73;
2008;64,08;21,72
2009;43,77;22,88
2010;54,87;24,07
2011;69,26;25,3
2012;75,33;26,36
2013;70,36;29,2
2014;64,37;29,78
2015;48,79;29,49
2016;40,94;29,73
2017;47,51;30,48
2018;53,74;

Das obige Listing zeigt den Inhalt der Datei Energiepreise_Heizoel_Strom.csv.

Die Datei enthält zu Beginn einige Kommentarzeilen (beginnend mit #) mit beschreibendem Text. Darunter befinden sich die drei Spalten Berichtsjahr, leichtes Heizöl und Strom, welche durch ein Semikolon voneinander getrennt sind. Diese Werte sollen nun in einem anschaulichen Diagramm dargestellt werden.

Daten mit gnuplot grafisch darstellen

Um die Daten aus obiger Datei grafisch darstellen zu können, sind zuerst folgende Schritte auszuführen:

  1. Öffne ein Terminal
  2. Wechsle in das Verzeichnis, in dem die Datei Energiepreise_Heizoel_Strom.csv liegt
  3. Starte gnuplot durch Eingabe des entsprechenden Kommandos
Bildschirmfoto vom Verzeichniswechsel und Start von gnuplot

Wir befinden uns jetzt im interaktiven Eingabemodus. Durch Eingabe der folgenden Befehle erhalten wir eine erste grafische Darstellung unserer Daten. Die gezeigten Befehle werden im Einzelnen nach der folgenden Abbildung erläutert.

Erster Plot des Diagramms
gnuplot> set datafile separator ";"
gnuplot> set autoscale
gnuplot> set xlabel "Jahr"
gnuplot> set ylabel "Preis in Cent"
gnuplot> plot "Energiepreise_Heizoel_Strom.csv" using 1:2 title "leichtes Heiz\U+FFC3\U+FFB6l Cent/l", "Energiepreise_Heizoel_Strom.csv" using 1:3 title "elektrischer Strom Cent/kWh"
gnuplot>

Das obige Listing stellt die Befehle zum Plot des Diagramms im Bild darüber dar.

In der ersten Zeile wird das verwendete Trennzeichen angegeben. In diesem Fall handelt es sich dabei um das Semikolon, welches die einzelnen Spalten in unserer CSV-Datei voneinander trennt.

Zeile 2 gibt an, dass sich Gnuplot selbst um eine sinnvolle Skalierung der Achsen im Diagramm kümmern soll. Wie man die Skalierung manuell vorgibt, wird in einem späteren Beispiel gezeigt. Mit `set xlabel/ylabel` wird die Achsenbeschriftung festgelegt.

In der letzten Zeile wird schließlich der Befehl zum Zeichnen des Diagramms eingegeben. Eingeleitet wird die Zeile vom Kommando „plot“, gefolgt von der Angabe des Dateinamens. Mit „using 1:2“ wird angegeben, dass Gnuplot die Spalten 1 und 2 aus der Datei darstellen soll. Dabei wird der erste Wert an der X-Achse und der zweite Wert an der Y-Achse abgetragen. Mit dem Schlüsselwort „title“ kann noch eine Graphenbeschriftung für die Legende vergeben werden. Nach dem Komma wird die Angabe wiederholt. Hier sollen die Daten der ersten und dritten Spalte aus der Datei visualisiert werden. Man könnte an dieser Stelle auch eine andere Datei angeben, aus der man Werte im Diagramm darstellen möchte. Dazu ist lediglich der entsprechende Dateiname zu ändern.

Selbstverständlich kann auch die Darstellungsform der Graphen beeinflusst werden. Das folgende Beispiel zeigt, wie man den Graphen für leichtes Heizöl als Linie und den für elektrischen Strom als Linie mit Punkten darstellt.

gnuplot> plot "Energiepreise_Heizoel_Strom.csv" using 1:2 with lines title "leichtes Heizl Cent/l", "Energiepreise_Heizoel_Strom.csv" using 1:3 with linespoints title "elektrischer Strom Cent/kWh"
Diagramm mit Linie und Linienpunkten

Wie man im  Listing sieht, kann hinter dem Schlüsselwort „with“ der zu verwendende Linientyp angegeben werden. Um zu sehen, welche Darstellungsformen möglich sind, kann man die eingebaute Hilfe aufrufen, indem man z.B. `help with` eingibt.

Gnuplot-Hilfe für die Funktion „with“

Die Hilfe in Gnuplot ist sehr umfangreich und bietet neben umfassenden Informationen zu allen Kommandos, Funktionen und Schlüsselwörtern auch einige schöne Beispiele. An ihr erkennt man in meinen Augen den hohen Reifegrad dieses Programms. Eine derart gute Dokumentation sucht man bei vielen anderen Projekten leider noch vergebens.

Die Entwickler von Gnuplot haben auch an die Tippmuffel unter uns gedacht. So lässt sich die Schreibweise etlicher Funktionen in Gnuplot abkürzen. Die beiden Zeilen im folgenden Listing sind äquivalent und führen zur gleichen Ausgabe.

gnuplot> plot "Energiepreise_Heizoel_Strom.csv" using 1:2 with lines title "leichtes Heizl Cent/l", "Energiepreise_Heizoel_Strom.csv" using 1:3 with linespoints title "elektrischer Strom Cent/kWh"

gnuplot> plot "Energiepreise_Heizoel_Strom.csv" u 1:2 w lines t "leichtes Heizl Cent/l", "Energiepreise_Heizoel_Strom.csv" u 1:3 w lines t "elektrischer Strom Cent/kWh"

Einstellungen speichern

Um nun nicht jedes Mal, wenn man Gnuplot startet, alle Einstellungen erneut eintippen zu müssen, können diese gespeichert werden.

gnuplot> save "Energiepreise_Heizoel_Strom.gp"

Diese Einstellungen können nun in einer neuen Gnuplot-Konsole mit load "Energiepreise_Heizoel_Strom.gp"geladen werden. Das Diagramm wird dabei automatisch mit den gespeicherten Einstellungen gezeichnet.

Ausgabe in PNG, SVG und EPS

Gnuplot bietet die Möglichkeit, Diagramme in verschiedensten Formaten auszugeben. Dazu wird in der interaktiven Gnuplot-Konsole das entsprechende Ausgabe-Terminal definiert und anschließend das Diagramm gezeichnet. Das folgende Listing zeigt den Code für Ausgabe des obigen Diagramms als PNG, SVG und EPS. Die Ergebnisse der Ausgabe befinden sich im aktuellen Arbeitsverzeichnis auf eurem Endgerät.

gnuplot> set terminal pngcairo size 640,480 enhanced font 'Verdana,10'
Terminal type set to 'pngcairo'
Options are ' background "#ffffff" enhanced font "Verdana,10" fontscale 1.0 size 640, 480 '
gnuplot> set output 'Energiepreise.png'
gnuplot> replot

gnuplot> set terminal svg size 640,480 fname 'Verdana' fsize 10
Terminal type set to 'svg'
Options are 'size 640,480 fixed enhanced fname 'Verdana'  fsize 10 butt dashlength 1.0 '
gnuplot> set output 'Energiepreise.svg'
gnuplot> replot

gnuplot> set terminal postscript eps size 3.2,2.4 enhanced color font 'Helvetica,20' linewidth 2
Terminal type set to 'postscript'
Options are 'eps enhanced defaultplex \
   leveldefault color colortext \
   dashlength 1.0 linewidth 2.0 butt noclip \
   nobackground \
   palfuncparam 2000,0.003 \
   size 3.20in, 2.40in "Helvetica" 20  fontscale 1.0 '
gnuplot> set output 'Energiepreise.eps'
gnuplot> replot
gnuplot>

Die Größenangaben (size) können selbstverständlich den eigenen Bedürfnissen angepasst werden.

Ist die Postscript-Ausgabe für ein Dokument bestimmt, welches in schwarz-weiß gedruckt werden soll, empfiehlt sich folgende Terminal-Konfiguration. Gnuplot bereitet dabei die Darstellung der Graphen für den Schwarz-Weiß-Druck auf.

gnuplot> set terminal postscript eps size 3.2,2.4 monochrome font 'Helvetica,20' linewidth 2
Terminal type set to 'postscript'
Options are 'eps enhanced defaultplex \
   leveldefault monochrome colortext \
   dashlength 1.0 linewidth 2.0 butt noclip \
   nobackground \
   palfuncparam 2000,0.003 \
   size 3.20in, 2.40in "Helvetica" 20  fontscale 1.0 '
gnuplot> set output 'Energiepreise_sw.eps'gnuplot> replot

Beispiel 2: Darstellung einer Messreihe mit Zeitabtrag an der X-Achse

Dieses Beispiel setzt den Schwerpunkt bei der Abtragung von Datum und Uhrzeit an der X-Achse mit entsprechender Formatierung. Daneben wird gezeigt, wie man selbst die anzuzeigenden Intervalle an X- und Y-Achse konfiguriert.

Um dieses Beispiel nachvollziehen zu können, wird folgende Datei benötigt:

In der Datei befinden sich Messwerte von drei DHT22-Sensoren, welche Temperatur und Luftfeuchtigkeit messen können. Die Datei besteht aus insgesamt 3983 Zeilen und besitzt folgenden Aufbau:

$ head -n6 dht22data.csv 
#Date,Temp1,Humd1,Temp2,Humd2,Temp3,Humd3
2018-06-04T17:57:26,23.80,61.50,23.90,51.50,22.70,52.80
2018-06-04T18:02:26,23.80,61.60,23.90,51.50,22.70,52.80
2018-06-04T18:07:27,23.80,61.50,23.90,51.50,22.70,52.80
2018-06-04T18:12:27,23.80,61.60,23.90,51.50,22.70,52.80
2018-06-04T18:17:28,23.80,61.30,23.90,51.50,22.70,52.80

In der ersten Spalte findet sich ein Zeitstempel, gefolgt von den jeweiligen Messwerten der drei Sensoren. Als Spaltentrennzeichen wird in dieser Datei das Komma verwendet. Als Dezimaltrennzeichen findet der Punkt Verwendung.

Im zu erstellenden Diagramm sollen Datum und Uhrzeit auf der X-Achse abgetragen werden. Auf der Y-Achse sollen die Temperaturwerte der drei Sensoren dargestellt werden. Die Luftfeuchtigkeit bleibt in diesem Beispiel unberücksichtigt.

set datafile separator ","
set xdata time
set timefmt "%Y-%m-%dT%H:%M:%S"
set xrange [ "2018-06-04T17:57:26" : "2018-07-11T12:44:50" ]
set yrange [ 18:25 ]
set format x "%m-%d\n%H:%M"
plot "dht22data.csv" u 1:2 title "Sensor 1", "dht22data.csv" u 1:4 title "Sensor 2", "dht22data.csv" u 1:6 title "Sensor 3"

Im obigen Listing wird zuerst das Spaltentrennzeichen definiert. In der zweiten Zeile wird Gnuplot mitgeteilt, dass auf der X-Achse Datum und Zeit abgetragen werden soll. Hinweis: Intern rechnet Gnuplot ausschließlich in Sekunden.

Zeile 3 teilt Gnuplot mit, in welchem Format Datum und Uhrzeit in der Datei vorliegen. In Zeile 4 werden die Grenzen definiert. Für die Angabe wurde der erste und der letzte Zeitstempel aus der Beispieldatei verwendet.

Mit set yrange [ 18:25 ] wird ein Intervall für die Y-Achse definiert, welches für eine Temperaturkurve sinnvoll erscheint. Das Kommando set format x "%m-%d\n%H:%M" gibt an, wie Datum und Uhrzeit an der X-Achse dargestellt werden sollen. In diesem Beispiel sollen erst Monat und Tag und nach einem Zeilenumbruch Stunde und Minute dargestellt werden. Der letzte Befehl zeichnet dann das folgende Diagramm.

Darstellung der Messwerte für die Temperatur

In der grafischen Darstellung ist auf den ersten Blick zu erkennen, dass es eine Lücke in der Messreihe gibt. Hierbei handelt es sich nicht um einen Fehler. Es fand in dem Zeitraum tatsächlich keine Messung statt. Zoomt man nun in das Diagramm hinein, kann man sehen, dass die Werte an der X-Achse automatisch skaliert werden.

Beispiel 3: Zweite Y-Achse

Im vorangegangenen Beispiel wurden nur die Temperaturwerte aus der Beispieldatei betrachtet. In diesem Beispiel soll die von einem Sensor gemessene Temperatur an der Y-Achse (links) und die Luftfeuchtigkeit an einer zweiten Y-Achse (rechts) abgetragen werden. Aus Gründen der Übersichtlichkeit wird dabei nur ein Ausschnitt der Werte für den ersten Sensor dargestellt.

set datafile separator ","
set xdata time
set timefmt "%Y-%m-%dT%H:%M:%S"
set xrange [ "2018-06-04T17:57:26" : "2018-07-11T12:44:50" ]
set yrange [ 23:25 ]
set y2range [ 40:65 ]
set y2tic
set format x "%m-%d\n%H:%M"
plot "dht22data.csv" u 1:2 title "Temp 1" axes x1y1, "dht22data.csv" u 1:3 title "Humd 1" axes x1y2

Mit set y2range [ 40:65 ] wird ein Intervall für die zweite Y-Achse festgelegt und mit set y2tic die Beschriftung der Achse aktiviert. Die letzte Zeile stellt den Plot-Befehl dar. Hier ist zu erkennen, dass bei Verwendung von zwei Y-Achsen stets mit anzugeben ist, an welcher Achse ein Wert abgetragen werden soll.

Darstellung von Temperatur und Luftfeuchtigkeit in einem Diagramm

Beispiel 4: Erstellung eines Histogramms

In diesem Beispiel wird aus den Daten einer CSV-Datei ein Histogramm erstellt. Die Datei selbst hat folgenden Aufbau und kann wie gewohnt von dieser Seite heruntergeladen werden, um das Beispiel nachvollziehen zu können.

Datum,0-6 Uhr,6-12 Uhr,12-18 Uhr,18-24 Uhr
2018-07-17,2,4,6,4
2018-07-18,1,5,5,2
2018-07-19,0,8,4,3
2018-07-20,0,3,7,6

Das Komma wird als Spaltentrennzeichen verwendet. Die erste Zeile enthält Spaltenüberschriften, gefolgt von den darzustellenden Werten in den folgenden Zeilen.

In diesem Beispiel wird dargestellt, wie viele Ereignisse pro Tag und Zeitraum erfasst wurden. Das Ergebnis soll dann wie folgt aussehen.

Darstellung von einer Anzahl Ereignisse pro Tag und Zeitraum
set datafile separator ","
set grid
set key top right outside vertical autotitle columnhead
set xtics rotate by 90 right out nomirror
set ytics out
set style fill solid border -1
set boxwidth 0.5 relative
set title "Ereignisse pro Tag und Zeitraum"
set style data histograms
set style histogram rowstacked
plot for [col=2:5] 'file.csv' u col:xticlabels(1)

Zu Beginn wird das Spaltentrennzeichen definiert. Die folgende Angabe schaltet ein Gitternetz innerhalb des Histogramms ein. Dies dient der besseren Übersicht.

Die dritte Zeile im Quelltext gibt an, dass die erste Zeile in der Beispieldatei genutzt werden soll, um passende Spaltenüberschriften zu generieren und als vertikale Legende rechts außerhalb des Diagramms darzustellen. Möchte man dies nicht verwenden, ist die erste Zeile der Beispieldatei auszukommentieren, da Gnuplot andernfalls einen Fehler meldet.

Da ein Histogramm mit einer wachsenden Anzahl Balken erstellt wird, ist die Beschriftung der X-Achse (mit den Werten aus Spalte 1) etwas anzupassen. Der Code in Zeile 4 dreht die Bezeichner um 90° und richtet sie rechtsbündig am dazugehörigen Balken aus. Die drei folgenden Zeilen kümmern sich um die Formatierung der Y-Achse und das Aussehen der Balken bzw. der Boxen in den Balken. Spielen Sie ruhig mit den Werten, um zu sehen, wie sich Änderungen auf die Darstellung auswirken.

Mit set title wird das Diagramm mit einem Titel überschrieben.

In den beiden vorletzten Zeilen wird angegeben, dass ein Histogramm gezeichnet werden soll und das die Daten Zeilenweise verarbeitet werden. Dies bedeutet, dass die in einer Zeile enthaltenen Werte anschließend als Boxen in einem Balken dargestellt werden. Pro Zeile wird ein Balken gezeichnet.

Die letzte Zeile zeichnet dann das Histogramm. Durch for [col=2:5] wird angegeben, dass die Werte in den Spalten 2 bis 5 als Boxen in einem Balken dargestellt werden. Mit col:xticlabels(1) wird erreicht, dass ein Balken einem Datum aus Spalte 1 zugeordnet wird.

Natürlich können auch die Einstellungen aus diesem Beispiel mit load "dateiname.gp" gespeichert und später wiederverwendet werden.

Fazit

Ich selbst bin erst vor relativ kurzer Zeit auf Gnuplot aufmerksam geworden, doch möchte ich es heute nicht mehr missen.

Hat man sich erstmal an die Bedienung gewöhnt, lassen sich schnell und effizient anschauliche Diagramme produzieren, ohne eine Tabellenkalkulation bemühen zu müssen.

Ich hoffe, dieses kleine Gnuplot-Tutorial hat euch gefallen und konnte euer Interesse an einem schönen und leistungsstarken Werkzeug wecken.

Kommentar zum geplanten Umstieg auf Open Source in Schleswig-Holstein

Wie heise online in diesem Bericht verkündet, will das Land Schleswig-Holstein die Abhängigkeit von Microsoft-Produkten verringern und die Verwaltung zukünftig komplett auf freie Software umrüsten.

Mir persönlich gefällt an dem Antrag der Fraktionen von
CDU, Bündnis`90/Die Grünen und FDP, dass diesmal nicht die Kostenreduzierung als oberstes Ziel formuliert wurde. Denn dass man mit freier Software durch den Wegfall von Lizenzgebühren IT-Kosten drastisch senken kann, ist ein häufiger Irrglaube.

Statt dessen formuliert der Antrag eindeutig die Absicht, die Abhängigkeit zu einzelnen Herstellern und deren Lizenzmodellen soweit wie möglich zu reduzieren. Dabei handelt es sich jedoch nicht um eine Umstellung um jeden Preis. Es soll nun nicht damit begonnen werden, alle etablierten Verfahren ohne besonderen Anlass auf freie Software umzustellen. Jedoch soll dies stets dann geprüft werden, wenn Neubeschaffungen anstehen, oder wesentliche Änderungen an bestehenden Verfahren/Programmen vorgenommen werden müssen.

Damit die Anwender nicht (wie so oft) auf der Strecke bleiben, sollen diese laut Antrag von Beginn an mit einbezogen werden. Frühzeitige Anwenderschulungen und eine Kommunikation von Sinn und Zweck einer Umstellung sollen die Akzeptanz bei den Mitarbeitern und Mitarbeiterinnen fördern.

Für mich klingt dieser Antrag durchdacht und schlüssig. Mir gefällt daran besonders, dass er die Punkte in den Mittelpunkt stellt, an denen bereits viele Open Source Projekte gescheitert sind. Dies sind in meinen Augen:

  • Keine Umstellung um jeden Preis, sondern sukzessive dort, wo dies sinnvoll und nachhaltig erscheint
  • Einbeziehung und Schulung der Mitarbeiterinnen und Mitarbeiter von Beginn an
  • Kein Versprechen, das mit einer Umstellung eine drastische Kostenreduzierung einhergeht

Ob es wirklich so kommt, bleibt natürlich abzuwarten. Es besteht jedoch Hoffnung, dass hier mit Verstand und Augenmaß gehandelt wird und freie Software Schritt für Schritt Einzug in die Verwaltung des Landes Schleswig-Holstein erhält. Auf jeden Fall klingt es nach einem spannenden Unterfangen, welches sich im Auge zu behalten lohnt.