yum Fehler: docker-ce benötigt container-selinux >= 2.9

Kürzlich wollte ich einen RedHat-Server einrichten und habe dafür docker auf dem Server installieren wollen. Beim Versuch, docker zu installieren bekam ich folgende Fehlermeldung:

Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package docker-ce.x86_64 0:18.06.1.ce-3.el7 will be installed
--> Processing Dependency: container-selinux >= 2.9 for package: docker-ce-18.06.1.ce-3.el7.x86_64
--> Finished Dependency Resolution
Error: Package: docker-ce-18.06.1.ce-3.el7.x86_64 (docker-ce-stable)
           Requires: container-selinux >= 2.9
**********************************************************************
yum can be configured to try to resolve such errors by temporarily enabling
disabled repos and searching for missing dependencies.
To enable this functionality please set 'notify_only=0' in /etc/yum/pluginconf.d/search-disabled-repos.conf
**********************************************************************

Error: Package: docker-ce-18.06.1.ce-3.el7.x86_64 (docker-ce-stable)
           Requires: container-selinux >= 2.9
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Die Lösung hierbei war, dass ich mit Hilfe des Subscription-Managers das Repository rhel-7-server-extras-rpms aktivieren musste:

sudo subscription-manager repos --enable=rhel-7-server-extras-rpms

Danach hat die Installation von docker wunderbar funktioniert.

Version in “./docker-compose.yml” is unsupported.

Ich habe heute etwas mit Fossology gespielt. Genauer gesagt, wollte ich Fossology in Docker Containern starten und zwar mit Hilfe der Dateien, die von dem Projekt Fossology bereit gestellt werden.

Also fing ich an die entsprechenden Befehle in die Kommandozeile zu tippen:

$ git clone https://github.com/fossology/fossology.git
$ cd fossology
$ sudo docker-compose up

Beim letzten Befehl kam plötzlich eine Fehlermeldung:

ERROR: Version in "./docker-compose.yml" is unsupported. You might be seeing this error because you're using the wrong Compose file version. Either specify a version of "2" (or "2.0") and place your service definitions under the `services` key, or omit the `version` key and place your service definitions at the root of the file to use version 1.
For more on the Compose file format versions, see https://docs.docker.com/compose/compose-file

Mit Hilfe von

$ sudo docker-compose -v

docker-compose version 1.8.0, build unknown

fand ich heraus, dass die installierte docker-compose Version zu alt für die docker-compose.yml war, die in dem Fossology-Projekt lag. Also musste ich erstmal docker-compose updaten:

$ sudo curl -L https://github.com/docker/compose/releases/download/1.18.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose

Danach konnte ich Fossology ohne Probleme in Docker Containern starten.

CMake: The ASM_NASM compiler identification is unknown

Neulich bekam ich beim Versuch, unter Ubuntu ein Makefile mit Hilfe von CMake zu erstellen, diese Fehlermeldung:

— The ASM_NASM compiler identification is unknown
— Didn’t find assembler
CMake Error at simd/CMakeLists.txt:41 (enable_language):
No CMAKE_ASM_NASM_COMPILER could be found.

Tell CMake where to find the compiler by setting either the environment
variable “ASM_NASM” or the CMake cache entry CMAKE_ASM_NASM_COMPILER to the
full path to the compiler, or to the compiler name if it is in the PATH.

— Configuring incomplete, errors occurred!

Die Lösung hier war, das Paket nasm zu installieren:

sudo apt install nasm

CMake und VS2017: could not find any instance of Visual Studio.

Vor kurzem bekam ich beim Versuch, ein Visual Studio 2017-Projekt mit CMake zu generieren, diese Fehlermeldung:

CMake Error at CMakeLists.txt:3 (project):
Generator

Visual Studio 15 2017 Win64

could not find any instance of Visual Studio.

— Configuring incomplete, errors occurred!

Die Fehlermeldung hat mich gewundert, da Visual Studio 2017 doch installiert war. Die Lösung bei mir war, dass ich noch die Komponente Visual C++ tools for CMake and Linux habe installieren müssen:

Jenkins master – Zu wenig Speicherplatz

Mit der Zeit kann es vorkommen, dass der frei verfügbare Speicherplatz auf dem Server auf dem Jenkins läuft, immer kleiner wird. Das kann unter Anderem auch an Jenkins selbst liegen.

