Schlagwort-Archive: Yum

Software-Pakete mit Ansible installieren

3 Antworten

In diesem sehr kurzen Beitrag möchte ich euch zeigen, wie ihr mit Ansible einen definierten Satz an Software-Paketen auf euren Linux-Hosts installieren könnt. Dies ist z.B. dann nützlich, wenn ihr bei der Provisionierung neuer Systeme sicherstellen möchtet, dass ein bestimmter Satz an Paketen vorhanden ist.

Natürlich kann man diese Aufgabe auch auf verschiedenen anderen Wegen lösen. Dies ist halt der Ansible-Weg. ;-)

---
- hosts: all
  tasks:
  - name: Install package baseline
    yum:
      name:
        - bind-utils
        - net-tools
        - chrony
        - ed
        - yum-utils
        - vim-enhanced
        - man-pages
        - strace
        - lsof
        - tcpdump
        - setroubleshoot-server
        - setroubleshoot
        - bash-completion
      state: latest
      update_cache: yes

Das obige Playbook zeigt ein einfaches Beispiel, wie auf einem RHEL/CentOS 7 System eine Liste von Paketen installiert werden kann. Dazu wird das Ansible-Modul yum verwendet. Der Parameter ’state‘ gibt an, dass immer die jeweils akutellste Version eines Pakets installiert werden soll. Mit ‚update_cache‘ wird definiert, dass der lokale Cache aktualisiert wird, bevor ein Paket zur Installation ausgewählt wird.

Für auf Debian/Ubuntu basierende Systeme gibt es das Modul apt. Für Fedora und RHEL/CentOS ab Version 8 nutzt man das Modul dnf.

Darüber hinaus gibt es noch das generische Modul package. Bei diesem ist jedoch zu beachten, dass die unterschiedlichen Paketmanager wie YUM und APT zum Teil unterschiedliche Paketnamen verwenden. Da ‚package‘ diese nicht automatisch übersetzt ist eine Verwendung über verschiedene Distributionen hinweg nicht ohne weiteres möglich. Daher empfinde ich dieses Modul als nutzlos.

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

Schreibe eine Antwort

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

Ansible – Das Modul yum_repository

4 Antworten

Das Ansible Modul yum_repositoryist dazu geeignet, Repositories zu RPM-basierten Linux-Distributionen hinzuzufügen bzw. zu entfernen. Es findet z.B. in unserer Umgebung Anwendung, um Repositories von unserem lokalen Spiegelserver anzubinden. Der folgende Text gibt ein Beispiel zur Anwendung dieses Ansible-Moduls.

Auf meiner Spielwiese verwende ich folgende Konfiguration, um zwei Repositories hinzuzufügen.

Hinweis: Die folgende Konfiguration ist nicht zur Nachahmung empfohlen. Es handelt sich dabei um meine ersten Schritte mit Ansible. Es ist daher wahrscheinlich, dass die Konfiguration noch Fehler enthält, nicht optimiert ist und ein großes Verbesserungspotenzial besitzt. Die Nachahmung erfolgt ausdrücklich auf eigene Gefahr. Über Hinweise, wie man es besser machen kann, freue ich mich jederzeit.

Verzeichnisstruktur

Abgeleitet aus den „Best Practices“ von Ansible, verwende ich auf meiner Spielwiese folgende Verzeichnisstruktur:

