[GELÖST] Installation auf Rocky Linux

[bkeller]

Guten Morgen,

Ich versuche, WAPT auf einer RockyLinux 8.5 VM zu installieren, stoße dabei aber auf Schwierigkeiten:

Ich habe mich an die Dokumentation hier gehalten
https://www.wapt.fr/en/doc/wapt-server- ... based.html
Folgende Voraussetzungen müssen erfüllt sein:

Code: Alle auswählen

nginx.x86_64         1:1.21.6-1
postgresql.x86_64         10.17-2

Alles läuft gut bis zum "post conf"-Teil; während der Ausführung des Skripts "postconf.py" erhalte ich die folgende Fehlermeldung

Code: Alle auswählen

[root@wapt ~]# /opt/wapt/waptserver/scripts/postconf.sh --force-https
not supported, exiting

Beim Blick in den Code (setuphelpers_linux.py) stellte ich fest, dass RockyLinux gut unterstützt wird

Code: Alle auswählen

def type_redhat():
	return linux_distribution is not None and linux_distribution[0].lower() in ('rhel', 'centos', 'fedora', 'oracle','almalinux','rocky linux')

Ich finde in der Dokumentation keine Angaben zu den technischen Voraussetzungen für nginx und PostgreSQL
Liegt das Problem an der Distributionserkennung oder an der Distributionsversion?
Liegt das Problem an der Version von PostgreSQL oder Nginx?
Ist es möglich, das Skript "postconf.py" zu debuggen?

DANKE

[dcardon]

Hallo bkeller,

welche Version von wapt verwendest du (siehe Forenregeln)? Das wurde bereits vor einiger Zeit korrigiert (Tippfehler: „rocky linux“ statt nur „rocky“).
Du benötigst eine PostgreSQL-Version ab 9.6 (für JSON-Unterstützung). Die Standardversion in Rocky Linux 8 ist ausreichend, ein Upgrade ist nicht nötig (im Gegensatz dazu muss die in CentOS 7 enthaltene PostgreSQL-Version 9.4 aktualisiert werden). Dasselbe gilt für nginx.

Viele Grüße,

Denis

[bkeller]

Hallo Denis,

Das habe ich übersehen, ich korrigiere es gern:

WAPT-Version

Code: Alle auswählen

[root@wapt ~]# dnf list *wapt*
Last metadata expiration check: 0:29:31 ago on Thu 05 May 2022 12:22:19 PM CEST.
Installed Packages
tis-waptserver.x86_64                   2.2.1.11899-2d82654e.el8           @wapt
tis-waptsetup.noarch                    2.2.1.11899-2d82654e               @wapt
Available Packages
tis-waptagent.x86_64                    2.2.1.11899-2d82654e.el8           wapt
tis-waptsetup-linux-mac.noarch          2.2.1.11899-2d82654e               wapt

Betriebssystemversion

Code: Alle auswählen

[root@wapt ~]# uname -a
Linux wapt.sieeen.fr 4.18.0-348.el8.0.2.x86_64 #1 SMP Sun Nov 14 00:51:12 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
[root@wapt ~]# cat /etc/*release
Rocky Linux release 8.5 (Green Obsidian)
NAME="Rocky Linux"
VERSION="8.5 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Rocky Linux 8.5 (Green Obsidian)"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:rocky:rocky:8:GA"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
ROCKY_SUPPORT_PRODUCT="Rocky Linux"
ROCKY_SUPPORT_PRODUCT_VERSION="8"
Rocky Linux release 8.5 (Green Obsidian)
Rocky Linux release 8.5 (Green Obsidian)
Rocky Linux release 8.5 (Green Obsidian)

Ist waptserver 2.2.1.11899 die neueste Version?


Aufrichtig

[bkeller]

durch Ändern der Zeilen 71 und 74 der Datei setuphelpers_linux.py wie folgt

Code: Alle auswählen

def type_redhat():
    return linux_distribution is not None and linux_distribution[0].lower() in ('rhel', 'centos', 'fedora', 'oracle','almalinux','rocky')

def type_rhel():
    return linux_distribution is not None and linux_distribution[0].lower() in ('rhel', 'centos', 'oracle','almalinux','rocky')

Das Skript postconf.py läuft korrekt!

[bkeller]

Am Ende des nginx-Konfigurationsskripts gibt es jedoch ein Problem

Code: Alle auswählen

Traceback (most recent call last):
  File "/opt/wapt/waptserver/scripts/postconf.py", line 648, in main
    print(restart_nginx())
  File "/opt/wapt/waptserver/scripts/postconf.py", line 278, in restart_nginx
    return run('systemctl restart nginx')
  File "/opt/wapt/waptutils.py", line 2123, in run
    raise CalledProcessErrorOutput(proc.returncode, cmd, ''.join(output))
waptutils.CalledProcessErrorOutput: Command b'systemctl restart nginx' returned non-z                                                           ero exit status 1.
Output:Job for nginx.service failed because the control process exited with error cod                                                           e.
See "systemctl status nginx.service" and "journalctl -xe" for details.


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/wapt/waptserver/scripts/postconf.py", line 761, in <module>
    main()
  File "/opt/wapt/waptserver/scripts/postconf.py", line 654, in main
    'errno = ' + str(cpe.returncode) + ', output: ' + cpe.output.decode('utf-8')
