Schlagwort-Archive: RHEL

RHEL 7: Wie stelle ich sicher, dass nur Pakete aus unterstützten Quellen installiert sind?

In diesem Artikel dokumentiere ich (vor allem für mich selbst), wie man ein System in einen Zustand versetzen kann, in dem ausschließlich RPM-Pakete aus Repositories (Repos) installiert sind, für die man kommerziellen Support erhält.

Dazu gehe ich kurz auf den Hintergrund der Aufgabenstellung ein, bevor ich anschließend eine mögliche Lösung beschreibe.

Die Hintergrundgeschichte

Für meine ersten Gehversuche mit Red Hat Enterprise Linux habe ich mich unter der URL „https://developers.redhat.com/“ für eine Developer Subscription registriert. Diese gestattet die unbeschränkte Nutzung zu Forschungs- und Entwicklungszwecken.

Mit der Developer Subscription erhält man Zugriff auf eine ganze Reihe von Repos, aus denen man Software installieren kann. Etliche Pakete wie z.B. sed, less, etc. sind dabei in mehreren Quellen verfügbar.

Nach einer gewissen Evaluierungszeit sollte das System produktiv genutzt werden. Da eine produktive Nutzung in der Developer Subscription ausgeschlossen ist, wurde eine RHEL Standard Subscription für das System beschafft. Diese wurde dem System über den „Subscription Manager“ hinzugefügt. Die Developer Subscription wurde im Gegenzug entfernt.

Um zu überprüfen, ob auf dem System Pakete aus anderen Repos als „rhel-7-server-rpms“ installiert waren, wurde folgendes Kommando genutzt:

# yum list installed | grep -v "rhel-7-server-rpms\|anaconda"
Loaded plugins: product-id, search-disabled-repos, subscription-manager
Installed Packages
NetworkManager-config-server.x86_64
Red_Hat_Enterprise_Linux-Release_Notes-7-en-US.noarch
libdnet.x86_64 1.12-13.1.el7 @rhel-7-server-eus-rpms
libicu.x86_64 50.1.2-15.el7 @rhel-7-server-eus-rpms
libmspack.x86_64 0.5-0.4.alpha.el7 @rhel-7-server-eus-rpms
net-tools.x86_64 2.0-0.17.20131004git.el7 @rhel-7-server-eus-rpms
sed.x86_64 4.2.2-5.el7.sjis.1 @rhel-sjis-for-rhel-7-server-eus-rpms

# yum repolist enabled
Loaded plugins: product-id, search-disabled-repos, subscription-manager
repo id repo name status
rhel-7-server-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server (RPMs) 14,280
repolist: 14,280

Der Ausgabe ist zu entnehmen, dass fünf Pakete aus Quellen stammen, die auf dem System nicht mehr verfügbar sind. Diesen Zustand galt es zu ändern.

Die Lösung

Für die ersten vier Pakete bestand die Lösung darin, diese einfach neuzuinstallieren:

yum reinstall libdnet libicu libmspack net-tools

Bei sed stellte sich dieser Ansatz als problematisch heraus, da der Versuch das Paket neuzuinstallieren mit folgender Meldung quittiert wurde:

# yum reinstall sed
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
rhel-7-server-optional-rpms | 3.5 kB 00:00:00
rhel-7-server-rpms | 3.5 kB 00:00:00
rhel-server-rhscl-7-rpms | 3.5 kB 00:00:00
Installed package sed-4.2.2-5.el7.sjis.1.x86_64 (from rhel-sjis-for-rhel-7-server-eus-rpms) not available.
Error: Nothing to do

Der zweite Ansatz, das Paket erst zu entfernen und dann erneut zu installieren, scheiterte an der Überprüfung der Paket-Abhängigkeiten (Auszug der Ausgabe):

# yum remove sed
[...]
--> Finished Dependency Resolution
Error: Trying to remove "systemd", which is protected
Error: Trying to remove "yum", which is protected