In diesem Post möchte ich ein paar Hilfestellungen geben, wie man dieses Problem lösen und auch vorbeugen kann. Ich werde in diesem Post von meiner Jenkins Installation ausgehen, die auf einem Ubuntu-Server installiert ist. Auf anderen Linux- oder Windows-Servern muss man die vorgestellten Strategien jedoch anpassen.

Speicherhungrige Jobs finden

Auf meinem Ubuntu-Server ist Jenkins unter dem Pfad /var/lib/jenkins installiert. Unter diesem Ordner gibt es einen Ordner namens jobs, in dem es wiederum weitere Ordner gibt. Jeder dieser Ordner ist nach dem jeweiligen Job in Jenkins benannt. Wenn man also einen Job namens First Job hat, dann findet man unter jobs einen Ordner, der auch First Job heißt.

Mit dem Kommandos

cd /var/lib/jenkins/jobs

du -h –max-depth=1 | sort -hr

bekommt man nun eine Auflistung aller Ordner in jobs und die Größe aller Dateien zusammen vom jeweiligen Ordner.

Auf diese Weise kann man erkennen, welche Jobs den meisten Speicherplatz belegen. In meinem Fall ist das jedoch noch kein Problem. Will man jedoch für mehr Speicherplatz sorgen gib, kann es helfen, die Anzahl der Builds zu limitieren.

Anzahl der Builds limitieren

Standardmäßig speichert Jenkins jeden Build ab, den ein Job je ausgeführt hat. Insbesondere auch dann, wenn man anfängt, Artefakte zu archivieren (eine Post-build Aktion), kann der verfügbare Speicherplatz je nach Projekt sehr schnell klein werden. Wenn man aber die Anzahl der Builds limitiert, werden alte Builds von Jenkins automatisch gelöscht und es wird regelmäßig Speicherplatz wieder frei gelegt.

Um die Anzahl der Builds zu limitieren, muss man in einer Job-Konfiguration unter General einen Haken vor Discard old builds setzen und je nach belieben Werte einsetzen:

Anschließend das Speichern nicht vergessen 😉

Ein Jenkins Plugin installieren

Erst durch die vielen Plugins wird Jenkins zu dem was es ist: Ein sehr mächtiges Werkzeug. Doch wie installiert man ein Plugin in Jenkins? In diesem Post will ich aufzeigen, wie man in Jenkins Plugins installieren kann.

Manage Plugins

Der übliche Weg geht über den Link Manage Jenkins.

Wenn man auf den Link Manage Jenkins klickt, taucht eine neue Seite mit einer Reihe von Buttons. Einer davon hat den Titel Manage Plugins.

Wenn man auf diesen Knopf drückt, kommt man auf die Seite, auf der man Plugin installieren kann.

Auf dieser Seite muss man in den Reiter Available wechseln. Dort wird eine Reihe von installierbaren Plugins aufgelistet. Jetzt muss man dort nach dem gewünschten Plugin suchen. Dabei kann man das Suchfeld rechts oben zur Hilfe nehmen.

Hat man das gewünschte Plugin gefunden, setzt man einen Haken links neben dem Namen des Plugins. In meinem Beispiel will ich jetzt das Plugin Pipeline installieren.

Im Browser unten müsste sich jetzt ein Knopf namens Download now and install after restart befinden. Diesen muss man drücken. Anschließend startet man Jenkins neu.

 

Jobs triggern Jobs in Jenkins – Parameterized Plugin

Neben den Boardmitteln von Jenkins, weitere Jobs zu triggern, gibt es einige Plugins, die dasselbe erledigen und dabei mehr Einstellungen anbieten können. In diesem Post geht es um das Plugin namens Parameterized Plugin. Dieses Plugin erlaubt es, in einem Job oder am Ende eines Jobs weitere Jobs zu starten und dazu noch Parameter zu übergeben. Ich nehme jetzt an, dass der Leser/die Leserin das Plugin Parameterized Plugin schon installiert hat.

Job vor Job starten

Es gibt Fälle, da möchte man einen Job laufen lassen, bevor der eigentliche Job gestartet wird. Mit dem Parameterized Plugin  geht das folgendermaßen: In der Konfiguration des eigentlichen Jobs geht man in die Build-Sektion und fügt dort einen neuen Build-Schritt hinzu: Trigger/call builds on other projects.

