Autorenarchiv: Jörg Kastning

Changelog eines RPM-Pakets unter RHEL/CentOS anzeigen

Es kommt häufiger mal vor, dass ich mir das Changelog eines RPM-Pakets ansehen möchte, bevor ich dieses Paket auf meinem System installiere.

Dazu kann das Kommando repoquery aus dem Paket yum-utils verwendet werden. Der Aufruf erfolgt nach dem Muster:

repoquery --changelog PAKETNAME

Das folgende Listing zeigt beispielhaft das Changelog zum Paket open-vm-tools:

repoquery --changelog open-vm-tools.x86_64
* Fri Aug 14 2015 Richard W.M. Jones  - 9.10.2-4
- Enable PrivateTmp for additional hardening
  resolves: rhbz#1253698

* Wed Jul 29 2015 Richard W.M. Jones  - 9.10.2-3
- Enable deploypkg
  resolves: rhbz#1172335

* Mon Jul 27 2015 Richard W.M. Jones  - 9.10.2-2
- Disable vgauthd service in vmtoolsd.service file.
  resolves: rhbz#1172833

* Tue Jul 07 2015 Ravindra Kumar  - 9.10.2-1
- Package new upstream version open-vm-tools-9.10.2-2822639
- Removed the patches that are no longer needed
  resolves: rhbz#1172833

* Wed May 20 2015 Ravindra Kumar  - 9.10.0-2
- Claim ownership for /etc/vmware-tools directory
  resolves: rhbz#1223498

* Wed May 20 2015 Richard W.M. Jones  - 9.10.0-1
- Rebase to open-vm-tools 9.10.0 (synchronizing with F22)
  resolves: rhbz#1172833

* Fri Sep 19 2014 Richard W.M. Jones  - 9.4.0-6
- Really rebuild for updated procps
  resolves: rhbz#1140149

* Wed Sep 10 2014 Richard W.M. Jones  - 9.4.0-5
- Rebuild for updated procps
  resolves: rhbz#1140149

* Mon Aug 18 2014 Richard W.M. Jones  - 9.4.0-4
- Removed unnecessary package dependency on 'dbus'
- Moved 'vm-support' script to /usr/bin
- Added a call to 'tools.set.version' RPC to inform VMware
  platform when open-vm-tools has been uninstalled
