Score:-1

Can't start Mercure Hub on Debian 11 with supervisord, outh of Docker image

ca flag

I'm trying to exec Mercure hub from supervisor, but is not possible for me. Mercure is in the same machine of webserver with the SSL virtualhost for pami54.local domain.

[program:mercure]
environment=JWT_KEY="m3rcu353cr37pa55pra53DEV"; CORS_ALLOWED_ORIGINS="https://pami54.local"; PUBLISH_ALLOWED_ORIGINS="*"; ADDR="pami54.local:3000"
command=/home/frizquierdo/mercureLinux/mercure run -config /home/frizquierdo/mercureLinux/Caddyfile
process_name=%(program_name)s_$(process_num)s
numprocs=1
autostart=true
#directory=/tmp
autorestart=true
startsecs=5
startretries=10
redirect_stderr=false
stdout_capture_maxbytes=1MB
stderr_capture_maxbytes=1MB
stdout_logfile=/var/log/supervisor/mercureout.log
stderr_logfile=/var/log/supervisor/mercureerror.log

EDIT:

I´ve founded a partial solution. In the Caddyfile I desactivated caddy server on port 80, setting auto_https directive to 'disable_redirects', staying Caddyfile on this way:

# Learn how to configure the Mercure.rocks Hub on https://mercure.rocks/docs/hub/config
{
   {$GLOBAL_OPTIONS}
   auto_https disable_redirects
}

pami54.local:3000

log

tls /etc/apache2/ssl-cert/pami54.local.crt /etc/apache2/ssl-cert/pami54.local.key