Die Lösung gelang mit dem dritten Versuch. Hierbei wurde ein Downgrade auf die Paket-Version aus dem Repo „rhel-7-server-rpms“ durchgeführt:

# yum downgrade sed-4.2.2-5.el7.x86_64
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package sed.x86_64 0:4.2.2-5.el7 will be a downgrade
---> Package sed.x86_64 0:4.2.2-5.el7.sjis.1 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

===============================================================================================================================================================
Package Arch Version Repository Size
===============================================================================================================================================================
Downgrading:
sed x86_64 4.2.2-5.el7 rhel-7-server-rpms 231 k

Transaction Summary
===============================================================================================================================================================
Downgrade 1 Package

Total download size: 231 k
Is this ok [y/d/N]: y
Downloading packages:
sed-4.2.2-5.el7.x86_64.rpm | 231 kB 00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : sed-4.2.2-5.el7.x86_64 1/2
Cleanup : sed-4.2.2-5.el7.sjis.1.x86_64 2/2
Verifying : sed-4.2.2-5.el7.x86_64 1/2
Verifying : sed-4.2.2-5.el7.sjis.1.x86_64 2/2

Removed:
sed.x86_64 0:4.2.2-5.el7.sjis.1

Installed:
sed.x86_64 0:4.2.2-5.el7

Complete!
# yum list installed | grep sed
sed.x86_64 4.2.2-5.el7 @rhel-7-server-rpms

Am Ende des Listings ist zu sehen, dass sed nun aus dem Repo „rhel-7-server-rpms“ installiert wurde. Damit stammen nun alle Pakete wieder aus Quellen, die von einer Subscription mit Support abgedeckt.

Bei zukünftigen Installationen mit einer Developer Subscription werde ich jedoch von Anfang an darauf achten, dass nur die Repos verwendet werden, die auch in der RHEL Standard Subscription enthalten sind.

Verweise

SELinux Booleans

Bei SELinux Booleans handelt es sich um kleine Schalter, mit denen sich das Verhalten der SELinux-Richtlinien beeinflussen lässt. Dieser Artikel knüpft an die „Einführung in das grundlegende Konzept von SELinux“ an und erläutert die Verwendung von SELinux Booleans anhand eines einfachen Beispiels.

Hinweis: Das Beispiel aus diesem Artikel wurde auf einem RHEL/CentOS 7.3 getestet. Unter CentOS 7.2 funktioniert die hier gezeigte Konfiguration nicht. Für Details wird auf das Topic[2. Solved SELinux Booleans and httpd_enable_homedirs] im CentOS-Support-Forum verwiesen.

Im Einführungsartikel[3. „Einführung in das grundlegende Konzept von SELinux“] wurde SELinux dazu genutzt, um den Zugriff des Apache auf das DocumentRoot-Verzeichnis /var/www/html zu beschränken. Nun möchte der Webmaster den Benutzern gestatten, Webseiten über ihre HOME-Verzeichnisse zu veröffentlichen und aktiviert dazu die Konfiguration für das Modul Userdir.[4. Linux Basics: How To Enable Apache UserDir In CentOS 7/RHEL 7 {en}] [5. Enable Userdir in CentOS 7 {en}] [6. Apache: Benutzerspezifische Verzeichnisse – wiki.ubuntuusers.de]

[root@centos ~]$ cat /etc/httpd/conf.d/userdir.conf

    UserDir enabled
    UserDir public_html



    AllowOverride FileInfo AuthConfig Limit Indexes
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
    Require method GET POST OPTIONS


[root@centos ~]#

Nun kann ein Benutzer in seinem HOME-Verzeichnis den Ordner public_html erstellen und eine test.txt-Datei erstellen:

[jkastning@centos ~]$ mkdir public_html
[jkastning@centos ~]$ sudo chmod 711 /home/jkastning/
[jkastning@centos ~]$ sudo chmod 755 public_html/
[jkastning@centos ~]$ vim public_html/test.txt

Hello User

