Re: createrepo listet nicht vollständig alle RPMs
Tim Landscheidt <tim(a)tim-landscheidt.de> hat am 20. November
2013 um 20:48
geschrieben:
Olaf Radicke <briefkasten(a)olaf-radicke.de> wrote:
>> > Das führt zu der Ausgabe unten und reduriert die Ausführungszeit um
>> > ca 2/3 (gefällt mir). Führt aber leider nicht dazu das das RPM gefunden
>> > wird.
>> >
>> Was ist der Inhalt des Repo-Datei in /etc/yum.repos.d/ ?
> Okay, die Sache war/ist etwas kniffliger. Dein nachfrage hat mich auf die
> richtige Fährte gebracht.
> Am Anfang habe ich das Henne-Ei-Problem. Ich habe ein RPM gebaut, was die
> Repo-Conf einrichten soll. Das Problem ist nur, das dass über ein
> %post-Skript
> passiert. Es wird nämlich in Abhängigkeit von der MAC- und er IP-Adresse
> unterschiedliche REPOs eingerichtet.
> Um die MAC-Adresse herauszubekommen parse ich die Ausgabe von ifconf. Das
> ist aber äußerst Fehlerträchtig. Ursprünglich hatte ich facter dafür benutzt
> aber das ist die selbe Sch**** in grün. Cool wäre es wenn "ip" oder
"ifconf"
> die Ausgabe auch in XML oder Json könne um gescheit zu parsen.
> Na jedenfalls war das Resultat der fehlgeschlagenen RPM-Installation das
> die Repos unvollständig installiert waren.
> Wer hierzu noch eine Idee hat kann dazu gerne noch posten.
Ich würde unterschiedliche RPMs für unterschiedliche Adres-
sen erzeugen lassen (aus einem .spec) und diese dann manuell
auswählen.
Eigendeich wollte ich den Admins die Arbeit abnehmen, darüber
nach zu denken, wie sie das System dazu bringen das richtige
Yum-Repo zu verwenden. Wenn das Verfahren aber so buggi ist
das die Admins damit beschäftigt sind, was um das RPM nicht
das tut was sie erwarten, habe ich nichts gewonnen. Von daher
ist der Weg über verschiedene RPMs zu mindestens transparenter
für die Admins.
Wenn Du allerdings eh facter benutzt, warum dann nicht kom-
plett auf Puppet setzen? Nicht jede Systemeinstellung kann
man sinnvoll aus einem RPM heraus setzen.
Die Erfahrungen mit Puppet haben uns dazu gebracht auf
RPM zu setzen. Die klare Arbeitsteilung Admin,Maintainer
und Entwickler sorgt für einen klaren, strengen und
konsequenten Workflow. Puppet skaliert in unseren Fall
auch nicht befriedigend. Wenn du nur eine Kleinigkeit deployn
willst braucht du ein Clien, ein Server und ein Versionskontrollsystem.
Mit RPM sind wir schneller. Auf jeden System ist schon RPM
fertig einsatzbereit. Einfach rpm-Paket über scp rüberkopieren
und mit rpm -i installieren. Das ist die minimal Konfiguration.
Auf der anderen Seite haben Systeme die wie über Versionskonrollsystem->
Jenkins-> YUM-Repos-> befüllen. RPMs sind ins sich konsistent.
Puppet-Module müssen - wenn sie irgendwo wieder verwertet werden
sollen - genau geprüft werden, ob sie sich mit den anderen,
schon vorhandenen Modulen vertragen. Als schwierig zu debuggen
zeigte sich das Wechselspiel mit Puppet-Master/-Clent, facter,
hiera und Git-Branches. Als völlig unmöglich stellte sich
heraus, das ausrollen von PHP-Applikationen. Puppet hat sich
mit seinen Check-Summen völlig fest gefressen. Die
PHP-Applikationen haben wir als erstes mit RPMs ausgerollt.
Das ging so gut, das nach und nach alle Puppet-Module in
RPMs umgebaut wurden.
Wo es Schwierigkeiten gibt, ist wenn Konfigurationen ausgerollt
werden sollen, die eigendlich Bestandteile anderer RPMs sind.
Das machen wir jetzt mit post-Skrips. Ich habe auch schon
darüber nachgedacht, ob ich die Configs aus den RPMs heraus
patche. vsftpd ist z.B. solch ein Kandidat. Nur geht dabei
dann der Support verloren.
Gruß
Olaf