NETWAYS Blog

Nachdem es mich in letzter Zeit immer öfter trifft, dass ein Kunde die Installation aus Paketen bevorzugt und es eigentlich auch mein bevorzugter Weg der Installation ist, wollte ich eine lockere Serien anfangen rund um das Thema.
Starten möchte ich mit dem Thema mit dem auch ein Paket startet und dass oftmals schon die ersten Hindernisse bereithält, dem Quelltext.
Ein RPM-Paket besteht prinzipiell aus zwei Dingen: dem Quelltext (wenn nötig mit Patches) und einer Bauanleitung, dem Spec-File. Im Spec-File wird angegeben von wo der Quelltext bezogen wird, wie dieser vorzubereiten, zu übersetzen und zu installieren ist, aber auch solche Themen wie die Lizenz unter der er veröffentlicht ist spielen eine Rolle.
Der Quelltext bleibt hierbei unverändert außer es müssen Dateien entfernt werden,die es lizenzrechtlich nicht erlauben sie zu verteilen. Daher muss alles was an Änderungen notfalls wichtig ist in Form eines Patches eingebracht werden. Warum dies leider oft notwendig ist, möchte ich im folgenden erläutern.
Mein Hauptgrund einen Patch hinzuzufügen ist die vorgesehene Installationsroutine. Diese besteht meist aus dem üblichen ./configure, make, make install, welche sich auch zum Paketieren eignet. Andere Optionen sind natürlich auch möglich, aber nur solang sie keine Interaktion erfordern. Wenn dies der Fall ist, schreibe ich diese üblicherweise gleich auf den Standard um.
Aber auch die übliche Make-Routine muss nicht immer eine gute Ausgangsbasis sein. Viele Entwickler sehen leider nur eine Installation in die von ihnen gewählten Standard-Pfade vor, meist /usr/local/bin oder ähnliches. Hierbei werden zur Sicherheit diese Verzeichnisse auch üblicherweise noch mittels install erstellt. Leider führt beides zu Problemen, denn bei der Erstellung eines RPM wird der Installationsvorgang von einem unpriviligierten Benutzer unterhalb eines speziellen Verzeichnisses durchgeführt, dem sogenannten Buildroot. Pfade außerhalb können also nicht angelegt werden und Dateien auch nicht anderen Benutzern übereignet werden.
Die Lösung hierfür sind mit configure konfigurierbare Pfade, da diese aber auch so in Konfigurationsdateien oder ähnlichem referenziert werden, muss noch ein weiterer Mechanismus genutzt werden um in die Buildroot zu installieren. Hierfür wird eine Variable DESTDIR genutzt, diese wird in den Makefiles dem eigentliche Zielpfad vorangestellt. Somit stehen in Konfigurationsdateien die echten Pfade wie beim Konfigurieren angegeben und die Installation erfolgt in diese Pfade relativ zur Buildroot.
Nun haben wir nach das Problem der Dateirechte. Werden diese beim install festangegeben, muss gepatcht werden. Guter Stil ist es diese als Variable INSTALL_OPTS zu hinterlegen, so dass diese auch in unserer Bauanleitung einfach überschrieben werden können.
Dies sind die üblichen Probleme. Patches um eine Hotfix einzupflegen solang noch kein Release erfolgt ist, sind dank git überhaupt kein Problem mehr. Fehlende Lizenzangaben finden sich ebenso immer seltener wie schlecht gepackter Quelltext, also ohne übergeordnetes Verzeichnis oder mit falscher Dateiendung.
Wenn sich nun Entwickler angesprochen fühlen und ihre Installationsroutine umschreiben wollen, habe ich ein paar Beispiele hierfür:
– EDBC (Make-Routine für Systempfade umgebaut
– Icinga-Cronk BP-Addon (phing durch make ersetzt)
– Interfacetable_v3t (Make-Routine um DESTDIR ergänzt)
Und wenn nun jemand nach unseren Paketen fragt, kann ich leider nur weiter um Geduld bitten, aber wir arbeiten daran. Versprochen!

Dirk Götz

Principal Consultant

---

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Lies mehr von Dirk und triff unser Team