Nach einem Neustart des Dienstes httpd sollte sich nun die Datei index.html aus dem Benutzerverzeichnis abrufen lassen. Statt dessen wird der Zugriff verweigert.

apache_userdir_forbidden

httpd_enable_homdirs –> off

In den Logdateien finden sich Hinweise, die auf SELinux als Ursache hindeuten.

[root@centos ~]# tail /var/log/audit/audit.log|grep AVC
type=AVC msg=audit(1480446615.354:844): avc:  denied  { getattr } for  pid=23150 comm="httpd" path="/home/jkastning/public_html/index.html" dev="sda1" ino=1052157 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=file

[root@centos ~]# tail /var/log/messages | grep SELinux
Nov 29 20:10:44 centos setroubleshoot: SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html. For complete SELinux messages. run sealert -l 13419731-cedd-4433-abb7-b2e7715d5636

Um weitere Informationen zu erhalten, führen wir das Kommando aus /var/log/messages aus (Ausgabe gekürzt):

[root@centos ~]# sealert -l 13419731-cedd-4433-abb7-b2e7715d5636
SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html.

*****  Plugin catchall_boolean (24.7 confidence) suggests   ******************

If you want to allow httpd to enable homedirs
Then you must tell SELinux about this by enabling the 'httpd_enable_homedirs' boolean.
You can read 'None' man page for more details.
Do
setsebool -P httpd_enable_homedirs 1

In der obigen Ausgabe wird neben der Ursache auch gleich die Lösung mitgeliefert. Nach der Aktivierung des SELinux Boolean httpd_enable_homedirs kann der Inhalt der Datei index.html im Webbrowser abgerufen werden.

apache_userdir_allowed

httpd_enable_homedirs –> on

Damit wurde eine weitere Funktionalität von SELinux kurz vorgestellt. Für weiterführende Informationen sei auf die Manpages booleans(8)[6. booleans(8) – Linux man page {en}], getsebool(8)[7. getsebool(8) – Linux man page {en}] und setsebool(8)[8. setsebool(8) – Linux man page {en}] verwiesen.

Benutzer die Ausführung eines Skripts mit sudo gestatten

In diesem kurzen Tutorial wird beschrieben, wie man einem normalen Benutzer das Recht einräumt, ein einzelnes Skript mit sudo auszuführen. Das Tutorial ist auf alle Linux-Distributionen anwendbar, welche sudo[1. sudo – Wikipedia] unterstützen.

Schritt 1: Skript und Benutzerkonto erstellen

Zuerst wird natürlich das Skript benötigt, welches der neue Benutzer später ausführen soll. Als Beispiel mag hier folgendes einfaches Beispiel dienen:

#!/bin/bash
echo "Hallo Welt."

Wichtig! Der Benutzer, welcher das Skript später ausführen soll, darf selbst keine Schreibrechte auf darauf besitzen. Andernfalls könnte er das Skript bearbeiten und durch eintragen von bash eine root-shell öffnen. Danke an Gerald für diesen wichtigen Hinweis.

Der Benutzer kann, sofern er nicht schon existiert, mit folgendem Kommando angelegt werden:

sudo adduser USERNAME

Schritt 2: /etc/sudoers konfigurieren

Um einem Benutzer das Recht zu verleihen, gibt es grundsätzlich mehrere Möglichkeiten.

Benutzer einer Gruppe hinzufügen

Auf vielen Linux-Distributionen existiert bereits eine Gruppe, deren Mitglieder die Berechtigung zur Verwendung von sudo besitzen. Unter Ubuntu ist dies z.B. die Gruppe ’sudo‘. Unter RHEL, CentOS und Fedora ist dies bspw. die Gruppe ‚wheel‘. Um welche Gruppe es sich konkret handelt, kann in der Datei /etc/sudoers nachgeschlagen werden. Dort findet sich auf einem Ubuntu 16.04 LTS z.B. folgender Eintrag:

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

Da dem Benutzer im hier beschriebenen Fall jedoch nur erlaubt werden soll, ein einziges Skript mittels sudo auszuführen, ist diese Methode ungeeignet.