Nun müsste ein neuer Build-Schritt erscheinen. Diesen muss man eventuell nach oben schieben, je nachdem, wie man es haben möchte und entsprechend konfigurieren (siehe nächstes Bild). Second Job ist in dem Fall ein zweiter Job, den ich in diesem Beispiel starten möchte, bevor der eigentliche Build-Prozess von dem aktuellen Job gestartet wird.

Nun kann man weiter unten auf Save drücken und es einfach mal ausprobieren. Dabei muss man darauf achten, dass die entsprechenden Knoten (master / slaves) genügend Slots haben. Ansonsten könnte es passieren, dass ein Job einen anderen blockiert.

Job nach Job starten

Genauso wie man einen Job vor einem Job starten kann (siehe das Unterkapitel weiter oben), kann man auch einen Job nach einem anderen Job starten. In diesem Fall fügt man in der Liste der Post-build-Aktionen eine weitere Aktion hinzu: Trigger parameterized build on other projects.

Nun müsste ein neuer Bereich in den Post-build-Aktionen aufgetaucht sein. Diesen gilt es nun anzupassen und dann mit einem Klick auf Save zu speichern.

Jobs triggern Jobs in Jenkins

In diesem Post möchte ich euch zeigen, wie man einen zweiten Job startet, wenn der erste fertig ist. Das lässt sich mit den Boardmitteln von Jenkins recht einfach realisieren. Dazu muss man in den Post-build actions den Punkt Build other projects auswählen und dann den Namen des anderen Jobs eintragen.

In diesem Fall habe ich zu Testzwecken einen zweiten Job namens Second Job erstellt, der gestartet wird, wenn der erste erfolgreich fertig geworden ist.

Wie man in dem obigen Bild sieht, kann man einstellen, wann der zweite Job Second Job gestartet werden soll. Dies kann geschehen, wenn der erste Job erfolgreich war (Trigger only if build is stable), oder wenn das Ergebnis vom ersten Job instabil ist (Trigger even if the build is unstable) oder auch dann, wenn der erste Job fehlgeschlagen ist (Trigger even if the build fails). Ich habe das jetzt einfach mal auf Trigger only if build is stable eingestellt.

Ist alles eingerichtet, sieht man das auch später in der Liste der Downstream Projects:

Nun kann man einen Testlauf durchführen und den ersten Job starten. Nach dem Ende des ersten Jobs sollte automatisch der zweite gestartet werden (je nachdem, wie das Ergebnis des ersten Jobs ist und welche Einstellung man gewählt hat).

InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

Meine Ausgangssituation war folgende: Ich hatte eine Ubuntu 18.04 Maschine mit Jenkins darauf. Jenkins war frisch installiert. Nun wollte ich neue Plugins installieren, also bin ich auf die Seite des Plugin-Managers gegangen. Dort habe ich auf den Button Check now geklickt und prompt kam dann diese Fehlermeldung:

java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
at java.security.cert.PKIXParameters.(PKIXParameters.java:120)
at java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:104)
at sun.security.validator.PKIXValidator.(PKIXValidator.java:89)
Caused: java.lang.RuntimeException: Unexpected error
at sun.security.validator.PKIXValidator.(PKIXValidator.java:91)
at sun.security.validator.Validator.getInstance(Validator.java:179)
at sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:312)
…

Wie ich herausgefunden habe, war das Problem, dass unter Ubuntu 18.04 und Debian, die cacerts-Datei für Java 9, 10 und 11 das Format pkcs12 benutzt. Frühere Java Versionen haben aber die Version jks benutzt. Das pkcs12-Format verlangt aber ein Passwort, was standardmäßig changeit lautet. Bei mir musste ich nun folgendes machen:
In der /etc/default/jenkins nach der Zeile suchen, die mit JAVA_ARGS anfängt.
Dort dann einfach -Djavax.net.ssl.trustStorePassword=changeit hinzufügen. Bei mir sieht das dann so aus:

JAVA_ARGS=”-Djava.awt.headless=true -Djavax.net.ssl.trustStorePassword=changeit”

Und dann Jenkins neustarten: sudo systemctl restart jenkins

Wenn man nichts falsch gemacht hat, sollte man nun im Plugin-Manager auf Check now klicken können ohne das diese Fehlermeldung nochmals auftaucht.

Quellen: