[RESUELTO] Instalación en Rocky Linux

[bkeller]

Buen día,

Estoy intentando instalar WAPT en una máquina virtual RockyLinux 8.5, pero tengo dificultades:

Seguí la documentación aquí
https://www.wapt.fr/en/doc/wapt-server- ... based.html
Los requisitos previos instalados son los siguientes

Código: Seleccionar todo

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

Todo va bien hasta la parte "post conf"; obtengo el siguiente mensaje de error durante la ejecución del script "postconf.py"

Código: Seleccionar todo

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

Mirando el código (setuphelpers_linux.py) vi que RockyLinux parece tener buen soporte

Código: Seleccionar todo

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

No veo dónde se especifican los requisitos técnicos para nginx y postgresql en la documentación
¿Es este un problema con la detección de distribución o con la versión de distribución?
¿Es este un problema con la versión de PostgreSQL o Nginx?
¿Es posible depurar el script "postconf.py"?

GRACIAS

[dcardón]

Hola bkeller,

¿qué versión de wapt (consulta las reglas del foro)? Esto ya se corrigió hace tiempo (error tipográfico: "rocky linux" en lugar de solo "rocky").
Necesitas una versión de PostgreSQL >= 9.6 (para compatibilidad con JSON), así que la versión predeterminada en Rocky Linux 8 está bien, no es necesario actualizarla (por el contrario, la versión 9.4 de PostgreSQL proporcionada por CentOS 7 sí necesita actualizarse). Lo mismo se aplica a nginx.

Saludos,

Denis

[bkeller]

Hola Denis,

Me perdí eso, déjame corregirlo:

Versión WAPT

Código: Seleccionar todo

[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

Versión del sistema operativo

Código: Seleccionar todo

[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)

¿Es waptserver 2.2.1.11899 la última versión?


Atentamente

[bkeller]

modificando las líneas 71 y 74 del archivo setuphelpers_linux.py de la siguiente manera

Código: Seleccionar todo

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')

¡El script postconf.py se ejecuta correctamente!

[bkeller]

Sin embargo, al final del script de configuración de nginx, hay un problema

Código: Seleccionar todo

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'

Y de hecho, estamos viendo un problema de versión del módulo nginx

Código: Seleccionar todo

[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

[dcardón]

Hola bkeller,

tu versión es correcta; yo fui quien se confundió. Por razones históricas, había dos lugares donde se definía la función `def type_redhat()`, y uno de ellos se corrigió. La refactorización está en marcha, así que debería desaparecer . Gracias por avisar; lo corregiré de inmediato.

En cuanto a nginx, es un tema aparte; depende del canal DNF seleccionado (hay varias versiones de nginx disponibles en paralelo). Pero parece que la versión 1.20 es ahora la predeterminada. Las extensiones de nginx no son compatibles entre versiones en cuanto a ABI, y el módulo Kerberos necesita recompilarse para cada versión disponible. Investigaré cómo configurar la versión a 1.20 en el archivo `.spec` y subir el módulo Kerberos correspondiente para evitar el problema. Por ahora, puedes deshabilitar la parte de Kerberos (o bajar la versión de nginx a 1.18).

Saludos cordiales,

Denis

[dcardón]

Hola de nuevo,

para que lo sepas, para degradar la versión de nginx necesitas hacer lo siguiente:

`dnf remove nginx*` # nota: esto también desinstalará el servidor wapt debido a las dependencias
`dnf module reset nginx -y` `
dnf module enable nginx:1.18 -y`
`dnf install nginx`
`dnf install tis-waptserver`

Después de eso, deberías poder activar el módulo Kerberos.

Voy a añadir a la documentación una corrección de la versión de nginx a 1.18 hasta que subamos el módulo compilado para la versión 1.20.

Saludos,

Denis

[bkeller]

Gracias por toda la información

Quería informarle que activé el módulo nginx de esta manera

Código: Seleccionar todo

dnf module enable nginx:mainline

y que esta es la version 1.21.x que está instalado

Código: Seleccionar todo

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

Sé que RH traslada los parches de seguridad a las versiones mantenidas en su repositorio, pero si podemos usar una versión actualizada...

¿Ofrecerás el paquete? nginx-mod-http-auth-spnego ¿Compatible con nginx 1.21.x?

GRACIAS
Atentamente

[dcardón]

Hola bkeller,

vamos a preparar el módulo para la versión 1.20. Sin embargo, te recomiendo encarecidamente que no configures nginx:mainline como módulo DNF, ya que con la próxima actualización del sistema operativo podrías actualizar a la versión 1.22, y entonces nginx no se reiniciará porque la ABI del módulo spnego ya no se considerará compatible.

Recuerda que nginx es bastante especial en este sentido; incluso los módulos cargados dinámicamente deben compilarse al mismo tiempo que el binario con exactamente (y me refiero a exactamente) las mismas opciones de compilación. Y esto es cierto incluso si no ha cambiado nada en la ABI...

Saludos cordiales,

Denis

[dcardón]

Hola bkeller,

Acabo de revisar la documentación y, de hecho, se menciona en [1]

Código: Seleccionar todo

dnf module enable nginx:1.18 -y

Quizás eso estaba ahí por alguna razón... Y repito, usar nginx:mainline no es recomendable si se usan módulos adicionales (como es el caso del módulo spnego). Según el sitio web de nginx[2], «Mainline es la rama de desarrollo activa», lo cual no es necesariamente la mejor opción para un servidor de producción

Si realmente desea/necesita tener la última versión de desarrollo de nginx, puede volver a compilar el módulo; el código fuente está disponible aquí [3] (pero esto no es compatible).

Atentamente,

Denis

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