Ab und an kommt es vor, dass wir für ein Programm ein eigenes RPM-Paket bauen möchten, da wir z.B. spezielle Optionen beim Buildlauf nicht gesetzt wurde, die wir aber benötigen. Dies ist z.B. bei Dansguardian so der Fall. Oder wir benötigen auf mehreren Rechner ein RPM Paket, für das wir zwar die Programmsourcen, aber kein fertiges RPM Paket haben.
In all den Fällen werden wir unser eigenes passendes RPM-Paket bauen. Doch bevor wir unser erstes RPM Paket selbst bauen, benötigen wir noch ein paar Erweiterungen und es sind noch ein paar Konfigurationsschritte nötig. Dieses Kapitel beschreibt einen Workaround, wie dies von Statten gehen kann.
Im ersten Schritt bauen wir uns einen vHOST und installieren dort das Development-Paket.
# yum groupinstall Development -y
Anschließend legen wir im Home-Verzeichnis unseres RPM-Maintainers die nötigen Unterverzeichnisse an.
$ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
Zum Schluß setzen wir noch in der Konfigurationsdatei .rpmmacros im Homeverzeichnis des Nutzers das gearade angelegt Arbeitsverzeichnis.
$ echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros
Wollen wir unsere RPM-Pakete auch anderen zur Verfügung stellen, wird man diese in aller Regel signieren, damit der Empfänger eine Möglichkeit hat, sich von der Integrität/Unversehrtheit des RPM Paketes überzeugen kann.
Sofern wir noch keinen PGP Key zum Signieren der Pakete angelegt haben, erzeugen wir diesen.
$ gpg --gen-key
gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
(1) RSA und RSA (voreingestellt)
(2) DSA und Elgamal
(3) DSA (nur unterschreiben/beglaubigen)
(4) RSA (nur signieren/beglaubigen)
Ihre Auswahl? 4
RSA-Schlüssel können zwischen 1024 und 4096 Bit lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
0 = Schlüssel verfällt nie
<n> = Schlüssel verfällt nach n Tagen
<n>w = Schlüssel verfällt nach n Wochen
<n>m = Schlüssel verfällt nach n Monaten
<n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0)
Schlüssel verfällt nie
Ist dies richtig? (j/N) j
GnuPG erstellt eine User-ID um Ihren Schlüssel identifizierbar zu machen.
Ihr Name ("Vorname Nachname"): Django
Email-Adresse: rpmbuild@nausch.org
Kommentar: RPM Build Maintainer
Sie haben diese User-ID gewählt:
"Django (RPM Build Maintainer) <rpmbuild@nausch.org>"
Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(B)eenden? f
Sie benötigen eine Passphrase, um den geheimen Schlüssel zu schützen.
can't connect to `/home/django/.gnupg/S.gpg-agent': Datei oder Verzeichnis nicht gefunden
Wir müssen eine ganze Menge Zufallswerte erzeugen. Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
gpg: Schlüssel 7C65AB27 ist als uneingeschränkt vertrauenswürdig gekennzeichnet
Öffentlichen und geheimen Schlüssel erzeugt und signiert.
gpg: "Trust-DB" wird überprüft
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: Tiefe: 0 gültig: 1 unterschrieben: 0 Vertrauen: 0-, 0q, 0n, 0m, 0f, 1u
pub 4096R/7C65AB27 2011-10-15
Schl.-Fingerabdruck = CE57 3461 A0AA A36E 9057 BCDA 31B4 758F 7C65 AB27
uid Django (RPM Build Maintainer) <rpmbuild@nausch.org>
Bitte beachten Sie, daß dieser Schlüssel nicht zum Verschlüsseln benutzt
werden kann. Sie können aber mit dem Befehl "--edit-key" einen
Unterschlüssel für diesem Zweck erzeugen.
Den gerade erzeugten Schlüssel können wir uns mit Hilfe der Option list-keys beim Befehl gpg anzeigen lassen.
$ gpg --list-keys
/home/django/.gnupg/pubring.gpg ------------------------------- pub 4096R/7C65AB27 2011-10-15 uid Django (RPM Build Maintainer) <rpmbuild@nausch.org>
Zum Überprüfen der PGP-Signaturen benötigt man später den public-key, daher werden wir diesen nun exportieren, damit wir diesen im Repository auch veröffentlichen können.
$ gpg --export -a Django > GPG-PUB-KEY.asc
Zum Überprüfen der RPM Signatur(en) importieren wir den Schlüssel in die RPM Datenbank. Dies machen wir als User root.
$ su -
# rpm --import /home/django/GPG-PUB-KEY.asc
Bei Bedarf können wir uns alle importierten public-keys der RPM Datenbank anzeigen lassen.
$ rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'
gpg-pubkey-c105b9de-4e0fd3a3 --> gpg(CentOS-6 Key (CentOS 6 Official Signing Key) <centos-6-key@centos.org>) gpg-pubkey-7c65ab27-4e99acfb --> gpg(Django (RPM Build Maintainer) <rpmbuild@nausch.org>)
Abschließend erweitern wir unser RPM-Macro-Konfiguration, damit zum Signieren der Pakete auch der richtige Schlüssel verwendet werden kann.
$ echo '%_signature gpg' >> ~/.rpmmacros $ echo '%_gpg_name Django' >> ~/.rpmmacros
Möchte man ein bereits erstelltes RPM Paket signieren so verwendet man einfach die Option –addsign beim Befehl rpm.
$ rpm --addsign ~/rpmbuild/RPMS/x86_64/dansguardian-2.10.1.1-1.el6.x86_64.rpm
Bitte das Passwort eingeben: Das Passwort ist richtig. /home/django/rpmbuild/RPMS/x86_64/dansguardian-2.10.1.1-1.el6.x86_64.rpm:
Will man bereits beim Bau des RPM Paketes selbiges signieren, verwendet man die Option –sign beim Aufruf des build-Befehls.
$ rpmbuild -ba --sign ~/rpmbuild/SPECS/dansguardian-2.10.1.1-1.spec
Bitte das Passwort eingeben: Das Passwort ist richtig. Ausführung(%prep): ...
Die Signatur eines RPM Paketes kann man mit Hilfe der Option –checksig beim Aufruf des Befehls rpm überprüfen.
$ rpm --checksig ~/rpmbuild/RPMS/x86_64/dansguardian-2.10.1.1-1.el6.x86_64.rpm
/home/django/rpmbuild/RPMS/x86_64/dansguardian-2.10.1.1-1.el6.x86_64.rpm: rsa sha1 (md5) pgp md5 OK
Möchten wir ein RPM-Paket selbst bauen, benötigen wir neben den nötigen Programmquellen ein SPEC-File. In diesem Spec-File wird angegeben, wie ein entsprechendes Paket zu bauen ist.
Wir laden also nun den sourcecode des gewünschten Programms auf unseren Rechner. Hierzu wechseln wir erst einmal in unser SOURCE-Verzeichnis unserer Build-Umgebung.
$ cd ~/rpmbuild/SOURCES/
Anschließend laden wir uns das gewünschte Soure-Paket auf unseren Build-Hostmit wget.
$ wget http://dansguardian.org/downloads/2/Stable/dansguardian-2.10.1.1.tar.gz
Das zum Übersetzen notwendige SPEC-File legen wir im Build-Verzeichnis ~/rpmbuild/SPECS/ ab. Mit dem Editor unserer Wahl bearbeiten wir nun unseres Spezifkations-datei.
$ vim ~/rpmbuild/SPECS/dansguardian-2.10.1.1-1.spec
Die Ergebnisse unserer Paketbauaktion finden wir im Verzeichnis ~/rpmbuild/RPMS/.
Wollen wir nur das Binary-paket bauen, so benutzen wir beim Aufruf des Befehles rpmbuild die Option bb.
$ rpmbuild -bb ~/rpmbuild/SPECS/dansguardian-2.10.1.1-1.spec
Möchten wir das Paket nach dem erstellen auch gelich noch signieren, so ergänzen wir die Option –sign.
$ rpmbuild -bb --sign ~/rpmbuild/SPECS/dansguardian-2.10.1.1-1.spec
Wollen wir nicht nur das Binary-Paket bauen, sondern auch ein Paket mit den Softwarequellen, so benutzen wir beim Aufruf des Befehles rpmbuild die Option ba.
$ rpmbuild -ba ~/rpmbuild/SPECS/dansguardian-2.10.1.1-1.spec
Möchten wir das Paket nach dem erstellen auch gelich noch signieren, so ergänzen wir die Option –sign.
$ rpmbuild -ba --sign ~/rpmbuild/SPECS/dansguardian-2.10.1.1-1.spec