AttributeError: 'str' object has no attribute 'decode'

und tatsächlich ein Problem mit der Nginx-Modulversion

Code: Alle auswählen

[root@wapt ~]# nginx -t
nginx: [emerg] module "/usr/lib64/nginx/modules/ngx_http_auth_spnego_module.so" version 1018000 instead of 1021006 in /usr/share/nginx/modules/mod-http-auth-spnego.conf:1
nginx: configuration file /etc/nginx/nginx.conf test failed
[root@wapt ~]# dnf list *spnego*
Last metadata expiration check: 1:16:01 ago on Thu 05 May 2022 12:22:19 PM CEST.
Installed Packages
nginx-mod-http-auth-spnego.x86_64                                             1.18.0-tis1.1.0                                              @wapt

[dcardon]

Hallo bkeller,

deine Version stimmt; ich war derjenige, der verwirrt war. Aus historischen Gründen gab es zwei Stellen, an denen die Funktion `def type_redhat()` definiert war, und eine davon wurde korrigiert. Die Refaktorisierung läuft, daher sollte sie verschwinden . Danke für den Hinweis; ich werde das sofort beheben.

Was nginx betrifft, ist das ein separates Problem; es hängt vom gewählten DNF-Kanal ab (es sind mehrere nginx-Versionen parallel verfügbar). Es scheint aber, dass Version 1.20 jetzt die Standardversion ist. nginx-Erweiterungen sind zwischen den Versionen nicht ABI-kompatibel, und das Kerberos-Modul muss für jede verfügbare Version neu kompiliert werden. Ich werde prüfen, ob ich die Version in der `.spec`-Datei auf 1.20 setzen und das entsprechende Kerberos-Modul hochladen kann, um das Problem zu umgehen. Bis dahin kannst du den Kerberos-Teil deaktivieren (oder nginx auf Version 1.18 downgraden).

Viele Grüße,

Denis

[dcardon]

Hallo nochmal,

nur zur Info: Um die nginx-Version herabzustufen, gehen Sie wie folgt vor:

`dnf remove nginx*` # Hinweis: Dadurch wird aufgrund von Abhängigkeiten auch der wapt-Server deinstalliert.
`dnf module reset nginx -y` `
dnf module enable nginx:1.18 -y`
`dnf install nginx`
`dnf install tis-waptserver`

Danach sollten Sie das Kerberos-Modul aktivieren können.

Ich werde die Dokumentation ergänzen, um die nginx-Version auf 1.18 festzulegen, bis wir das für Version 1.20 kompilierte Modul hochladen.

Viele Grüße,

Denis

[bkeller]

Vielen Dank für die Informationen

Ich wollte Ihnen mitteilen, dass ich das nginx-Modul folgendermaßen aktiviert habe

Code: Alle auswählen

dnf module enable nginx:mainline

und dass dies die Version ist 1.21.x welches installiert ist

Code: Alle auswählen

[root@wapt ~]# nginx -v
nginx version: nginx/1.21.6

Ich weiß, dass Red Hat Sicherheitspatches in die in ihrem Repository verwalteten Versionen zurückportiert, aber wenn wir eine aktuellere Version verwenden können...

Werden Sie das Paket anbieten? nginx-mod-http-auth-spnego Kompatibel mit nginx 1.21.x?

DANKE
Aufrichtig

[dcardon]

Hallo bkeller,

wir bereiten das Modul für Version 1.20 vor. Ich rate jedoch dringend davon ab, nginx:mainline als DNF-Modul festzulegen, da Sie mit dem nächsten Betriebssystem-Upgrade möglicherweise auf Version 1.22 aktualisiert werden und nginx dann nicht mehr startet, weil die ABI des spnego-Moduls nicht mehr als kompatibel gilt.

Beachten Sie, dass nginx in dieser Hinsicht eine Besonderheit darstellt: Selbst dynamisch geladene Module müssen gleichzeitig mit der Binärdatei selbst und mit exakt denselben Compiler-Flags kompiliert werden. Dies gilt selbst dann, wenn sich an der ABI nichts geändert hat.

Mit freundlichen Grüßen,

Denis

[dcardon]

Hallo bkeller,

Ich habe gerade die Dokumentation überprüft, und es wird tatsächlich in [1] erwähnt

Code: Alle auswählen

dnf module enable nginx:1.18 -y

Vielleicht hatte das seinen Grund… Und ich wiederhole: Die Verwendung von nginx:mainline ist keine gute Praxis, wenn man Zusatzmodule nutzt (wie hier beim spnego-Modul). Laut der nginx-Website[2] ist „Mainline der aktive Entwicklungszweig“, was nicht unbedingt die beste Wahl für einen Produktivserver ist

Falls Sie unbedingt die neueste Entwicklerversion von nginx benötigen, können Sie das Modul neu kompilieren. Der Quellcode ist hier verfügbar [3] (dies wird jedoch nicht unterstützt).

Aufrichtig,

Denis

[1] https://www.wapt.fr/fr/doc/wapt-server- ... based.html
[2] https://www.nginx.com/blog/nginx-1-18-1-19-released/
[3] https://github.com/stnoonan/spnego-http ... inx-module