Benutzer in /etc/sudoers

Um einem Benutzer das Recht zu gewähren, ein bestimmtes Skript oder Programm mit sudo auszuführen, kann der Benutzer wie folgt in die Datei /etc/sudoers eingetragen werden.

Wichtig! Die Datei /etc/sudoers sollte nur als root mit dem Kommando visudo editiert werden, da hiermit eine Syntaxprüfung erfolgt. Eine Beschädigung der Datei /etc/sudoers, z.B. durch Syntaxfehler, kann dazu führen, dass das gesamte System unbrauchbar wird.

# User privilege specification
USERNAME    ALL=/path/to/script.sh

Mit obiger Zeile wird dem Benutzer ‚USERNAME‘ erlaubt, das Skript unter /path/to/script.sh mit sudo auszuführen.

Diese Methode ist bereits geeignet, um die gestellte Aufgabe zu lösen.

Datei unter /etc/sudoers.d/ erstellen

Unter aktuellen Versionen von Debian, Ubuntu, RHEL, CentOS und Fedora besteht die Möglichkeit, eine Datei im Verzeichnis /etc/sudoers.d/ zu erstellen, welche den Eintrag aus dem vorangegangenen Abschnitt enthält. Voraussetzung dafür ist, dass die Datei /etc/sudoers folgende Direktive enthält:

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Beachte: Das Zeichen ‚#‘ vor ‚includedir‘ stellt in diesem Fall kein Kommentarzeichen dar.

Diese Methode hat den Vorteil, dass die Datei /etc/sudoers unverändert bleibt und es bei Updates nicht zu einem Versionskonflikt kommen kann.

Fazit

Mittels /etc/sudoers ist es möglich, sudo-Berechtigungen granular an Benutzer zu delegieren. Neben dem in diesem Tutorial beschriebenen Beispiel existieren noch weitere Möglichkeiten. Beispiele dazu finden sich in der Manpage von sudoers.

Support-Subskriptionen von SUSE und RedHat

Nachdem ich an dieser Stelle bereits ausführlich über das kommerzielle Angebot Ubuntu Advantage berichtet habe, möchte ich in diesem Artikel kurz die Support-Subskriptionen von SUSE und RedHat vorstellen.

Die Subskriptionen

Beim SUSE Linux Enterprise Server (SLES) sowie dem RedHat Enterprise Linux (RHEL) handelt es sich um kommerzielle Produkte, welche nur mit einer gültigen Subskription verwendet werden dürfen.

Mit einer Subskription erhält man neben dem Recht, das erworbene Enterprise Linux verwenden zu dürfen, auch Zugriff auf Software-Paketquellen und darin enthaltene Updates für das Betriebssystem und enthaltene Software. Darüber hinaus umfassen die Subskriptionen Zugang zu Wissensdatenbanken und zu technischem Support. Für letzteren legen die einzelnen Subskriptionen auch das jeweilige Service-Level-Agreement fest.

Im Unterschied zu Ubuntu Advantage umfassen die in der folgenden Tabelle dargestellten Subskriptionen keine Verwaltungs-Werkzeuge, wie z.B. das von Canonical angebotene Landscape. Diese können sowohl bei SUSE, als auch bei RedHat zusätzlich erworben werden.

Die folgende Tabelle bietet eine Übersicht über die gängigen Support-Subskriptionen für SLES und RHEL:

 SLES StandardSLES PriorityRHEL StandardRHEL Premium