- Add missing package dependency on 'which' (BZ#1045709)
- Add missing package dependencies (BZ#1045709, BZ#1077320)

* Tue Feb 11 2014 Richard W.M. Jones  - 9.4.0-3
- Only build on x86-64 for RHEL 7 (RHBZ#1054608).

Valides passwdfile für ldapsearch erstellen

Dieser Artikel beschreibt die Erstellung eines validen passwdfile für ldapsearch.

Die Man-Page zum LDAP search tool LDAPSEARCH(1) bietet die Möglichkeit, eine Passwortdatei zu nutzen:

-y passwdfile
              Use complete contents of passwdfile as the password  for  simple
              authentication.

Das passwdfile darf dabei ausschließlich das Passwort und keinerlei Newline-Zeichen („\n“) enthalten. Erstellt man diese Datei nun mit dem Editor vim oder vi, fügen diese Editoren automatisch ein Newline-Zeichen („\n“) an. Dies lässt sich überprüfen, indem man die Datei mit dem folgenden Kommando ausgibt:

od -c proxytest
0000000 S e c r e t P a s s w o r d 1 \n
0000020

Damit ist die Datei nicht mehr valide und kann nicht mit ldapsearch genutzt werden.

Um nun ein valides passwdfile zu erstellen, kann man folgendes Kommando verwenden:

echo -n SecretPassword1 > proxytest
od -c proxytest
0000000 S e c r e t P a s s w o r d 1
0000017

Die Ausgabe zeigt, dass in diesem Beispiel kein Newline-Zeichen mehr enthalten ist. Das passwdfile ist valide und kann mit dem Kommando ldapsearch verwendet werden.

Getestet wurde dies mit dem Kommando ldapsearch aus dem Paket openldap-clients-2.4.40-9.el7_2.x86_64 auf einem System mit RHEL 7.

Mein erstes RPM-Paket

Vorwort

Der Inhalt dieses Artikels ist nicht zur Nachahmung empfohlen. Ich halte an dieser Stelle fest, wie ich mein erstes RPM-Paket erstellt habe. Dieses funktioniert zwar und tut was es soll, doch ist es aus qualitativer Sicht noch ein weiter Weg, bis ich es selbst als gut bezeichnen würde. Der Artikel ist daher eher als ein Hilferuf zu verstehen. Ich freue mich, wenn mir geduldige, erfahrene Paketbauer in den Kommentaren Tipps geben, wie ich es besser machen kann.

Was habe ich getan?

Um die Installation des Tivoli TSM-Backup-Client 7.1.6 unter RHEL/CentOS/Fedora zu vereinfachen, habe ich für die Installation ein RPM-Paket erstellt. Der TSM-Backup-Client selbst wird vom Hersteller als TAR-Archiv bereitgestellt, welches die zur Installation benötigten RPM-Pakete enthält. Dazu gibt es eine Dokumentation, welche weitere z.T. optionale Abhängigkeiten aufführt. Darunter z.B. die Installation einiger Bibliotheken und eines Oracle JRE 1.7 oder höher.

All diese Dinge habe ich zusammen mit einem Skript, welches die initiale Installation und Konfiguration vornimmt, in ein RPM-Paket gepackt. Dieses Paket lässt sich auf dem Zielsystem installieren und durch die anschließende Ausführung des (selbst erstellten) Skripts tsm_init.sh werden die benötigten RPM-Pakete und Abhängigkeiten installiert.

Meine SPEC-Datei sieht wie folgt aus:

#---------------------------------------------------------------#
# version for using createRPM_* script
#---------------------------------------------------------------#
Name:      tsm-backup-client
Version:   7.1.6
Release:   1%{?dist}
Packager:  Tronde
Group:     Applications/System
Summary:   Tivoli TSM Backup Client for Linux

License:   non-free
URL:       http://example.com

BuildArch: x86_64
BuildRoot: %{_tmppath}/%{name}-%{version}

# $RPM_SOURCE_DIR : Variable of rpmbuild SOURCE dir
# $RPM_BUILD_DIR  : Variable of rpmbuild BUILD dir
# $RPM_BUILD_ROOT : Variable of rpmbuild BUILDROOT dir
#%define  

#BuildRequires:
Requires: libXrender
Requires: libXtst
Requires: libXp
Requires: xorg-x11-xauth

%description
This package installs the required packages and scripts for the
installation of the Tivoli TSM Backup Client for Linux.

The package contains:
 * bacli
 * tsm_init.sh
 * jre-8u91-linux-x64.tar.gz

#---------------------------------------------------------------#
# not used sections should be be set to comment
#---------------------------------------------------------------#
# The section '%prep' to extract the sourcefile 'Source0'
#%prep

# The section '%build' to build binaries from sources
#%build

# copy files to $RPM_BUILD_ROOT for using in the %files section
%install
cd $RPM_BUILD_ROOT
tar xvzf $RPM_SOURCE_DIR/%{name}.tgz
mv %{name}/* .
rmdir %{name}

# this files will be included in the rpm package
# with path on target host
%files
%defattr(-,root,root)
%doc
/root/bin/tsm_init.sh
/root/bin/start-tivoli-gui.sh
/data/bacli/gskcrypt64-8.0.50.66.linux.x86_64.rpm
/data/bacli/gskssl64-8.0.50.66.linux.x86_64.rpm
%doc /data/bacli/README_api_enu.htm
%doc /data/bacli/README_enu.htm
%doc /data/bacli/README
/data/bacli/cat_README.sh
/data/bacli/TIVsm-API64.x86_64.rpm
/data/bacli/TIVsm-APIcit.x86_64.rpm
/data/bacli/TIVsm-BAcit.x86_64.rpm
/data/bacli/TIVsm-BAhdw.x86_64.rpm
/data/bacli/TIVsm-BA.x86_64.rpm
/data/bacli/TIVsm-filepath-7.1.6-0-rhel59.x86_64.rpm
/data/bacli/TIVsm-filepath-7.1.6-0-rhel64.x86_64.rpm
/data/bacli/TIVsm-filepath-7.1.6-0-rhel7.x86_64.rpm
/data/bacli/TIVsm-filepath-7.1.6-0-sles11sp2.x86_64.rpm
/data/bacli/TIVsm-filepath-source.tar.gz
/data/bacli/TIVsm-JBB.x86_64.rpm
/data/jre-8u91-linux-x64.tar.gz

%clean
rm -rf %{buildroot}

# The section '%pre', for code to be executed prior to install
#%pre

# The section '%prerun' for code to be executed prior to uninstall
%preun

# the section '%post', for code to be executed after install
# normal sh script, prefs variables and macros can be used
%post

# The section '%postun' for code to be executed after uninstall
#%postun

%changelog
*Tue Jul 05 2016  Tronde 7.1.6-1
-- Initial Build.

Bisher erkannte Mängel

Mir sind bisher folgende Mängel aufgefallen:

  1. Nach der Installation des Pakets müssen die enthaltenen RPM-Pakete durch ein weiteres Skript installiert werden.
  2. Das Installationsskript muss manuell auf dem Zielsystem gestartet werden.
  3. Bei der Deinstallation werden die vom tsm_init.sh-Skript installierten RPM-Pakete nicht mit entfernt.

Meine Idee das tsm_init.sh-Skript in die Sektion %post zu packen hat leider nicht funktioniert, da ich die Paketverwaltung damit in einen Deadlock schicke. YUM ist noch durch den Installationsprozess blockiert, welcher mein RPM-Paket installiert und wartet darauf, dass der YUM-Aufruf aus meinem tsm_init.sh-Skript beendet werden kann. So geht es also nicht.

Was möchte ich eigentlich erreichen?

Erreichen möchte ich, dass durch die Installation eines RPM-Paktes die folgenden RPM-Pakete auf dem Zielsystem installiert werden:

  • gskcrypt64-8.0.50.66.linux.x86_64.rpm
  • gskssl64-8.0.50.66.linux.x86_64.rpm
  • TIVsm-API64.x86_64.rpm
  • TIVsm-BA.x86_64.rpm

Das Skript tsm_init.sh soll anschließend nur noch dazu verwendet werden, um den installierten TSM-Backup-Client mit einer initialen Konfiguration zu versehen. Ein zweites Skript soll an einem Ort abgelegt werden, von dem aus es ausgeführt werden kann.

Bisher ist meine einzige Idee, diese Aufgabe zu lösen, die vier genannten RPM-Pakete in ein YUM-Repository zu legen. In meiner SPEC-Datei kann ich sie dann als Abhängigkeiten definieren:

#BuildRequires:
Requires: gskcrypt64-8.0.50.66.linux.x86_64.rpm
Requires: gskssl64-8.0.50.66.linux.x86_64.rpm
Requires: TIVsm-API64.x86_64.rpm
Requires: TIVsm-BA.x86_64.rpm

Allerdings frage ich mich, ob es nicht auch eine Möglichkeit gibt, eine Art Meta-RPM zu erstellen, welches die benötigten RPMs enthält und diese Installiert. Ich könnte die Software auf diesem weg über ein einziges Paket bereitstellen.

Falls ihr Ideen oder Hinweise geben könnt, wie die Anforderung am besten umzusetzen ist, freue ich mich über eure Kommentare unter diesem Artikel.

SSH-Logins in RHEL/CentOS/Fedora auditieren

SSH-Logins werden unter RHEL, CentOS und Fedora in der Datei /var/log/secure protokolliert. Dieser Artikel beschreibt, wie man bei einem Audit den zum im Log protokollierten RSA-Fingerprint passenden SSH-Key identifiziert.

In dem hier beschriebenen Szenario wird angenommen, dass SSH-Logins ausschließlich über Public-Key-Authentifizierung zugelassen sind und die öffentlichen SSH-Schlüssel an zentraler Stelle im Dateisystem abgelegt sind. Darüber hinaus enthält jeder SSH-Schlüssel die E-Mail-Adresse des dazugehörigen Benutzers.

Authentifiziert sich ein Benutzer mit seinem öffentlichen SSH-Schlüssel an einem RHEL-, CentOS- oder Fedora-System, wird dies im Log /var/log/secure wie folgt dokumentiert:

Jun 18 15:34:55 hostname sshd[846]: Accepted publickey for tronde from X.X.X.X port 61362 ssh2: RSA cd:22:29:38:f7:e2:49:b1:a6:2f:8d:8f:cc:69:d7:c2

Neben Datum, Uhrzeit und dem verwendeten Benutzernamen wird hier der RSA-Fingerabdruck des verwendeten SSH-Publickey dokumentiert. Um nun herauszufinden, welcher SSH-Public-Key zu diesem Fingerabdruck gehört, nutze ich ein kleines Bash-Skript[1. Das Skript auf GitHub]:

#!/bin/bash
# Beschreibung:
# Dieses Skript gleicht einen RSA-Hash aus dem Log /var/log/secure mit den
# vorhandenen SSH-Public-Keys ab. Bei Uebereinstimmung wird der entsprechende
# Key ausgegeben.
#
# Der RSA-Hash wird dem Skript als Argument uebergeben.
#
# Autor: Joerg Kastning <joerg.kastning(aet)uni-bielefeld(punkt)de>

# Hauptteil #######################################################
rsa_fprint="$1"
printf "RSA-Fingerprint:\n${rsa_fprint}\n\n"
for key in *.pub
do
  tmp1=`/usr/bin/ssh-keygen -lf ${key}`
  set - $tmp1
  tmp2=`echo "$2"`
  if [[ "${rsa_fprint}" = "${tmp2}" ]]
  then
    printf "Der zugehoerige SSH-Key lautet:\n${tmp1}\n"
    exit 0
  fi
done
printf "Es wurde kein SSH-Key gefunden, welcher zu dem uebergebenen RSA-Fingerprint passt."
exit 0

Diesem Skript wird der RSA-Fingerabdruck als Argument übergeben. Das Skript generiert anschließend den RSA-Fingerabdruck aller SSH-Schlüssel in dem Verzeichnis, in dem das Skript aufgerufen wird und vergleicht diese mit dem übergebenen Fingerabdruck. Bei Übereinstimmung wird der zugehörige SSH-Schlüssel ausgegeben. Beispiel:

$ ./match_ssh-pubkey.sh cd:22:29:38:f7:e2:49:b1:a6:2f:8d:8f:cc:69:d7:c2
RSA-Fingerprint:
cd:22:29:38:f7:e2:49:b1:a6:2f:8d:8f:cc:69:d7:c2

Der zugehoerige SSH-Key lautet:
2048 cd:22:29:38:f7:e2:49:b1:a6:2f:8d:8f:cc:69:d7:c2  foo@example.com (RSA)
$

In diesem Beispiel gehört der verwendete SSH-Schlüssel dem Benutzer Foo. Auf diese Weise kann ein Audit mit einfachen Mitteln durchgeführt werden.

Ubuntu/Debian: PPA für PHP wechseln

In diesem Artikel dokumentiere ich den Wechsel eines PPA[1. „Personal Package Archive“] unter Ubuntu 14.04 LTS „Trusty Tahr“.

Achtung: Dies ist keine Schritt-für-Schritt-Anleitung. Die im Folgenden beschriebenen Schritte müssen auf einem anderen System nicht zwingend funktionieren. Fehler können euer System unbrauchbar machen. Also sagt nicht, ihr wurdet nicht gewarnt.

Warnung vor Fremdquellen: Die Benutzung fremder Quellen für Software sollte nach Möglichkeit auf das Notwendigste beschränkt werden, da sie einige gravierende Nachteile mit sich bringt.[2. ubuntuusers Wiki – Risiken von Fremdquellen]

Ich betreibe einen Server mit Ubuntu 14.04 LTS. In Trusty steht in den Originalquellen lediglich die PHP-Version 5.5.x zur Verfügung. Ich benötige jedoch PHP in Version 5.6.x und habe dazu das PPA ppa:ondrej/php5 in mein System eingebunden. Dieses PPA wurde nun von seinem Maintainer als deprecated markiert.

ppa:ondrej/php5 deprecated

ppa:ondrej/php5 deprecated

Der Maintainer stellt als Ersatz das PPA ppa:ondrej/php bereit. Dieses beinhaltet die PHP-Versionen 5.5, 5.6 und 7.0, welche auch nebeneinander installiert werden können.

Um dieses PPA meinem System hinzuzufügen, folge ich der PPA-Beschreibung[3. The main PPA for PHP (5.5, 5.6, 7.0) with many PECL[…]] und führe folgenden Befehl aus:

:~$ sudo LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php
 Co-installable PHP versions: PHP 5.5, 5.6, PHP 7.0 and batteries included.

You can get more information about the packages at https://deb.sury.org

For PHP 5.4 on Ubuntu 12.04 use: ppa:ondrej/php5-oldstable

BUGS&FEATURES: This PPA now has a issue tracker: https://deb.sury.org/#bug-reporting

PLEASE READ: If you like my work and want to give me a little motivation, please consider donating regularly: https://donate.sury.org/

WARNING: add-apt-repository is broken with non-UTF-8 locales, see https://github.com/oerdnj/deb.sury.org/issues/56 for workaround:

# LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php
 More info: https://launchpad.net/~ondrej/+archive/ubuntu/php
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmptgkt4t8k/secring.gpg' created
gpg: keyring `/tmp/tmptgkt4t8k/pubring.gpg' created
gpg: requesting key E5267A6C from hkp server keyserver.ubuntu.com
gpg: /tmp/tmptgkt4t8k/trustdb.gpg: trustdb created
gpg: key E5267A6C: public key "Launchpad PPA for Ondřej Surý" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK
:~$

Analog zu dem oben ausgeführten Befehl wird das alte PPA aus dem System entfernt:

:~$ sudo add-apt-repository -r ppa:ondrej/php5
 This PPA is going to be DEPRECATED, please use ppa:ondrej/php

If you need other PHP versions use:
  PHP 5.4: ppa:ondrej/php5-oldstable (Ubuntu 12.04 LTS)
  PHP 5.5, PHP 5.6 and PHP 7.0: ppa:ondrej/php (Ubuntu 14.04 LTS - Ubuntu 16.04 LTS)

WARNING: add-apt-repository is broken with non-UTF-8 locales, see https://github.com/oerdnj/deb.sury.org/issues/56 for workaround:

# apt-get install -y language-pack-en-base
# LC_ALL=en_US.UTF-8 add-apt-repository ppa:ondrej/php5
 More info: https://launchpad.net/~ondrej/+archive/ubuntu/php5
Press [ENTER] to continue or ctrl-c to cancel removing it
:~$

Hinweis: Durch das Entfernen des PPA wird die aus diesem PPA installierte Software nicht vom System entfernt.

Um zukünftig die Software aus dem neuen PPA zu nutzen, werden die folgenden Befehle ausgeführt. Bei dieser Gelegenheit habe ich gleich meine PHP-Version auf 7.0 aktualisiert:

:~$ sudo apt-get update
:~$ sudo apt-get --reinstall install php-pear
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  php-cli php-common php-xml php7.0-cli php7.0-common php7.0-json
  php7.0-opcache php7.0-readline php7.0-xml
Die folgenden NEUEN Pakete werden installiert:
  php-cli php-common php-xml php7.0-cli php7.0-common php7.0-json
  php7.0-opcache php7.0-readline php7.0-xml
Die folgenden Pakete werden aktualisiert (Upgrade):
  php-pear
1 aktualisiert, 9 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
Es müssen 2.284 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 9.839 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] J

Operation beendet, Webanwendung funktioniert noch, Happy End.

Roundcube mit PGP-Unterstützung

Vor Kurzem wurde Roundcube Webmail[1. Roundcube Webmail] in Version 1.2.0 veröffentlicht. Zu einer der Neuerungen zählt die Unterstützung von PGP. Dabei hat man die Wahl zwischen der client-seitigen Verschlüsselung, basierend auf der Browser-Erweiterung Mailvelope und der server-seitigen Variante mittels Enigma-Plugins.

In diesem Artikel stelle ich beide Varianten kurz vor und zeige einige Punkte auf, die beim Einsatz zu beachten sind.

Zu Beginn noch einmal kurz zur Erinnerung: OpenPGP verwendet asymmetrische Verschlüsselung[2. Asymmetrische Verschlüsselung], bestehend aus einem privaten und einem öffentlichen Schlüssel. Dabei gilt, dass der private Schlüssel unbedingt vor unberechtigtem Zugriff zu schützen ist.

Enigma-Plugin

Das Enigma-Plugin ist bereits Bestandteil von Roundcube 1.2.0. Aleksander Machniak beschreibt in seinem englischsprachigen Blog die Installation und Nutzung des Plugins.[3. Enigma plugin (PGP encryption)]

Das Plugin befindet sich demnach bereits auf dem gleichen Server, auf dem auch die Roundcube-Installation läuft. Besitzt man selbst die vollständige Kontrolle über diesen Server, ist die Nutzung des Enigma-Plugins eine komfortable Lösung.

In meinem Fall läuft der Server, welcher die Roundcube-Installation hostet, jedoch bei einem Hosting-Provider. Zwar habe ich root-Zugriff auf diesen Host, doch besitze ich nicht die vollständige Kontrolle über diesen Server. Es besteht die Möglichkeit, dass beim Provider ein Zugriff auf meinen Server und damit auch auf meinen privaten Schlüssel erfolgen kann.

Mir persönlich ist das Risiko der Kompromittierung meines privaten Schlüssels bei dieser Variante zu groß. Daher scheidet sie für mich aus.

Mailvelope

Mailvelope[4. Mailvelope Webseite] stellt über eine Browser-Erweiterung eine client-seitige OpenPGP-Verschlüsselung für Webmailer bereit. Es existieren Erweiterungen für Chrome und Firefox. Die Schlüssel werden dabei im Benutzerverzeichnis von Chrome bzw. im Profilordner von Firefox gespeichert.[5. Mailvelope – Wo werden meine Schlüssel gespeichert?] Die Chrome-Einstellung „Nutzungsstatistiken und Absturzberichte automatisch an Google senden“, sollte man jedoch besser deaktivieren. Andernfalls könnten im Falle eines Absturzes Speicherinhalte mit privaten Schlüsseln an Google gesendet werden.

Verschlüsselt man die Festplatte mit der Installation, in der sich der private Schlüssel befindet, ist dieser zusätzlich bei Verlust oder Diebstahl des Endgeräts geschützt.

Der Vorteil dieser Variante liegt in jedem Fall darin, dass sich die Schlüssel auf einem Endgerät befinden, über das der Besitzer in der Regel die vollständige Kontrolle hat. Gerade wenn die Roundcube-Installation bei einem Hosting-Provider betrieben wird, ist diese Variante daher in meinen Augen vorzuziehen.

Fazit

Dass Roundcube nun zwei Varianten zur Nutzung von OpenPGP-Verschlüsselung unterstützt, finde ich grundsätzlich positiv. Für beide genannten Varianten gibt es sinnvolle Einsatzszenarien.

In jedem Fall sollte man für einen konkreten Anwendungsfall abwägen, bei welcher Variante der private Schlüssel besser geschützt ist.

Für mich persönlich habe ich beschlossen, dass keine der beiden beschriebenen Varianten für mich in Frage kommen. Die Variante mit dem Enigma-Plugin scheidet für mich aus, da mein Mailserver bei einem Hosting-Provider betrieben wird und ich nicht die vollständige Kontrolle über den Host habe.

Die Variante mit Mailvelope kommt für mich nicht in Frage, da es mir nicht gefällt, dass die Schlüssel im Webbrowser gespeichert und verwaltet werden. Ich besuche mit meinem Webbrowser täglich dutzende Webseiten und nutze verschiedenste Webdienste. Dabei besteht grundsätzlich das Risiko, dass mein Webbrowser durch Malware kompromittiert wird. Mir persönlich ist die Gefahr zu groß, dass dabei auch mein privater Schlüssel kompromittiert bzw. entwendet wird.

Meinen E-Mail-Client verwende ich hingegen ausschließlich zum Lesen und Schreiben von E-Mails. Die Angriffsfläche ist hier wesentlich kleiner und das Risiko geringer, dass mein privater Schlüssel kompromittiert wird.

Erstellung eines Yum-Repositories

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

Konfiguration eines einfachen Git-Servers

Git ist ein freies Versionsverwaltungssystem für Dateien. In diesem Artikel wird die Konfiguration eines einfachen Git-Servers dokumentiert, der von Entwicklern genutzt werden kann, um ihren Code ein- bzw. auszuchecken.

Der Zugriff auf den hier beschriebenen Git-Server erfolgt ausschließlich über SSH. Die öffentlichen SSH-Schlüssel der Entwickler müssen in der Datei authorized_keys hinterlegt werden, bevor diese auf den Server zugreifen können. Doch ein Schritt nach dem anderen.

Installation von Git

Zuerst wird Git selbst auf dem Server installiert. Dies kann je nach verwendeter Distribution mit einem der folgenden Kommandos erledigt werden.

Für CentOS, Fedora, RHEL, etc.:

sudo yum install git

Für Debian, Ubuntu und Derivate:

sudo apt-get install git

Die benötigten Abhängigkeiten werden dabei von der Paketverwaltung selbstständig aufgelöst.

Git-Benutzer erstellen und SSH-Zugriff einrichten

Für die Verwendung des Git-Servers wird ein eigener Benutzeraccount erstellt. In diesem Beispiel wird dafür der Benutzer „git“ angelegt. Der Name ist jedoch frei wählbar.

Anschließend wird im HOME-Verzeichnis dieses Benutzers die Datei ~/.ssh/authorized_keys angelegt, in welche die öffentlichen SSH-Schlüssel der Benutzer eingefügt werden, welche den Server später verwenden sollen.


:~# useradd git -m
:~# su git
:~$ cd
:~$ mkdir .ssh && chmod 700 .ssh
:~$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys

Ein leeres Git-Repository erstellen

Um ein neues/leeres Git-Repository zu erstellen, meldet man sich als „git“-Benutzer an und führt die folgenden Befehle aus:

mkdir verzeichnis.git
cd verzeichnis.git
git init --bare
Initialisierte leeres Git-Projektarchiv in /home/git/verzeichnis.git/

Fertig. Damit wurde ein Git-Repository erzeugt, welches von anderen Rechnern für Push- und Pull-Operationen genutzt werden kann.

Hinweis: Für die Erstellung weiterer Repositories muss die obige Prozedur wiederholt werden.

Zusätzliche Absicherung des Git-Servers

Bisher können Anwender, deren öffentlicher SSH-Schlüssel in der Datei authorized_keys des Git-Servers hinterlegt ist, sich via SSH am Server anmelden und bekommen eine Login-Shell. Dies ist evtl. nicht in jedem Fall gewünscht. Daher wird im Folgenden beschrieben, wie man den Git-Server härten kann.

Um ein Login via SSH zu verhindern, gleichzeitig aber die Ausführung von Git-Operationen zu erlauben, kann eine andere Shell für den Git-Benutzer gesetzt werden. Ob die dafür erforderliche Shell bei der Installation von Git bereits mit installiert wurde, kann mit folgendem Kommando überprüft werden:

which git-shell

Ist die git-shell installiert, liefert das Kommando den Installationspfad zurück. Dieser Pfad wird der Datei /etc/shells hinzugefügt.

Um nun die Login-Shell für den Benutzer „git“ zu ändern, wird folgendes Kommando mit root-Rechten ausgeführt.

sudo chsh -s git-shell git

Repository auf einem Client nutzen

In diesem Abschnitt beschreibe ich, wie ein Repository von einem einfachen Git-Server auf einem Client genutzt werden kann. Dabei verwende ich folgende Werte für die Umgebung.

  • FQDN des einfachen Git-Servers: git.example.com
  • Repository-Name: verzeichnis.git

git-clone via SSH-Protokoll

$ git clone ssh://git@git.example.com/home/git/verzeichnis.git

Repository als remote hinzufügen

Ich habe häufig den Fall, dass ich lokal auf meinem Client bereits ein Git-Repository habe, welches ich in das Repository auf meinem einfachen Git-Server pushen möchte. Dazu füge ich dies als remote wie folgt hinzu:

git remote add git-example ssh://git@git.example.com/home/git/verzeichnis.git

Dabei ist git-example ein Name, der mich daran erinnert, auf welchem Server das Remote-Repository liegt.

Quellen und weiterführende Informationen

Lokaler Spiegelserver für CentOS, Fedora und RHEL

Durch die Nutzung eines lokalen Spiegelservers lassen sich Softwarepakete im lokalen Netzwerk bereitstellen. Dies schont die Internetverbindung und spart damit Bandbreite und evtl. Kosten.

Dieser Artikel beschreibt und dokumentiert die Einrichtung eines lokalen Spiegelservers für CentOS, Fedora und RHEL. Er bietet jedoch keine Schritt-für-Schritt-Anleitung. Für detaillierte Informationen wird auf die Quellen am Ende des Artikels sowie auf die manpages der einzelnen Kommandos verwiesen.

Konfiguration des Spiegelservers

Für den Betrieb eines lokalen Spiegelservers müssen ein Webserver sowie die CLI-Programme reposync und createrepo auf dem Host installiert werden, welcher als Spiegelserver dienen soll.

Hinweis für RHEL: Bei Verwendung von RHEL könnten nur jene Paketquellen gespiegelt werden, für welche der Spiegelserver eine gültige Subskription besitzt. Sollen auch solche Paketquellen gespiegelt werden, für die der Host keine Subskription besitzt, ist der Einsatz des kostenpflichtigen Satellite Servers erforderlich.

Diese Pakete befinden sich in der Regel in den Paketquellen, welche standardmäßig zur jeweiligen Distribution gehören. Für CentOS/RHEL können die Pakete zum Beispiel mit den folgenden Befehlen installiert werden:

$ sudo yum groupinstall "Einfacher Webserver"
$ sudo yum install yum-utils createrepo

Verwendet man bereits eine Fedora-Version mit dem YUM-Nachfolger DNF, so können die Pakete wie folgt installiert werden:

$ sudo dnf groupinstall "Web Server"
$ sudo dnf install yum-utils createrepo

Für eine Minimalkonfiguration des Webservers ist es erforderlich, den FQDN des Hosts als ServerName in der Datei /etc/httpd/conf/httpd.conf zu setzen.

Verwendet man die Hostfirewall, so ist der Zugriff auf den Webserver in dieser noch freizugeben.

$ sudo firewall-cmd --add-service http

Im nächsten Schritt wird unterhalb des Webserver-Wurzelverzeichnisses ein Verzeichnis erstellt, in dem zukünftig die gespiegelten Repositories abgelegt werden.

sudo mkdir /var/www/html/repomirror

Nun können mit reposync Pakete aus Online-Quellen auf den Spiegelserver heruntergeladen werden:

$ sudo reposync --gpgcheck -l --repoid= --download_path=/var/www/html/repomirror --downloadcomps --download-metadata -n

Die benötigte Repo-ID kann der ersten Spalte der Ausgabe von sudo yum repolist entnommen werden. Mit dem Parameter -n wird nur die aktuellste verfügbare Paketversion heruntergeladen.

Möchte man bspw. das base-Repository von CentOS spiegeln, so geschieht dies mit dem Kommando:

$ sudo reposync --gpgcheck -l --repoid=base --download_path=/var/www/html/repomirror --downloadcomps --download-metadata -n

Dadurch wird im Verzeichnis /var/www/html/repomirror das Unterverzeichnis base erstellt.

Damit die lokale Paketquelle nun von anderen Servern im lokalen Netzwerk genutzt werden kann, müssen noch die Metadaten mit Hilfe des folgenden Befehls erstellt werden. Beispiel für das base-Repository aus CentOS:

# cd /var/www/html/repomirror/base
# createrepo -v /var/www/html/repomirror/base/ -g comps.xml

Um den Abgleich der Paketquellen und die Erstellung der Metadaten zu automatisieren, kann folgendes Skript über den Cron-Dienst ausgeführt werden. Hier sind lediglich noch die REPO-ID und der Download-Pfad für die entsprechenden Variablen zu definieren.
#!/bin/bash
#
# Beschreibung: Skript zur Synchronisierung des RHEL-Repositories
# auf dem Spiegelserver
# Autor: Joerg Kastning <joerg(Punkt)kastning(aet)uni-bielefeld.de>

LOG="/var/log/do_reposync.log"
REPOID=" "
DOWNLOADPATH=" "

echo \# `date +%Y-%m-%d` - START REPOSYNC \# > $LOG

reposync --gpgcheck -l --repoid=$REPOID --download_path=/var/www/html/$DOWNLOADPATH --downloadcomps --download-metadata -n >> $LOG

echo \# `date +%Y-%m-%d` - END REPOSYNC \# >> $LOG
echo \# `date +%Y-%m-%d` - START CREATEREPO \# >> $LOG

cd /var/www/html/$DOWNLOADPATH/$REPOID
createrepo -v /var/www/html/$DOWNLOADPATH/$REPOID -g comps.xml >> $LOG

echo \# `date +%Y-%m-%d` - END CREATEREPO \# >> $LOG

exit 0

Erzeugung einer *.repo-Datei

Um die Paketquellen auf dem Spiegelserver zu verwenden, müssen diese auf dem Client bekannt gemacht werden. Dies geschieht zum Beispiel, indem auf dem Client eine *.repo-Datei im Verzeichnis /etc/yum.repos.d/ angelegt wird. Der Aufbau dieser Datei wird am Beispiel des CentOS-Repositories base demonstriert:

[base]
name= CentOS-$releasever - Base (local)
baseurl=http://FQDN/repomirror/base/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Legt man diese Datei auf dem lokalen Spiegelserver in einem Verzeichnis ab, welches über den Webserver erreichbar ist, kann sie von einem Client mit dem folgenden Kommando importiert werden:

# yum-config-manager --add-repo http://FQDN/repomirror/DATEINAME.repo

Besonderheit bei Verwendung von SELinux

Bei Verwendung von SELinux, müssen die Dateien noch mit dem Attribut httpd_sys_content_t ausgestattet werden. Für Dateien in /var/www/html geschieht dies mit:

restorecon -R -v /var/www/html/*

Quellen und weiterführende Links

Bash-Skript zur Aktualisierung einer Roundcube-Installation

In diesem Artikel möchte ich euch ein kleines Bash-Skript vorstellen, mit dem die Aktualisierung von Roundcube gesteuert werden kann.

Es führt ein Backup der Roundcube-Installation inkl. der dazugehörigen MySQL-Datenbank durch, lädt das TAR-Archiv der neuen Version herunter und aktualisiert die existierende Version.

Das Skript habe ich auf GitHub Gist unter der GPLv3 veröffentlicht. Ihr dürft es also gern unter den Bedingungen der GPLv3 verwenden, ändern und in eigene Projekte einbauen. Es kann auch am Ende dieses Artikels als ZIP-Archiv heruntergeladen werden.

Um das Skript nutzen zu können, müssen die vier Variablen am Anfang des Skripts definiert werden:

# Variablen
INSTALL_PATH=" " # Pfad zur Roundcube-Installation
RC_DB_NAME=" " # Name der zur Roundcube-Installation gehörenden MySQL-Datenbank
PACKAGE_URL=" " # Download-URL der akutellen Roundcube-Version
MYSQL_ROOT_USER=" " # MySQL-Benutzer mit Root-Rechten auf der Roundcube-Datenbank

Anschließend muss das Skript noch mit dem Befehl chmod a+x updating_roundcube.sh ausführbar gemacht werden.

Nun kann das Skript zur Aktualisierung der Roundcube-Installation ausgeführt werden. Getestet habe ich das Skript heute, um meine Roundcube-Installation von Version 1.0.8 auf Version 1.0.9 zu aktualisieren.

Downloads:

2017-03-25_updating_roundcube.zip