Running RedHat SCL PostgreSQL with Puppet

On a test system for a customer I wanted to bring up a newer PostgreSQL version on CentOS 7 (same for RHEL 7). Software Collections (also for RedHat) gives you a neat distribution method that is not very invasive into your existing distribution. So you can install a PostgreSQL 9.4 under RHEL 7 without replacing any of the existing packages. This is a bit tricky in terms of paths, but just works.
I found a relatively simple way to install, configure and run such a SCL with Puppet, with just using the existing PostgreSQL module.
https://gist.github.com/lazyfrosch/1926b17d1d605bfb819e899ef6bd4b63
Have fun trying it out and let me know what you think.

Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

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.

Spiegeln unter dem roten Hut

In vielen unserer Umgebungen nutzen wir DRBD zur Spiegelung der Festplatten über zwei Server hinweg. So lassen sich Hochverfügbarkeitskonzepte auch ohne den Einsatz einer shared Storage aufbauen.
DRBD wird bei vielen Distributionen schon im Standart Package Repository mitgeliefert. Die Ausnahme der Regel machen hier die “Kommerziellen”.
Bei SuSE Linux Enterprise Server muss dafür die HA Extension gekauft werden. Bei RedHat ist es leider nicht in der Cluster Suite enthalten. Abhilfe schafft hier das CentOS Extra Repository.

rpm --import http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
yum install drbd83 kmod-drbd83

Das ganz klappt bis RHEL 5.6 wunderbar, ab Version 6 stehen leider derzeit noch keine RPM Pakete zur Verfügung.
Kein Problem, kompilieren wir uns das ganz doch einfach selbst und weil wir nicht auf den Kopf gefallen sind bauen wir auch direkt RPM Pakete daraus um uns den Schritt für den zweiten Node zu ersparen.
Fangen wir mit den Vorbereitungen für unser DBRD Menü an:
Zutaten bereitlegen

yum install kernel-devel rpm-build gcc bison flex
wget http://oss.linbit.com/drbd/8.3/drbd-8.3.10.tar.gz
tar xzvf drbd-8.3.10
cd drbd-83.10
cp /boot/config-`uname -r` .config

Zutaten verrühren

./configure --with-km --with-utils
make
cd drbd
make clean all

In den Backofen schieben
Als erstes erstellen wir die DRBD Pakete (DRBD, DRBD Utils, DRBD Hearbeat- und Pacemakerskripte, DRDB-Xen etc.) und anschließend das Paket was uns DRBD als Kernel Modul lädt.

make rpm
make km-pm

Verzehr

cd /root/rpmbuild/RPMS/x86_64 (oder i368)
rpm -ivh drbd-*.rpm

Zum Abschluß können die erstellten DRBD RPM Pakete auf den zweiten Node kopiert und installiert werden.