NETWAYS Blog

Einmal lokaler Mirror? Kommt sofort!

von Dirk Götz | Okt 25, 2019 | Linux

Wer mich kennt, weiß dass ich gerne zu großen umfangreichen Lösungen neige. Daher ist meine bevorzugte Lösung für einen lokalen Mirror Katello, aber es gibt auch Situationen in denen man nur eine Version ohne Staging braucht. Beispiel aus dieser Woche ein „Icinga 2“-Satellite in China, der einfach nicht die Pakete von packages.icinga.com beziehen möchte. Auf seinem übergeordneten Satelliten in Singapur hat noch alles gut funktioniert und auch die Kommunikation zwischen beiden funktioniert auch gut. Also ist nach kurzer Überlegung der Plan gefasst, es soll ein lokaler Mirror her von dem in China installiert werden soll.

Um den Mirror aufzusetzen, setze ich auf die Kommandos reposync und createrepo, welche recht schnell installiert sind und keine Konfiguration benötigen.

yum install -y yum-utils createrepo

Mit reposync kann nur ein bereits konfiguriertes Repository gespiegelt werden. Da in diesem Fall auf beiden Systemen die gleiche Betriebssystemversion installiert ist, für mich kein Problem und es kann gleich weitergehen. Auch ist auf dem Satelliten bereits ein Webserver installiert um Icinga Web 2 als separates Webinterface für die asiatischen Kollegen anzubieten, also auch hier kein Handlungsbedarf. Der Mirror ist also schnell aufgesetzt.

mkdir -p /var/www/html/repo
reposync -r icinga-stable-release -p /var/www/html/repo/ -n
createrepo /var/www/html/repo/icinga-stable-release

Die Optionen bei reposync sind mit -r die Repository-ID aus der Yum-Konfiguration, -p das Zielverzeichnis und -n um nur die jeweils neuste Version herunterzuladen. reposync lädt allerdings nur die Pakete herunter und legt sie in der entsprechenden Struktur ab ohne die benötigten Metadaten. Diese werden dann mit createrepo erzeugt und schon kann mit der neu zur Verfügung gestellten URL das Repository eingebunden werden.

In vielen Fällen ist dies ausreichend, aber hier noch ein paar Tipps wenn es dann doch etwas mehr sein darf.

Zum regelmäßigen Updaten einfach die beiden Kommandos reposync und createrepo in einem Cronjob hinterlegen.
Ein Repository kann noch weitere Metadaten enthalten, beispielsweise die comps.xml mit Gruppeninformationen. Diese wird durch der Option --downloadcomps von reposync mit heruntergeladen und im aktuellen Arbeitsverzeichnis abgelegt. Bei createrepo wird diese wiederum mit -g comps.xml eingebunden.
Die Errata-Informationen können nicht mit reposync heruntergeladen werden, aber beispielsweise yum list-sec lädt diese lokal in den Cache. Kopiert man die updateinfo.xml dann aus dem Repository-Cache in /var/cache/yum/ in das synchronisierte Repository und führt modifyrepo /var/www/html/repo-id/repodata/updateinfo.xml /var/www/html/repo-id/repodata aus, wird diese Teil der Metadaten.
Sollen Repositories für ein anderes Betriebssystem zur Verfügung gestellt werden, kann eine Konfiguration erstellt werden, die aber nicht aktiv ist, also enabled=0 enthält. Bei reposync kann dann mit --enablerepo repo-id das Repository nur für die Synchronisation aktiviert werden.

Ich hoffe dieser kleine Artikel hilft dem ein oder anderen. Wem das schnelle einfache Repository nicht genug ist, der kann auch versuchen mit rsync einen vollständigen Mirror aufzusetzen oder mit Katello sogar ein Staging einbauen, damit Updates erst in Entwicklung und Test laden bevor sie in Produktion vielleicht Probleme verursachen. Bei letzterem unterstützen gerne ich oder ein Kollege im Rahmen eines Foreman-Consultings.

Dirk Götz

Principal 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.

Lies mehr von Dirk und triff unser Team

Azubis erzählen: April 2015 Alexander

von Alexander Klimov | Apr 13, 2015 | MySQL, Serien, Icinga, Team, Development

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.
Neben 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. 😉 )
An 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

Senior 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 Arbeit an Icinga Web 2 bei uns friedliche Wege.

Lies mehr von Alexander und triff unser Team

Icinga2 SELinux Policy sucht Tester

von Dirk Götz | Apr 3, 2015 | Linux, Icinga

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?

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

Principal Consultant

Lies mehr von Dirk und triff unser Team

Release packages for RPM repository configuration

von Michael Friedrich | Jan 29, 2015 | Monitoring & Observability, Linux, Technology

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 https://packages.icinga.com -O /etc/yum.repos.d/ICINGA-release.repo
# yum makecache

While 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:            https://packages.icinga.com
Source0:        %{name}-%{version}.tar.gz
Source1:        https://packages.icinga.com
Source2:        https://packages.icinga.com
Source3:        https://packages.icinga.com
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 https://packages.icinga.com
# yum search icinga2

See you in the icinga2 training sessions!

RPM-Packaging: Software Collections selbst gemacht

von Dirk Götz | Nov 28, 2014 | Linux

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 . 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

Principal Consultant

Lies mehr von Dirk und triff unser Team

« Ältere Einträge