ansible/
|-- group_vars
|   `-- e-stage               # variables for group e-stage
|-- hosts                     # inventory file
|-- host_vars                 # for system specific variables
|-- roles
|   |-- common                # this hierarchy represents a "role"
|   |   |-- defaults          
|   |   |-- files
|   |   |-- handlers
|   |   |   `-- main.yml      #  handlers file
|   |   |-- meta
|   |   |-- tasks
|   |   |   `-- main.yml      #  tasks file can include smaller files if wanted
|   |   `-- vars
|   `-- std-repos
|       |-- defaults
|       |-- files
|       |-- handlers
|       |-- meta
|       |-- tasks
|       |-- templates
|       `-- vars
|-- set_repos.yml             # playbook which sets the repos
|-- site.yml                  # master playbook file
`-- staging                   # inventory file for staging environment

Das Playbook

Das Playbook ist sehr kurz gehalten und gibt im Wesentlichen nur an, welche Hosts auf welche Rolle gemapped werden sollen.

# set_repos.yml
---
- hosts: all
  roles:
    - std-repos

Das obige Playbook definiert, dass die Tasks aus der Datei roles/e-stage/tasks/main.yml ausgeführt werden sollen, welche wie folgt aufgebaut ist:

---
- name: Add rhel-e-stage-repository
  yum_repository:
    name: "{{ repo_name1 }}"
    description: "{{ repo_description1 }}"
    baseurl: "{{ repo_baseurl1 }}"
    gpgcheck: yes
    gpgkey: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

- name: Add my-own-repository
  yum_repository:
    name: "{{ repo_name2 }}"
    description: "{{ repo_description2 }}"
    baseurl: "{{ rebo_baseurl2 }}"
    gpgcheck: no

GroupVars

Nun existieren im Staging-Bereich häufig noch weitere Stages. So gibt es oftmals eine T-, E- und I-Stage. Dabei ist jeder Stage ein eigenes Stage-Repository zugeordnet. Um die Systeme in den unterschiedlichen Stages mit den dazugehörigen Stage-Repositories zu versorgen, werden diese mit Hilfe der group_vars den entsprechenden Gruppen zugewiesen.

Für die Server der Gruppe e-stage wird in der Datei group_vars/e-stage definiert:

# file: group_vars/e-stage
repo_name1: rhel-e-stage
repo_description1: Local RHEL-Repo for E-Stage
repo_baseurl1: http://repo.example.com/rhel-e-stage/

repo_name2: own-e-stage
repo_description2: Local OWN-Repo for E-Stage
repo_baseurl2: http://repo.example.com/own-e-stage/

Nach diesem Beispiel können nun weitere Variablen unter group_vars für andere Stages erstellt werden. Den Hosts in den entsprechenden Hostgruppen, werden auf diesem Wege die passenden Repositories hinzugefügt.

Erstellung eines Yum-Repositories

Schreibe eine Antwort

Nachdem ich im Artikel „Lokaler Spiegelserver für CentOS, Fedora und RHEL“ beschrieben habe, wie man Paketquellen auf den eigenen Server spiegeln kann, möchte ich in diesem Artikel dokumentieren, wie man ein Yum-Repository erstellt, um darüber z.B. eigene RPM-Pakete zur Verfügung zu stellen.

Auch für diesen Artikel gilt, dass es keine Schritt-für-Schritt-Anleitung ist. Weiterführende Informationen findet man unter den Links am Ende des Artikels oder in der manpage des jeweiligen Programms.

Voraussetzung dafür ist, dass wie beim lokalen Spiegelserver ein Webserver läuft, über welchen das Repository ausgeliefert werden kann. Darüber hinaus muss das Programm createrepo installiert sein, welches über das gleichnamige Paket bereitgestellt wird.

Für das eigene Yum-Repository wird ein Verzeichnis erstellt, welches vom Webserver ausgeliefert werden kann. Unter CentOS, RHEL und Fedora kann dies z.B. wie folgt erfolgen:

:~# mkdir /var/www/html/custom-rpms

In dieses Verzeichnis werden die RPM-Pakete kopiert, welche man über dieses Repository bereitstellen möchte. Anschließend wechselt man in das Verzeichnis und erstellt durch den Aufruf von createrepo die erforderlichen Meta-Daten.

:~# cd /var/www/html/custom-rpms
:~# createrepo --database /var/www/html/custom-rpms

Damit ist die Erstellung des Yum-Repositories bereits abgeschlossen.

Ergänzend kann man noch eine *.repo-Datei erstellen, um die Verwendung des Repository zu vereinfachen.

Quellen und weiterführende Links