Bits, Bytes and my 5 cents » Fedora

Paketieren unter Linux

Patrick — Fri, 04 Jun 2010 07:08:05 +0000

Vorgestern und heute konnte ich mein erstes rpm-Paket erstellen. Da ich so was noch nie gemacht hatte, war es für mich eine gewisse Herausforderung.
Das Ergebnis sollte ein RPM-Paket sein, welches beim Installieren eine Ordnerstruktur anlegt, Files kopiert und danach ein Script ausführt. Beim Deinstallieren soll zuerst ein Script ausgeführt werden und dann die Kopierten Files wieder gelöscht werden.

Für jemand, der das schon ein paar mal gemacht hat, mag das einfach klingen, ich weiss – für mich war es aber alles andere als das

Jedoch, da ich auch schon mal für Windows paketiert habe, kann ich auch gleich einen Vergleich anstellen: Es ist viel unkomplizierter und einfacher unter Linux, wenn das SPEC-File mal steht… wenn

Doch nun zum Vorgehen!
Der Kern des Paketieren stellt das Programm rpmbuild und eine selbst erstellte SPEC-Datei dar.
Die SPEC-Datei kann man dabei wie eine Art Anleitung ansehen, wo aufgeschrieben wird, wann was getan werden soll. Anhand dieser Anleitung erstellt rpmbuild dann ein Paket.

Die allgemeine Funktionsweise habe ich mir aus dem Internet angeeignet. Besonders geholfen dabei hat mir diese Anleitung.

Das Problem aber, all diese Anleitungen basieren darauf, dass der Source aus dem Internet nachgeladen wird. Mein Paket musste aber alle Dateien lokal zur Verfügung haben.

Nun die erste Herausforderung: Wie mach ich das?
Nach viel probieren und testen hatte ich endlich eine Lösung… Unter dem Punkt %files werden die Dateien so aufgelistet, wie sie danach beim Zielsystem kopiert werden:

%files
/opt/itc/bin/soe-rootadd
/opt/itc/bin/soe-updatepubkeys
/opt/itc/prepost/install_post.sh
/opt/itc/prepost/remove_post.sh
/opt/itc/.sshsoe_id

Während dem Erstellen des Paketes mussten die Dateien aber im Ordner ~/rpmbuild/BUILDROOT/Paketname/opt/itc/../ liegen, damit es korrekt in das RPM integriert wird.

Die zweite Herausforderung war das Script: Unter %pre, wo ich auch alle Ordner erstellen liess, konnte ich das Script nicht starten, da zuerst %pre und danach erst %files abgearbeitet wird, wodurch das Script beim Starten noch gar nicht an seinem Platz ist.
Also habe ich es kurzerhand unter %install abgelegt. Doch aus welchem Grund auch immer – da wurde es nie gestartet…
Darauf habe ich ohne noch lange weiterzuprobieren, das Script unter %post abgelegt, welcher nach der Installation abgearbeitet wird.

Das die Dateien dann beim Deinstallieren wieder gelöscht werden, war ein kleines Problem. Einfach alles unter %preun eintragen und gut ist.

Mein SPEC-File sah am Schluss so aus:

...
%pre
mkdir -p /opt/itc/bin/
mkdir -p /opt/itc/ssh/pubkeys/
mkdir -p /opt/itc/prepost/
 
%post
/opt/itc/bin/install_post.sh
 
%preun
/opt/itc/bin/remove_post.sh
rm -f /opt/itc/bin/soe-rootadd
rm -f /opt/itc/bin/soe-updatepubkeys
rm -f /opt/itc/bin/install_post.sh
rm -f /opt/itc/bin/remove_post.sh
rm -f /opt/itc/.sshsoe_id
 
%prep
%build
%install
%clean
rm -rf $RPM_BUILD_ROOT
 
%files
/opt/itc/bin/soe-rootadd
/opt/itc/bin/soe-updatepubkeys
/opt/itc/prepost/install_post.sh
/opt/itc/prepost/remove_post.sh
/opt/itc/.sshsoe_id

Beim erstellen des Paketes zeigt sich dann die Stärke von Linux. Auf dem 32Bit System, welches ich zur Erstellung verwendet habe, habe ich ohne Probleme mit dem Parameter –target x86_64 ein Paket für 64Bit Systeme erstellt.
Das Begeistert mich deshalb so, denn unter Windows konnte ich auf einem 32Bit-Host auch nur ein Paket für dessen Architektur machen.
Und da ich schon damit gerechnet hatte, für jede Architektur ein eigenes Hostsystem aufzusetzen, war ich umso erfreuter

SELinux mag kein VMware

Patrick — Fri, 26 Mar 2010 15:39:59 +0000