route {
    encode zstd gzip

    mercure {
        # Transport to use (default to Bolt)
        transport_url {$MERCURE_TRANSPORT_URL:bolt://mercure.db}
        # Publisher JWT key
        publisher_jwt {env.MERCURE_PUBLISHER_JWT_KEY} {env.MERCURE_PUBLISHER_JWT_ALG}
        # Subscriber JWT key
        subscriber_jwt {env.MERCURE_SUBSCRIBER_JWT_KEY} {env.MERCURE_SUBSCRIBER_JWT_ALG}
        # Extra directives
        cors_origins https://pami54.local
        publish_origins *
        {$MERCURE_EXTRA_DIRECTIVES}
    }

    respond /healthz 200

    respond "Not Found" 404
}

Its virtualhost config:

<IfModule mod_ssl.c>
 #SSLStaplingCache "shmcb:${SRVROOT}/logs/ssl_stapling(32768)"
 <VirtualHost *:443>
   ServerName pami54.local
   ServerAlias wwww.pami54.local

   DocumentRoot "/var/www/html/pami54.local/public"
   DirectoryIndex index.php

   <Directory "/var/www/html/pami54.local/public/">
    AllowOverride All
    Order Allow,Deny
    Allow from All
    #Require local
    Require all granted

    <IfModule mod_rewrite.c>
            Options -MultiViews
            RewriteEngine On
            RewriteCond %{REQUEST_FILENAME} !-f
            RewriteRule ^(.*)$ index.php [QSA,L]
    </IfModule>
   </Directory>

   SSLEngine on
   SSLProtocol all -SSLv3 -SSLv2
   SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
   SSLCertificateFile "/etc/apache2/ssl-cert/pami54.local.crt"
   SSLCertificateKeyFile "/etc/apache2/ssl-cert/pami54.local.key"
   SSLUseStapling off

   <FilesMatch "\.(cgi|shtml|pl|asp|php)$">
    SSLOptions +StdEnvVars
   </FilesMatch>

   BrowserMatch ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

   SSLProxyEngine On
   ProxyRequests Off
   ProxyPreserveHost On
   #ProxyPass '/.well-known/mercure' 'https://pami54.local:3000/.well-known/mercure' connectiontimeout=300 timeout=300
   ProxyPass '/.well-known/mercure' 'https://pami54.local:3000/.well-known/mercure'
   ProxyPassReverse '/.well-known/mercure' 'https://pami54.local:3000/.well-known/mercure'
 </VirtualHost>
</IfModule>

On this way the clients can connect to Mercure on https://pami54.local/.well-known/mercure, even when a disconnection occurs the client successfully reconnects to the hub, but when server (webapp) try to publish a notification on the hub, symfony http client log error:

[2022-04-27T19:29:40.857698-04:00] http_client.INFO: Request: "POST https://pami54.local/.well-known/mercure" [] []
[2022-04-27T19:29:40.871491-04:00] messenger.WARNING: Error thrown while handling message App\Message\NotificacionMarcarComoLeidaMessage. Sending for retry #1 using 1000 ms delay. Error: "Handling "App\Message\NotificacionMarcarComoLeidaMessage" failed: Failed to send an update." {"message":{"App\\Message\\NotificacionMarcarComoLeidaMessage":[]},"class":"App\\Message\\NotificacionMarcarComoLeidaMessage","retryCount":1,"delay":1000,"error":"Handling \"App\\Message\\NotificacionMarcarComoLeidaMessage\" failed: Failed to send an update.","exception":"[object] (Symfony\\Component\\Messenger\\Exception\\HandlerFailedException(code: 0): Handling \"App\\Message\\NotificacionMarcarComoLeidaMessage\" failed: Failed to send an update. at /var/www/html/pami54.local/vendor/symfony/messenger/Middleware/HandleMessageMiddleware.php:129)\n[previous exception] [object] (Symfony\\Component\\Mercure\\Exception\\RuntimeException(code: 0): Failed to send an update. at /var/www/html/pami54.local/vendor/symfony/mercure/src/Hub.php:104)\n[previous exception] [object] (Symfony\\Component\\HttpClient\\Exception\\TransportException(code: 0): The request was not processed and can be safely retried at /var/www/html/pami54.local/vendor/symfony/http-client/Response/CommonResponseTrait.php:148)\n[previous exception] [object] (Symfony\\Component\\HttpClient\\Exception\\TransportException(code: 0): The request was not processed and can be safely retried at /var/www/html/pami54.local/vendor/symfony/http-client/Chunk/ErrorChunk.php:65)\n[previous exception] [object] (Amp\\Http\\Client\\Connection\\UnprocessedRequestException(code: 0): The request was not processed and can be safely retried at /var/www/html/pami54.local/vendor/amphp/http-client/src/Connection/DefaultConnectionFactory.php:117)\n[previous exception] [object] (Amp\\Http\\Client\\SocketException(code: 0): Connection to 'pami54.local:443' failed at /var/www/html/pami54.local/vendor/amphp/http-client/src/Connection/DefaultConnectionFactory.php:118)\n[previous exception] [object] (Amp\\Socket\\ConnectException(code: 111): Connection to tcp://pami54.local:443 refused at /var/www/html/pami54.local/vendor/amphp/socket/src/DnsConnector.php:108)"} []

What does this error mean that is throwing the symfony HTTP CLIENT component? I thought I had solved the problem. At least the clients connect an reconnect to the hub, now the problem is when the web application try to publish to the Mercure hub.

I must say that my local environmet have not an dns server, all is with local virtualhost and domains name declared in /etc/hostname.conf of Debian virtual machine:

#/etc/hostname.conf     
debiandev
pami54.local
djdomi avatar
za flag
and what is the business related question? If you're trying to access the service via a web server by the default port, then a reverse proxy would fit your needs
Francisco avatar
ca flag
@djdomi I have actualized the post with a virtual host config. The issue is with the mercure server (caddy), if I set in the Caddyfile that it must run over port 3000, why from supervisord it try to run over port 80???
djdomi avatar
za flag
what happened while you stop apache and try to start the service first? second use grep -R 80 /path/to/configdir if you maybe set by mistake port 80
Score:0
ca flag

I found partial solution. In the Caddyfile I desactivated caddy server on port 80, setting auto_https directive to 'disable_redirects', staying Caddyfile on this way:

# Learn how to configure the Mercure.rocks Hub on https://mercure.rocks/docs/hub/config
{
   {$GLOBAL_OPTIONS}
   auto_https disable_redirects
}

pami54.local:3000

log

tls /etc/apache2/ssl-cert/pami54.local.crt /etc/apache2/ssl-cert/pami54.local.key

route {
    encode zstd gzip

    mercure {
        # Transport to use (default to Bolt)
        transport_url {$MERCURE_TRANSPORT_URL:bolt://mercure.db}
        # Publisher JWT key
        publisher_jwt {env.MERCURE_PUBLISHER_JWT_KEY} {env.MERCURE_PUBLISHER_JWT_ALG}
        # Subscriber JWT key
        subscriber_jwt {env.MERCURE_SUBSCRIBER_JWT_KEY} {env.MERCURE_SUBSCRIBER_JWT_ALG}
        # Extra directives
        cors_origins https://pami54.local
        publish_origins *
        {$MERCURE_EXTRA_DIRECTIVES}
    }

    respond /healthz 200

    respond "Not Found" 404
}

Now, it´s possible for the clients to connect to the hub, but de web application can´t publish on it.

I have updated the post.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.