viernes, 12 de junio de 2020

Estaba funcionando en su momento -antes del confinamiento y el ERTE- pero parece ser que lo dejé en pruebas por el paso a usar docker-compose y como resultado tenía seis instancias del mismo programa compitiendo entre sí por el acceso a los puertos.

En realidad no he llegado a captar del todo el problema porque sigue siendo confuso el registro de eventos de los contenedores y las aplicaciones Java, pero he llegado a la conclusión de que si veían que no podían escuchar un puerto en IPv4 lo hacía tranquilamente en IPv6 por lo que el servidor Apache que estaba haciendo de proxy no conseguía ninguna conexión. Lo mismo estaba todo marchando menos el frontal.

He eliminado todos los contenedores que estaban funcionando y una vez que he tenido una lista limpia he arrancado el servicio con docker-compose y ha ido como un tiro.

Como un tiro si tu navegador incluye probar conexiones seguras en las web como la combinación de Firefox y HTTPS Everywhere. En caso contrario se estrella con la versión vacía de la web.

La configuración del servicio virtual en este caso parece ser idéntica a las de las otras web que tengo en el interior pero algo se me está escapando:

<VirtualHost *:80>
    ServerName          consolas.venexma.net
    ServerAdmin         root@venexma.net

        Include conf.d/redirect-ssl.conf

</VirtualHost>

<VirtualHost *:443>
    ServerName          consolas.venexma.net
    ServerAdmin         root@venexma.es
 
    # Incluímos conexiones seguras
    SSLEngine   On
        SSLProxyEngine On

        LogLevel        info
        ErrorLog        /var/log/apache2/consolas.venexma.net/error.log
        CustomLog       /var/log/apache2/consolas.venexma.net/access.log Combined

    Include conf.d/certificates.conf

        <Location />
                Require all granted

                ProxyPass http://192.168.100.1:8080/guacamole/ flushpackets=on
                ProxyPassReverse http://192.168.100.1:8080/guacamole/
                ProxyPassReverseCookiePath /guacamole/ /
        </Location>

        <Location /guacamole/websocket-tunnel>
                Require all granted
                ProxyPass ws://192.168.100.1:8080/guacamole/websocket-tunnel
                ProxyPassReverse ws://192.168.100.1:8080/guacamole/websocket-tunnel
        </Location>
</VirtualHost>

Y la parte que redirecciona es también la que emplean los otros:

# Redirección a versión segura exceptuando servicios conocidos
RewriteEngine on

Alias /letsencrypt      /var/www/letsencrypt
RewriteCond %{REQUEST_URI} ^/.well-known/acme-challenge/
RewriteRule . /letsencrypt%{REQUEST_URI} [PT] [L]

RewriteCond %{HTTPS} !^on$ [NC]
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI}  [L]

Se incluyen las excepciones para el desafío HTTP de certbot y los certificados digitales. Algo que espero que la semana que viene me sobre por fin.

El caso es que cuando mi superusuario PowerUser entra por fin en su consola con su navegador se encuentra con lo siguiente:

Por lo que me ahorro instalarle en Windows un programa para conectar vía SSH a la máquina antigua, y emular un terminal VT220 o similar, al mismo tiempo que puede gestionar lo que hace su compañera (aún en el ERTE) sin volverse loco de una mesa a la otra.