Azubis erzählen: April 2015 Alexander

This entry is part 5 of 12 in the series Azubis erzählen

Name: Alexander Klimov
Ausbildungsberuf: Fachinformatiker für Anwendungsentwicklung
Abteilung: Development
Lehrjahr: 1

Hallo Menschen!
Diesmal bin ich an der Reihe, Euch meinen Ausbildungsberuf nahezubringen.
Doch zuerst ein paar Angaben zu meiner Wenigkeit:
Ich heiße Alexander. Ich bin 20 Jahre jung und im 1. Lehrjahr. Mein Ausbildungsberuf heißt Fachinformatiker für Anwendungsentwicklung und mich erwartet im kommenden Lehrjahr erst mal die Zwischenprüfung. Die Abschlussprüfung sollte im Lehrjahr darauf folgen. Meine Kollegen Nadja und Marius mögen schon weiter sein, aber – wie ich gerne zu sagen pflege – kommt Zeit, kommt Rat! Neben der unglaublich spannenden Berufsschule bin ich in der Development-Abteilung von NETWAYS tätig.
Die Berufsbezeichnung ist relativ selbsterklärend. Meine (Haupt-)Aufgabe besteht darin, Anwendungen (weiter) zu entwickeln. Im Folgenden möchte ich euch ein paar davon vorstellen.

Icinga Web 2

An unserem PHP-Framework Icinga Web 2 gibt es noch alle Hände voll zu schrauben (schließlich soll es irgendwann mal fertig werden) – kein Wunder, dass der Löwenanteil meiner bisherigen Ausbildung diesem Projekt gewidmet war.
Icinga LogoNeben dem Erlernen der unglaublich tollen Programmiersprache PHP war es mir vergönnt, viele kleinere Fehler zu beheben und die Puppet-Manifeste radikal umzubauen, um Letztgenannte überschaubar(er) zu machen. Das Problem bestand darin, dass (fast) alles (fast 800 Zeilen) sich in einer .pp-Datei befand – und das hat den Code nicht viel übersichtlicher gemacht. Meine Aufgabe bestand darin, das Ganze zu modularisieren. Das hat zwar eine ganze Weile gedauert, aber mittlerweile ist es geschafft!

DbMaint

Das von mir Mitte 2014 entwickelte DbMaint soll u. a. beim Aktualisieren von Icinga 2 dazugehörige Datenbanken mit auf den neusten Stand bringen – und somit den Administrationsaufwand verringern. Für Debian gab es zwar schon dbconfig-common, aber in RPM-basierenden GNU-Distributionen fehlte ein derartiges Werkzeug.
DbMaint war in Python zu realisieren und sollte sowohl MySQL als auch PostgreSQL unterstützen. Als ob letztgenanntes nicht schon aufwändig genug war, lagen mir – dank RHEL 5 – Steine im Weg. Dieser Weg war entsprechend steinig und schwer – trotzdem ist mir die Fertigstellung gelungen.

Stammdaten-Verwaltung

Momentan verantworte ich die Fertigstellung eines Icinga Web 2 Moduls, das Stammdaten von Kunden verwalten soll. Dazu zählen bspw. Verträge und (im Rahmen letztgenannter) erworbene Produkte/Dienstleistungen. Da die voraussichtliche Datenmenge nicht überschaubar ist, kommt dafür nur eine relationale Datenbank in Frage. Sich mit solchen zu beschäftigen fand ich spannend und lehrreich. (Überhaupt lerne ich im Betrieb eine ganze Menge interessanter Sachen – die Berufsschule lasse ich an dieser Stelle mal unkommentiert..)
Zuerst hatte ich das Datenbankschema zu planen – wie die Datenbank aufgebaut sein soll und was sie überhaupt speichern soll. Danach sollte das Modul für Icinga Web 2 programmiert werden. Es soll die gespeicherten Daten anzeigen und auch das Hinzufügen, Bearbeiten und Löschen ermöglichen. (Für Leute, die sich nicht mit Datenbanken/SQL auskennen oder gerade keine Lust haben, viele/längere SQL-Abfragen abzutippen. 😉 )
Exploits of a MomAn dieser Stelle darf ich eine Lanze für Icinga Web 2 brechen, denn ohne seine Infrastruktur wäre ich so gut wie aufgeschmissen.

