• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

OpenSuSE Build service?

goeba

Hacker
Moin,

ich habe folgendes Problem: Ich würde gerne die Software "italc" verwenden.

Für diese gibt es eine Version 3.0, SuSE hat aber - auch in der aktuellsten Distro - nur 2.02.

Ich müsste das jetzt auf ca. 200 Rechner verteilen, diese sind gemischt 32 bit / 64 bit und haben alle OpenSUSE 13.2 als System.

Ich habe auf meinem Rechner 3.0 kompiliert und getestet, einfacher wäre die Verteilung aber mit einem rpm, oder noch besser, mit einem Repository, das ich einbinden kann. Das ginge dann alles skriptgesteuert und mit zypper auf der Konsole.

Wäre da der Open SuSE Build Service eine Lösung? Ich habe gesehen, dass für Fedora auf dem Build Service auch schon jemand Italc 3.0 gebaut hat.

Also, langer Rede kurzer Sinn: Hat das schon mal jemand benutzt, wie kompliziert ist das, wäre das eine Lösung für mein Problem?

Viele Grüße,

Andreas
 

Sauerland

Ultimate Guru
Also, langer Rede kurzer Sinn: Hat das schon mal jemand benutzt, wie kompliziert ist das, wäre das eine Lösung für mein Problem?
1. ja
2. kommt darauf an
3. ja.

Lade dir das Fedora.src.rpm herunter, dann siehst du, was alles drin ist.

Baue es dann auf deinem PC zuerst.
wenn es dort funktioniert, sind die Aussichten größer, das es im OBS auch funktioniert.

Ein paar Links:
http://rpm5.org/docs/rpm-guide.html
http://dokuwiki.nausch.org/doku.php/centos:rpmbuild
https://presentations.nordisch.org/packaging-oSC2014/#/
http://wiki.rosalab.ru/en/index.php/Rpmlint_Errors

PS:
Ich müsste das jetzt auf ca. 200 Rechner verteilen, diese sind gemischt 32 bit / 64 bit und haben alle OpenSUSE 13.2 als System.
https://lists.opensuse.org/opensuse-security-announce/2016-11/msg00030.html
 
OP
G

goeba

Hacker
Hallo Sauerland,
danke für die Hinweise.

Ich habe angefangen mich da hindurchzulesen, ich denke, das ist mir zu kompliziert. Wenn ich merke, dass ich unbedingt italc 3.0 brauche, verteile ich vermutlich einfach die nötigen Dateien per rsync und versuche, für alle Maschinen die 32 bit Version zu nehmen.

Zu Deinem Sicherheitshinweis: Für wie groß hälst Du das Risiko, wenn da einige veraltete Clients hinter einer Firewall (professionell gewartet, nicht von mir) in einem lokalen Netz stehen? Ich werde die frühestens im kommenden Sommer umstellen.

Gruß,

Andreas
 

Sauerland

Ultimate Guru
https://de.opensuse.org/openSUSE:Build_Service_Anleitung

Für wie groß hälst Du das Risiko, wenn da einige veraltete Clients hinter einer Firewall (professionell gewartet, nicht von mir) in einem lokalen Netz stehen?
Das musst du als Admin entscheiden.
 

josef-wien

Ultimate Guru
Wenn Sicherheitslücken wie z. B. seinerzeit Hartbleed oder HEUR:Backdoor.Java.Agent.a entdeckt werden, bekommst Du für ein veraltetes System schlicht und einfach keine updates mehr, die sie beheben. Bei solchen Vorkommnissen kann Dir die beste firewall nicht helfen.

Bei 200 zu verwaltenden Rechnern sollten doch ohnehin interne Repos vorhanden sein, in die auch Deine neuen 32- und 64-Bit-Pakete aufgenommen werden können. Wenn Du diese Pakete nicht auch anderen Leutem zur Verfügung stellen willst, sehe ich keinen Grund, sie zusätzlich im build service abzubilden.
 
OP
G

goeba

Hacker
@josef : Wenn der Aufwand nicht zu groß wäre, hätte ich natürlich nichts dagegen, anderen Usern die Pakete zur Verfügung zu stellen. Ich nutze ja selbst auch Pakete aus dem Build Service.

Ich hatte allerdings gehofft, dass es da stärkere Automatismen gibt. Wäre es nicht z.B. vorstellbar, dass ich in einer virtuellen Maschine ein ./configure make install ausführe und aus einem diff zwischen vorher und nachher automatisch ein rpm erstellt wird?

Aber nach der Komplexität der Unterlagen scheint mir der Aufwand für einen User der Software erheblich zu groß zu sein.

@josef + sauerland: Ich sehe das Risiko für Clients als gering an. Wenn man mal bedenkt, wie häufig noch WinXP eingesetzt wird ...
 

TomcatMJ

Guru
Wenn du ein rpm auf die Schnelle bauen willst und vorher schon mit dem bekannten "Dreisatz"
Code:
./configure
make
make install
gearbeitet hast, wäre
Code:
checkinstall
anstelle des letzten Schritts aus dem "Dreisatz" für dich vielleicht noch eine Alternative...dazu muss dann auf den Zielrechnern natürlich derselbe Softwarestand wie auf deinem Build-System vorliegen um keine fehlenden Libs irgendwo erst später zu bemerken ;)
 
Oben