Da ich soeben einen neuen PC erhalten habe, musste ich mein Fedora 12, mit welchem ich mich während der Arbeit rumschlage, neu installieren.
Das ganze war ja keine wirklich grosse Sache, neu installieren, Paketliste importieren und Home-Verzeichnis kopieren.
Trotzdem gibt es ja auch noch Pakete wie VMware Workstation, welche nicht im Repository gelistet sind.
Und gerade zum Testen finde ich VMware das beste was es gibt.

Die Installation von VMware ist ja spätestens seit Workstation 7 überhaupt kein Problem mehr. Downloaden, ausführen und dem Agent folgen. Doch nach der Installation, noch vor dem ersten Start, meldet VMware Workstation, dass es gerne noch ein paar Module kompilieren und in den Kernel laden würde. Doch als nach 20 Minuten immer noch nichts passiert ist, wurde ich stutzig.

Also habe ich mir während dem Starten mal die laufenden Prozesse angesehen, und auffällig war, dass sobald VMware mit seinen Anpassungen loslegen sollte, schnelle SELinux in die Höhe…

Also habe ich SELinux mal temporär deaktiviert:

1	echo 0 >/selinux/enforce

Und man glaubt es kaum, plötzlich macht auch VMware was es sollte…
Für mich wirft sich nun die Frage auf, wieso SELinux blockiert, ohne etwas zu melden?

Will man SELinux dann wieder aktivieren reicht ein reboot oder folgender Befehl:

1	echo 1 >/selinux/enforce

Oder man macht es wie ich und setzt in der Datei /etc/selinux/config den Punkt SELINUX auf disabled:

1
2
3

# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:

Nun ist SELinux nach einem Reboot komplett deaktiviert und wird sich nie mehr einmischen.

Kampf mit dem Citrix Receiver

Patrick — Fri, 05 Feb 2010 11:48:13 +0000

Um auf ein paar unserer Server zugreifen zu können, musste ich heute auf meinem Fedora 12 den Citrix Receiver installieren.
Am Anfang war ich noch glücklich darüber, dass ich die Installation nicht unter Debian / Ubuntu durchführen musste, da es schon fertige RPM-Pakete von Citrix gibt für Fedora.

Frisch fröhlich habe ich mit der Installation des Paketes begonnen:

1	rpm -i ICAClient-11.0-1.i386.rpm

Dummerweise besteht ein Abhängigkeitsproblem, also gleich mal yum durchrennen lassen:

2	yum install ICAClient-11.0-1.i386.rpm

Doch dummerweise findet auch yum das benötigte Paket libXm.so.3 nicht…

Nach ein bisschen googeln habe ich dann herausgefunden, dass man unbedingt openmotif installieren muss. Doch auch das scheint nirgends in den Paketquellen vorhanden zu sein??
Also lade ich mir das Paket halt manuell herunter und installiere es:

3	yum localinstall --nogpgcheck openmotif-2.3.1-1.RHEL3.0.i386.rpm

Soweit so gut, also gleich nochmal versucht den Receiver zu installieren.

Doch noch immer scheint libXm.so.3 nicht vorhanden zu sein… Nach weiterer Suchzeit auf Google habe ich noch ein weiteres benötigtes Paket gefunden:

4	yum install libXaw

Doch damit wurde libXm.so.6 und nicht wie benötigt libXm.so.3 installiert. Also muss man noch ein bisschen bescheissen:

5	ln -s /usr/lib/libXm.so.6 /usr/lib/libXm.so.3

Auch bin ich oft über die Aussage gestolpert, dass möglichweise ein paar Fonts rumzicken könnten:

6
7
8

cd /usr/share/fonts/cjkuni-uming/
mv fonts.dir fonts.dir.disabled
mv fonts.scale fonts.scale.disabled

und dann war es endlich soweit:

9	yum install ICAClient-11.0-1.i386.rpm

Jetzt konnte ich den Receiver endlich installieren.
Doch damit noch nicht genug, man sollte die Applikation ja auch starten können… Und genau daran haperte es noch!
Als Ausgabe erhielt ich immer:

10	/usr/lib/ICAClient/wfcmgr: Zeile 197: Vereinbarung: Kommando nicht gefunden.

Doch nach ein bisschen Überlegen und Nachdenken war das ein kleineres Problem. Denn wenn man den Fehler so liest, so habe ich gleich an ein Problem mit der Eula gedacht. Also mal recherchieren, wie man das Anzeigen der Lizenz umgehen kann

11	touch ~/.ICAClient/.eula_accepted

Und von nun an kann ich auch unter Fedora alle Citrix Applikationen gebrauchen:

12	/usr/lib/ICAClient/wfcmgr -icaroot /usr/lib/ICAClient