RPM Build-Umgebung aufsetzen und RPM selbst bauen
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.
Development Umgebung aufsetzen
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
RPM Pakete mit PGP Key signieren
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.
Key erzeugen
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.
Key Auflisten
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>
Public-Key exportieren
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
Public-Key exportieren
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
Abfrage aller importierten GPG-Schlüssel
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>)
RPM Macros konfiguieren
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
Bestehendes RPM Paket signieren
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:
RPM Paket bauen und signieren
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): ...
RPM Paket Signatur überprüfen
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
RPM - Pakete bauen
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.
Softwarequellen downloaden
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
SPEC File anlegen
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
RPM-Paket(e) erzeugen
Die Ergebnisse unserer Paketbauaktion finden wir im Verzeichnis ~/rpmbuild/RPMS/.
Binär-Paket
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
Binär- und Quell-Paket
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