Fazit

In diesem Beruf reicht es nicht, in die Tasten hauen zu können – auch Köpfchen anstrengen will gelernt sein. Und wer auch um die Ecke denken kann – der findet bei uns bestimmt die richtige Stelle für sich.

Alexander Klimov
Alexander Klimov
Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der...

Icinga2 SELinux Policy sucht Tester

selinux-penguin-125
Nachdem ich mit Michael im Rahmen der FOSDEM über das Thema einer SELinux Policy zur weiteren Absicherung von Icinga 2 diskutiert hatte, nahm ich mich der Aufgabe an. Rund zwei Monate später hat die Policy nun einen Stand erreicht, an dem sie Benutzerfeedback braucht.

Wer soll testen?

Das Hauptziel ist eine Policy für Red Hat Enterprise Linux 7 und seine Derivate. Wer also eines davon betreibt ohne SELinux abzuschalten, ist das perfekte Versuchskaninchen der perfekte Tester. Aber natürlich freuen wir uns über Feedback zu jedem Betriebssystem, wenn es jemand auf einem anderen System mit SELinux ausprobieren möchte.

Was soll getestet werden?

Einfach das Policy Modul gemäß der Anleitung installieren und Icinga 2 wie gewohnt betreiben. Hierbei ist es egal ob es sich um ein einfaches Setup oder eine hoch komplexe Umgebung handelt, jedes Feedback hilft dabei die Policy produktionsreif zu bekommen. Auch das Feedback, dass alles funktioniert wie erwartet, hilft! Sollte die Dokumentation noch Fragen offen lassen oder unklar sein, schreibt uns auch das und macht Vorschläge wie diese verbessert werden kann. Das Feedback einfach an den Feature Request anhängen, der es erlaubt die Entwicklung zu verfolgen.

Mehr zu SELinux?

SELinux Coloring Book
Für diejenigen, die erst mal mehr zu SELinux erfahren möchten, enthält die Dokumentation Links zum SELinux FAQ, dem Red Hat Enterprise Linux 7 – SELinux User’s and Administrator’s Guide und der wahrscheinlich besten Erklärung für SELinux-Neulinge, dem SELinux Malbuch. Die Dokumentation erklärt darüber hinaus das Icinga 2 Policy Modul mit dem der Dienst abgesichert wird. Auch erlaubt es einen administrativen Benutzer auf das Management von Icinga 2 zu beschränken.

Warum SElinux?

Warum sollte SELinux einen überhaupt kümmern? Einfach weil es ein zusätzlicher Sicherheitsmechanismus ist, der die möglichen Auswirkungen von Schwachstellen verringert. Als ein noch nicht zu weit vergangenes und bekanntes Beispiel soll der Shellshock-Exploit dienen, welchen Dan Walsh unter dem Aspekt SELinux analysiert.

Nächste Schritte

Oberste Priorität hat das Sammeln von Feedback und Weiterentwickeln der Policy und Dokumentation dazu. Danach um die Installation zu vereinfachen das Bauen von Paketen. Ziel ist es bis zur Version 2.4 von Icinga 2 alles nochmal überprüft zu haben und den Entwicklungszweig in den Release zu überführen.
Dies erlaubt dann den Fedora und EPEL Maintainern mit dem Review-Prozess zu beginnen, der benötigt wird um das Paket in die Distribution zu bekommen.
Mit dem Release von Icinga Web 2 wird der gleiche Prozess hierfür ablaufen.
Zu guter Letzt soll das hier entwickelte Policy Modul in die Reference Policy einfließen, was dann wiederum die Installation von Zusatzpaketen unnötig macht.
For an English version of this post have a look at the Icinga blog.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Release packages for RPM repository configuration

While writing and updating training material for our Icinga 2 courseware, we are also re-evaluating the installation and configuration process by practical example and learning curve. Certain parts of the Icinga2 documentation are updated similar to the training material from training participants feedback and also by the trainers themselves.
In this special example, we found it tremendously hard to install the icinga rpm repository from packages.icinga.org inside the CentOS 7 training VM. By default you would just type a long string to fetch the yum repository information.

# wget http://packages.icinga.org/epel/ICINGA-release.repo -O /etc/yum.repos.d/ICINGA-release.repo
# yum makecache