Subskription für1-2 Sockets oder 1-2 VMs1-2 Sockets oder 1-2 VMs2 Sockets, 1 physischer Server oder 2 VMs2 Sockets, 1 physischer Server oder 2 VMs
Software Upgrades & UpdatesJaJaJaJa
Anzahl Supportanfragenunbegrenztunbegrenztunbegrenztunbegrenzt
ZugangChat, Telefon und E-MailChat, Telefon und E-MailWeb und TelefonWeb und Telefon
Verfügbarkeit12x524x78x524x7
Reaktionszeiten
Stufe 12 Std.1 Std.1 Geschäfts-Std.1 Std.
Stufe 24 Std.2 Std.4 Geschäfts-Std.2 Std.
Stufe 31 Werktag4 Std.1 Werktag4 Std.
Stufe 41 Werktag1 Werktag2 Werktage8 Std. initial / 2 Werktage ongoing
Listenpreis pro Jahr670 EUR1.250 EUR700 EUR1.139 EUR

Die in der Tabelle enthaltenen Informationen beziehen sich auf die bei Veröffentlichung dieses Artikels aktuellen Angaben der Distributionen.

Die dargestellten Subskriptionen gelten für je einen physischen Server mit 1-2 CPU Sockets oder 2 VMs. Besitzt man einen physischen Server mit mehr als 2 CPU-Sockets muss eine Subskription mehrfach erworben werden, um diesen Server abzudecken. Besitzt ein Server bspw. 4 CPU-Sockets, muss die Subskription für diesen Server zweimal erworben werden. Möchte man die benötigte Anzahl der Subskriptionen für virtuelle Maschinen bestimmen, so lautet die Formel Anzahl VMs / 2 = Anzahl benötigter Subskriptionen.

Bei den Subskriptionen für virtuelle Maschinen spielt es dabei keine Rolle, ob diese mit Hilfe von VMware, Microsoft Hyper-V, XEN oder KVM betrieben werden.

Ab einer bestimmten Menge VMs ist es kostengünstiger statt Subskriptionen für einzelne VMs solche einzusetzen, welche das gesamte virtuelle Datacenter abdecken:

 SUSE für hochdichte VirtualisierungsumgebungenRed Hat Enterprise Linux for Virtual Datacenters
StandardPriorityStandardPremium
Gültig für1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen
Listenpreis für 1 Jahr1.330 EUR2.490 EUR2.192 EUR3.507 EUR

Die in der obigen Tabelle dargestellten Subskriptionen gelten jeweils für einen physischen Host, auf welchem virtuelle Maschinen ausgeführt werden. Zum Beispiel müssen für einen VMware vSphere-Cluster bestehend aus drei physischen Hosts mit je 1-2 CPU Sockets dann drei der entsprechenden Subskriptionen erworben werden. Auch hier gilt wieder, besitzt ein Host mehr als 2 CPU-Sockets, muss die jeweilige Subskription entsprechend mehrmals für diesen Host gekauft werden, bis die Gesamtzahl der CPU-Sockets pro Host abgedeckt ist.

Der Vorteil dieses Subskriptions-Modells liegt darin, dass hiermit beliebig viele VMs in einem virtuellen Datacenter betrieben werden können. Wird das virtuelle Datacenter jedoch um einen physischen Host erweitert, muss für diesen ebenfalls eine Subskription erworben werden, obwohl weiterhin die gleiche Anzahl VMs darauf ausgeführt wird. Je nach Kostenbetrachtung kann dies einen Nachteil darstellen.

Die folgenden Diagramme stellen den Break Even der jeweiligen Subskriptionen dar. Sie wurden für die Verwendung eines virtuellen Datacenters bestehend aus 3 Hosts mit jeweils 1-2 CPU Sockets berechnet.

Bei den in diesem Artikel verwendeten Preisen handelt es sich um Listenpreise. Beim Kauf von Subskriptionen über einen Fachhändler können je nach Umfang der Bestellung meist noch Rabatte gewährt werden.

Neben den hier betrachteten Subskriptionen existieren noch weitere für die Bereiche Forschung und Lehre sowie zur Erweiterung des Leistungsumfangs. Weitere Informationen dazu finden sich über die Links am Ende dieses Artikels.

Die in diesem Artikel enthaltenen Informationen wurden im Rahmen einer Linux-Evaluierung im Hochschulrechenzentrum der Uni Bielefeld erhoben.

Links