training_install_icinga_repositoryWhile this works pretty well for release repositories, how about the snapshot repository for testing bleeding edge stuff? Similar to EPEL release package we’d just want that for Icinga as well.
The RPM package called ‘icinga-rpm-release’ contains the repository’s GPG key as well as the yum configuration for the release repository which is enabled by default. The snapshot repository is installed, but disabled. You may use it with the “–enablerepo” yum parameter.
Example for el7:

Name:           icinga-rpm-release
Version:        7
Release:        1%{?dist}
Summary:        Icinga Package Repository
Group:          System Environment/Base
License:        GPLv2
URL:            http://packages.icinga.org/epel/
Source0:        %{name}-%{version}.tar.gz
Source1:        http://packages.icinga.org/icinga.key
Source2:        http://packages.icinga.org/epel/ICINGA-release.repo
Source3:        http://packages.icinga.org/epel/ICINGA-snapshot.repo
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:      noarch
Requires:       redhat-release >=  %{version}
%description
This package contains the Icinga package repository GPG key
as well as configuration for yum.
%prep
%setup -q -c -T
install -pm 644 %{SOURCE0} .
%build
%install
rm -rf $RPM_BUILD_ROOT
#GPG key
install -Dpm 644 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-ICINGA
#yum
install -dm 755 $RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d
install -pm 644 %{SOURCE2} %{SOURCE3} $RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%config(noreplace) /etc/yum.repos.d/*
/etc/pki/rpm-gpg/*
%changelog

All distribution releases are organized in git branches, which keeps it fairly simply for Jenkins package builds.
Tip: Downloading the url-referenced sources (“SourceX: Url”) works using spectool.

$ cd sources
$ spectool -g ../icinga-rpm-release.spec
modify, add, commit

In the end, you’ll get a nice rpm which installs just fine. No need to worry about the GPG key or where to store the configuration files.

# rpm -i http://packages.icinga.org/epel/7/release/noarch/icinga-rpm-release-7-1.el7.centos.noarch.rpm
# yum search icinga2

See you in the icinga2 training sessions!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

RPM-Packaging: Software Collections selbst gemacht

RPM-Icon from www.softicons.com used under LGPL
Zum Abschluss meiner kleinen Reihe von Hilfestellungen zum Thema Paketieren von Software mittels RPM möchte ich die Software Collections beleuchten. Die Software Collections sind ein relativ neues Modell von Red Hat zur Parallelinstallation von Software in unterschiedlichen Version. Um von der in der eigentlichen Distribution enthaltenen Version unabhängig zu sein erfolgt die Installation in ein abweichendes “root”-Verzeichnis, wobei es sich nicht um eine echte chroot-Umgebung handelt, da der Zugriff auf außerhalb liegende Ressourcen trotzdem möglich ist. Stattdessen werden entsprechende Umgebungsvariablen zur Verwendung gesetzt.
Red Hat liefert diese über einen eigene Channel aus, für CentOS und Fedora heißt die Anlaufstelle https://www.softwarecollections.org/. Eine Software Collection besteht hierbei aus einem Metapaket, dass die Verzeichnisstruktur erstellt und Skripte mitliefert um diese zu nutzen. Hierbei ist die Funktionsweise recht simpel: Nachdem die Software Collection installiert wurde, können mittels einem Befehl die entsprechenden Umgebungsvariablen gesetzt und diese beispielsweise in einer neuen Shell genutzt werden.

$ ruby --version
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
$ scl enable ruby193 bash
$ ruby --version
ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]

Gegebenenfalls kann dieses Kommando auch in einem Wrapper-Skript untergebracht werden, so dass es noch leichter zu verwenden ist.

$ ruby193-ruby --version
ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]

So kann beispielsweise Foreman direkt auf dieses Skript als zu verwendende Ruby-Version verweisen.
Und nicht nur die Verwendung ist sehr einfach auch die Erstellung ist sehr simpel. Der zusätzliche Aufwand ist die Erstellung eines Metapakets wobei das Tool spec2scl helfen kann, bei Bedarf die Erstellung von einem oder mehreren Wrapperskripten und die Anpassung des SPEC-Files.
Die Anpassungen halten sich hierbei in Grenzen, da hier mit Makros gearbeitet wird die durch die Software Collection Werkzeuge gesetzt werden. Ein bisschen aufpassen muss man mit Dateien, die außerhalb der Software Collection benötigt werden wie Apache- oder Sudo-Konfiguration. Um hier nun kein Beispiel komplett abzutippen möchte ich nur auf die Red Hat Dokumentation verweisen.
Um das Paket dann mit den gewohnten Werkzeugen zu erstellen, wird noch das Paket scl-utils-build benötigt. Möchte man statt dem lokalen rpmbuild lieber mock verwenden, muss hierbei das Paket durch die mock-Konfiguration in den Chroot-Umgebungen installiert werden! Und noch ein kleiner Tipp verwendet nur die vorgesehenen Makros scl und _scl_prefix, interne Makros wie _scl_vendor funktionieren nicht zuverlässig auf allen Versionen!
Der Aufruf um dann das neue Paket für die Software Collektion zu bauen ist dann nur unwesentlich komplexer als vorher:

mock -r epel-6-x86_64 --define '_scl_prefix /opt/netways' --define 'scl icinga-1.12' rpmbuild/SRPMS/icinga-1.12-interfacetable_v3t-0.05.1-1.fc20.src.rpm

Damit schließe ich zumindest fürs erste meine Reihe zum Thema RPM ab und wünsche jedem viel Erfolg beim Ausprobieren und viel Spaß mit der gewonnen Zeit wenn Software nicht auf jedem System manuell zu installieren ist.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

RPM-Packaging: Die Werkzeuge

RPM-Icon from www.softicons.com used under LGPL
Wie versprochen will ich heute nach dem Arbeitsmaterial und der Bauanleitung vorstellen womit mein Werkzeugkoffer für das Bauen von Paketen bestückt ist. Auch ein paar Werkzeuge die ich nicht nutze, aber bestimmt für den ein oder anderen eine Alternative oder Ergänzung darstellen möchte ich kurz erwähnen.
Das Basiswerkzeug rpmbuild hat wohl jeder bereits einmal gesehen, der sich mit dem Thema befassen durfte. Unser Arbeitsmaterial Quelltext und Patches bereitgelegt, angewandt auf die Bauanleitung und es entstehen Schritt für Schritt oder auch in einem Rutsch sowohl Binärpakete als auch Sourcepaket. Letzteres kann alternativ auch als Ausgangspunkt dienen um ein Paket einfach für eine andere Zielplattform zu bauen. Und warum erwähne ich die Möglichkeit des schrittweisen Bauens? Einfach weil es mir so einfacher fällt das Spec-File zu entwickeln. Immer schön eine Sektion schreiben, testen, aus- oder verbessern und zur nächsten übergehen.
So ein bisschen was von Schweizer Armeemesser haben die rpmdevtools. Intial nutze ich hier rpmdev-setuptree um mir eine Buildumgebung aufzubauen. Die Templates von rpmdev-newspec und rpmdev-newinit stellen meist die Ausgangsbasis für die weitere Arbeit dar. Wenns mal wieder schnell gehen muss wird mit rpmdev-bumpspec die Version erhöht und ein Changelog-Eintrag erstellt bevor die neue Version gebaut wird. Bei komplizierter Nummerierung hilft rpmdev-vercmp und rpmdev-rmdevelrpms und rpmdev-wipetree unterstützen beim Hauskeeping. Die beiden letzten sind aber auch der Grund warum nur auf einer virtuellen Maschine paketiere. Selten genutzt werden die anderen Werkzeuge in dieser Sammlung, können aber auch sehr hilfreich sein.
Wenn ich rpmbuild als Schraubenschlüssel bezeichnet hätte dann wäre mock der Koffersatz mit allen Schraubenschlüsseln für jeden Schraubentyp. mock nimmt die gleiche Ausgangsbasis wie rpmbuild baut aber dann in einer chroot-Umgebungen Pakete für beliebige Architekturen und Distributionen. Aber nicht nur das, wenn ein Projekt neben dem Quelltext auch ein Spec-File in einem Git-Repository liegen kann, kann man mock die ganze Arbeit erledigen lassen. Es clont das Repository, baut ein Archiv und dann die Pakete. Wer dann auch gleich noch mehr auf einmal erledigt haben will nutz mockchain und lässt gleich mehrere Pakete bauen.
Die Wasserwaage zur Qualitätskontrolle stellt dann rpmlint dar. Dieses sollte gegen das Specfile, die nicht-installierten und installierten Pakete ausgeführt werden. Hierbei werden neben viele, viele formale Fehlern auch viele potentielle Probleme aufgezeigt. Einen Teil davon kann man sicher ignorieren, rpmlint aber komplett still zu bekommen sorgt sicher für ein qualitativ hochwertiges Paket.
Einen letzten Werkzeugsatz benötigt man um dann die Pakete der breiten Öffentlichkeit zugänglich zu machen. Einen GPG-Key und rpm zum Signieren der Pakete ist erstmal Grundvoraussetzung und sollte genutzt werden um aufzuzeigen, dass ein Paket qualitätsgesichert ist. Createrepo kann dann genutzt werden um die Pakete in einem Repository zu veröffentlichen. Createrepo kann auch mit Gruppeninformationen für die Installation versehen werden, diese können mit dem Tool yum-groups-manager erstellt werden.
Wer eine GUI braucht installiert sich das passende Modul in Eclipse. Wer einen Buildserver braucht den mehrere Package Maintainer gleichzeitig nutzen können, sollte sich den auf mock aufbauenden Buildserver koji anschauen, den das Fedora Projekt nutzt, oder er schaut sich den Werkzeugkasten der Suse-Welt an bis hin zum OpenSuse-Buildserver, alternativ gibt es aber auch kommerzielle Produkte für denjenigen der Support braucht. Aber mit all diesen Werkzeugen habe ich bisher wenig Erfahrung sammeln dürfen.
Ich hoffe dieser kleine Überblick hilft dem ein oder anderen. Auf meiner Agenda für diese kleine Serie steht nun noch eine kleine Einführung in Red Hats Software Collection als Konzept für Pakete zur parallelen Installation von Softwareversionen.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

RPM-Packaging: Die Bauanleitung

RPM-Icon from www.softicons.com used under LGPL
In diesem Blogpost möchte ich mich nach dem Quelltext mit der zweiten wichtigen Datei bei Paketbau befassen, dem Spec-File. Ich tituliere dieses immer als Bauanleitung und üblicherweise ist die Erstellung dieses meinen Hauptarbeit beim Paketieren.
Das Spec-File lässt sich in verschiedene Abschnitte aufteilen: Header, Preparation, Clean, Build, Install, Scriptlets, Files und Changelog.
Der Header beschreibt das Paket inklusive Abhängigkeiten und definiert eigene lokale Makros. Viele dieser Beschreibungsfelder werden allerdings durch die unterschiedlichen Programme ausgewertet und aufbereitet, so dass es hier für fast alles feste Vorgaben gibt an die man sich halten sollte. Details finden sich in den Packaging-Guidelines des Fedora-Projekts. Wichtig ist es auch zu wissen, dass hierbei mit Verzweigungen gearbeitet werden kann, so dass ein Spec-File auch für verschiedene Versionen einer Distribution oder auch verschiedene Distributionen verwendet werden kann. Allerdings muss dann sehr auf den Überblick geachtet werden.
Preparation ist der Abschnitt in dem der Quelltext entpackt und gepatcht wird. Dieser wird wie beim letzten Mal geschrieben besonders dann kompliziert wenn sich der Quelltext nicht an bestimmte Konventionen hält.
Clean ist eigentlich optional, da das Aufräumen des Verzeichnisses in dem der Paketbauprozess stattfindet nicht standardmäßig aufgerufen wird.
Build ist die Sektion in der der Quelltext mittels make oder anderen Werkzeugen übersetzt wird und kann entfallen wenn es sich um Pakete handelt, die dies nicht benötigen.
Im Abschnitt Install wird anschließend die Installation in das temporäre Verzeichnis durchgeführt. Üblicherweise in dem dieses Verzeichnis als Variable DESTDIR gesetzt wird und die INSTALL_OPTS auf einen leeren String gesetzt werden.
Scriptlets können bei der Installation und Deinstallation von Paketen ausgeführt werden, wobei es über die Abfrage wie oft ein Paket vorhanden ist, möglich ist beispielsweise Update und Deinstallation zu unterscheiden. Hierbei ist es wichtig darauf zu achten, dass der Rückgabewert immer 0 ist, so dass auch bei fehlschlagenden Skripten die Installation möglich ist. Auch sollten keine Änderungen an der eigentlichen Installation vorgenommen werden oder Dienste (neu-)gestartet werden.
Im Abschnitt Files werden die Dateien aus der Installation in das Paket übernommen. Hier werden die Rechte, Besitzer und Gruppe vorgegeben, aber auch bestimmte Kennzeichnungen vorgenommen. Eine Datei kann beispielsweise als Dokumentation gekennzeichnet werden oder als Konfigurationsdatei. Aufpassen sollte man, dass Dateien nicht als zu einem Paket gehörend markiert werden, die bereits durch ein anderes Paket zur Verfügung gestellt werden.
Ein übersichtliches Beispiel in dem doch alles vorkommt stellt das Spec-File für unseren EventDB Correlator dar.
Beim nächsten Mal will ich dann ein paar Werkzeuge und Hilfsmittel für die Paketentwicklung vorstellen.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

RPM-Packaging: Der Quelltext

RPM-Icon from www.softicons.com used under LGPL
Nachdem es mich in letzter Zeit immer öfter trifft, dass ein Kunde die Installation aus Paketen bevorzugt und es eigentlich auch mein bevorzugter Weg der Installation ist, wollte ich eine lockere Serien anfangen rund um das Thema.
Starten möchte ich mit dem Thema mit dem auch ein Paket startet und dass oftmals schon die ersten Hindernisse bereithält, dem Quelltext.
Ein RPM-Paket besteht prinzipiell aus zwei Dingen: dem Quelltext (wenn nötig mit Patches) und einer Bauanleitung, dem Spec-File. Im Spec-File wird angegeben von wo der Quelltext bezogen wird, wie dieser vorzubereiten, zu übersetzen und zu installieren ist, aber auch solche Themen wie die Lizenz unter der er veröffentlicht ist spielen eine Rolle.
Der Quelltext bleibt hierbei unverändert außer es müssen Dateien entfernt werden,die es lizenzrechtlich nicht erlauben sie zu verteilen. Daher muss alles was an Änderungen notfalls wichtig ist in Form eines Patches eingebracht werden. Warum dies leider oft notwendig ist, möchte ich im folgenden erläutern.
Mein Hauptgrund einen Patch hinzuzufügen ist die vorgesehene Installationsroutine. Diese besteht meist aus dem üblichen ./configure, make, make install, welche sich auch zum Paketieren eignet. Andere Optionen sind natürlich auch möglich, aber nur solang sie keine Interaktion erfordern. Wenn dies der Fall ist, schreibe ich diese üblicherweise gleich auf den Standard um.
Aber auch die übliche Make-Routine muss nicht immer eine gute Ausgangsbasis sein. Viele Entwickler sehen leider nur eine Installation in die von ihnen gewählten Standard-Pfade vor, meist /usr/local/bin oder ähnliches. Hierbei werden zur Sicherheit diese Verzeichnisse auch üblicherweise noch mittels install erstellt. Leider führt beides zu Problemen, denn bei der Erstellung eines RPM wird der Installationsvorgang von einem unpriviligierten Benutzer unterhalb eines speziellen Verzeichnisses durchgeführt, dem sogenannten Buildroot. Pfade außerhalb können also nicht angelegt werden und Dateien auch nicht anderen Benutzern übereignet werden.
Die Lösung hierfür sind mit configure konfigurierbare Pfade, da diese aber auch so in Konfigurationsdateien oder ähnlichem referenziert werden, muss noch ein weiterer Mechanismus genutzt werden um in die Buildroot zu installieren. Hierfür wird eine Variable DESTDIR genutzt, diese wird in den Makefiles dem eigentliche Zielpfad vorangestellt. Somit stehen in Konfigurationsdateien die echten Pfade wie beim Konfigurieren angegeben und die Installation erfolgt in diese Pfade relativ zur Buildroot.
Nun haben wir nach das Problem der Dateirechte. Werden diese beim install festangegeben, muss gepatcht werden. Guter Stil ist es diese als Variable INSTALL_OPTS zu hinterlegen, so dass diese auch in unserer Bauanleitung einfach überschrieben werden können.
Dies sind die üblichen Probleme. Patches um eine Hotfix einzupflegen solang noch kein Release erfolgt ist, sind dank git überhaupt kein Problem mehr. Fehlende Lizenzangaben finden sich ebenso immer seltener wie schlecht gepackter Quelltext, also ohne übergeordnetes Verzeichnis oder mit falscher Dateiendung.
Wenn sich nun Entwickler angesprochen fühlen und ihre Installationsroutine umschreiben wollen, habe ich ein paar Beispiele hierfür:
EDBC (Make-Routine für Systempfade umgebaut
Icinga-Cronk BP-Addon (phing durch make ersetzt)
Interfacetable_v3t (Make-Routine um DESTDIR ergänzt)
Und wenn nun jemand nach unseren Paketen fragt, kann ich leider nur weiter um Geduld bitten, aber wir arbeiten daran. Versprochen!

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Graphite auf CentOS, RHEL oder Fedora installieren

Um Graphite auf einem CentOS, RHEL oder Fedora zu installieren, muss das EPEL Repository eingebunden werden. Danach können die zu Graphite gehörenden Pakete installiert werden:

yum install python-whisper python-carbon graphite-web

Graphite-web benötigt noch eine Datenbank um Session- und Benutzerinformationen zu speichern, zum Beispiel MySQL:

# mysql -u root -p
mysql> CREATE DATABASE graphite;
mysql> GRANT ALL ON graphite.* TO graphite@localhost IDENTIFIED BY 'graphite';

Damit die erstellte Datenbank von Graphite-web genutzt wird, muss in der Datei /etc/graphite-web/local_settings.py folgende Konfiguration hinzugefügt werden:

DATABASES = {
  'default': {
    'NAME': 'graphite',
    'ENGINE': 'django.db.backends.mysql',
    'USER': 'graphite',
    'PASSWORD': 'graphite',
    'HOST': 'localhost',
    'PORT': '3306',
  }
}

Der Datenbank fehlt jetzt nur noch das Schema und ein administrativer Benutzer, die mit folgendem Kommando angelegt werden:

# /usr/lib/python2.6/site-packages/graphite/manage.py syncdb

Zum Abschluss muss in der Datei /usr/lib/python2.6/site-packages/graphite/settings.py nur noch der SECRET_KEY konfiguriert werden.

Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

OSDC 2014: Der Countdown läuft – nur noch 57 Tage

Andrew Ford setzt, in seinem Vortrag Software Packaging with RPM Demystified, dem Mangel an Information über das Packaging mit RPM, ein Konvolut praktischer Lösungsstrategien entgegen.

OSDC? Noch nie gehört…
Das ist aber schade und fast schon ein unentschuldbares Versäumnis!
Aber wir holen das nach:
Die Open Source Data Center Conference (kurz OSDC) ist unsere internationale Konferenz zum Thema Open Source Software in Rechenzentren und großen IT-Umgebungen. 2014 findet sie zum sechsten Mal statt und bietet mit dem Schwerpunktthema Agile Infrastructures ganz besonders erfahrenen Administratoren und Architekten ein Forum zum Austausch und die Gelegenheit zur Aneignung des aktuellsten Know-Hows für die tägliche Praxis. Diesmal treffen wir uns dafür in Berlin!
Workshops am Vortag der Konferenz und das im Anschluss an die Veranstaltung stattfindende Puppet Camp komplettieren dabei das Rundum-sorglos-Paket für Teilnehmer, die gar nicht genug Wissen in sich aufsaugen können.

Paketierung mit Ruby Gem FPM

Als Sysadmin kennt man das Problem: Man hat Software XYZ gepatcht oder möchte eigene Files über ein Paket bereitstellen und sucht dafür natürlich den schnellsten und einfachsten Weg. Für solche Angelegenheiten hat sich bereits das Urgestein “checkinstall” bewährt. Heut möchte ich eine Alternative dazu vorstellen.
Das Ruby Gem “FPM” bietet eine einfache Möglichkeit diverse Pakete aus diversen Quellen zu erstellen. So kann z.B. ein Verzeichnis angegeben werden, welches dann den Inhalt eines Paketes darstellt.

# fpm -s dir -t deb -a all -n mein-paket -v 1.0 /opt/mein-paket

FPM bietet eine Vielzahl an zusätzlichen Parametern, mit denen man beispielsweise den Paketmaintainer, die Version und Revision des Paketes, Post- und Pre-Skripte definieren kann. Hier lohnt sich ein genauer Blick in das Wiki des Projektes.