BOSH http_bind with metronome and nginx for nextcloud xmpp client

Hi all,

My YunoHost server

Hardware: Raspberry Pi 2B 1024MB RAM
YunoHost version: 3.6.4.6 (stable)
I have access to my server : Through SSH, through the webadmin and direct access via serial ttyUSB
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

Description of my issue

I am tryning to use the XMPP client in nextcloud with metronome. I struggle to get BOSH running.

bjarkan wrote an howto, I especially paid attention to the last post with the better but dirtier solution.

So, my actions were:

  • Install custom webapp at sub.doma.in/chat
  • wget converse.im index page to /var/www/my_webapp/www
  • edit /etc/metronome/conf.d/sub.doma.in.cfg.lua (add location /chat/http_bind)
  • edit /etc/metronome/metronome.cfg.lua (uncomment bosh)
  • edit /etc/nginx/conf.d/sub.doma.in.d/my_webapp.conf (point to localhost:5290)
  • edit /var/www/my_webapp/www/index.html to point bosh at sub.doma.in/chat/http_bind

After service restart metronome/nginx, I get a gateway error at sub.doma.in/chat/http_bind.

  • When using telnet at localhost to port 5290, I get no reply.
  • When using telnet at localhost to port 5280, I do get in, but I do not know who is answering there.

When I change the configuration (nginx for my_webapp and metronome’s sub.doma.in.cfg.lua) to use port 5280 instead of 5290, my browser shows ‘file not found’.

With that port (5280), nginx’s access.log says: “GET /chat/http-bind HTTP/2.0” 404 922 “-” , error.log says:
[error] 29046#29046: *1 connect() failed (111: Connection refused) while connecting to upstream, client: (my IPv6), server: sub.doma.in, request: “GET /chat/http-bind HTTP/2.0”, upstream: “http://[::1]:5280/http-bind”, host: “sub.doma.in”

When I change it back to port 5290, the nginx-logs reflect the change:
access.log: “GET /chat/http-bind HTTP/2.0” 502 907 “-”
error.log: [error] 29478#29478: *1 connect() failed (111: Connection refused) while connecting to upstream, client: (my IPv6), server: sub.doma.in, request: “GET /chat/http-bind HTTP/2.0”, upstream: “http://[::1]:5290/http-bind”, host: “sub.doma.in”

Metronome does not have any entry when hitting https://sub.doma.in/chat/http-bind

There is one point in bjarkan’s howto that does not match my experience. In my metronome.conf.lua, there are no http-related settings. No http plugin to enable, no http ports or interfaces to check/change. I did add them:
http_ports = { 5280 }
http_interfaces = { "127.0.0.1", "::1" }
but that did not change the symptoms. There is a disabled virtual host, and there is a virtual host in the conf.d-directory that I did modify.

I only downloaded the index.html from converse.js; I don’t need converse.js, because I got nextcloud jabber, I only need http-bind.

Any idea where I went wrong?

Tip: if you want to check what ports metronome is listening on use this command:

netstat -lptn | grep lua

Then you should try to debug bosh without involving nginx. For example, if you set http_ports = { 5280 } in metronome.conf.lua then your bosh endpoint should respond here:

curl -i http://localhost:5280/http-bind/

Thanks, that shows metronome is indeed listening (and providing BOSH) at port 5280:

# netstat -lptn | grep lua                                                                                                        
tcp        0      0 0.0.0.0:5222            0.0.0.0:*               LISTEN      29461/lua5.1                                                   
tcp        0      0 0.0.0.0:5269            0.0.0.0:*               LISTEN      29461/lua5.1                                                   
tcp        0      0 0.0.0.0:5280            0.0.0.0:*               LISTEN      29461/lua5.1                                                   
# curl -i http://localhost:5280/http-bind                                                                                         
HTTP/1.1 200 OK                                                                                                                                
Connection: Keep-Alive                                                                                                                         
Content-Type: text/html; charset=utf-8                                                                                                         
Date: Fri, 27 Sep 2019 09:23:59 GMT                                                                                                            
Content-Length: 187                                                                                                                            
Server: Metronome/3.11.8 (net.http.server; https://metronome.im)                                                                               
                                                                                                                                               
<!DOCTYPE html><html><head><title>Metronome's BOSH Interface</title></head><body>                                                              
                <p>It works! Now point your BOSH client to this URL to connect to the XMPP Server.</p>                                         
                </body></html>
#                        

That is a good starting point. I see that it is listening at localhost:5280/http-bind, not localhost:5280/chat/http-bind.

I’ll change that in the nginx-config, and let it know if it solved my problem.

Thanks!

Actually, I misremembered that; it already points to the right URL;
/etc/nginx/conf.d/online.osba.nl.d/my_webapp.conf:

 location /chat/ {
 ...
  location = /chat/http-bind {
    proxy_pass http://localhost:5280/http-bind;
    proxy_redirect off;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $server_name;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection “upgrade”;
 }
}

/etc/metronome/conf.d/sub.doma.in.cfg.lua:

VirtualHost "sub.doma.in"
  http_interfaces = { "127.0.0.1", "::1" }
  http_ports = { 5280 }
  ssl = {
        key = "/etc/yunohost/certs/sub.doma.in/key.pem";
        certificate = "/etc/yunohost/certs/sub.doma.in/crt.pem";
  }
  authentication = "ldap2"
  ldap = {
     hostname      = "localhost",
     user = {
       basedn        = "ou=users,dc=yunohost,dc=org",
       filter        = "(&(objectClass=posixAccount)    (mail=*@sub.doma.in))",
       usernamefield = "mail",
       namefield     = "cn",
       },
  }

So, am I right to understand that:

  • Metronome is OK; BOSH is being served at localhost:5280/http-bind;
  • Localhost:5280/http-bind is accessible locally
  • Nginx is supposed to proxy external address https://sub.doma.in/chat/http-bind to localhost:5280/http-bind
  • Nginx can not access localhost:5280/http-bind, because there is an error in my configuration;

The last point: how can I check whether another rewrite is in place, that rewrites between /chat/http-bind and :5280/http-bind ? (Edit: Yes, there is, to the admin-interface.)

I ran some curl’s, and found that there is a redirect to the admin-login (curl -Lik, foLlow redirects, insekure):

# curl -i http://localhost:5280/http-bind/
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
Date: Fri, 27 Sep 2019 16:03:17 GMT
Content-Length: 187
Server: Metronome/3.11.8 (net.http.server; https://metronome.im)

<!DOCTYPE html><html><head><title>Metronome's BOSH Interface</title></head><body>
                <p>It works! Now point your BOSH client to this URL to connect to the XMPP Server.</p>
                </body></html>root@online:~#


# curl -i http://localhost/chat/http-bind/
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 27 Sep 2019 16:03:28 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Location: https://localhost/yunohost/admin

<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

# curl -i http://sub.doma.in/chat/http-bind/
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Fri, 27 Sep 2019 16:03:56 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Location: https://sub.doma.in/chat/http-bind/

<html>
<head><title>301 Moved Permanently</title><script type="text/javascript" src="/ynh_portal.js"></script><link type="text/css" rel="stylesheet" href="/ynh_overlay.css"></link><script type="text/javascript" src="/ynhtheme/custom_portal.js"></script><link type="text/css" rel="stylesheet" href="/ynhtheme/custom_overlay.css"></link></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
#

curl -Lik http://localhost/chat/http-bind/  
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 27 Sep 2019 16:09:48 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Location: https://localhost/yunohost/admin

HTTP/2 301 
server: nginx
date: Fri, 27 Sep 2019 16:09:49 GMT
content-type: text/html
content-length: 178
location: https://localhost/yunohost/admin/
strict-transport-security: max-age=63072000; includeSubDomains; preload
referrer-policy: 'same-origin'
content-security-policy: upgrade-insecure-requests; object-src 'none'; script-src https: 'unsafe-eval'
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-frame-options: SAMEORIGIN

HTTP/2 200 
server: nginx
date: Fri, 27 Sep 2019 16:09:49 GMT
content-type: text/html
content-length: 3506
last-modified: Tue, 17 Sep 2019 22:02:13 GMT
etag: "5d8157e5-db2"
strict-transport-security: max-age=63072000; includeSubDomains; preload
referrer-policy: 'same-origin'
content-security-policy: upgrade-insecure-requests; object-src 'none'; script-src https: 'unsafe-eval'
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-frame-options: SAMEORIGIN
accept-ranges: bytes

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>YunoHost admin</title>
    <meta http-equiv="cache-control" content="no-cache" />
    <meta name="format-detection" content="telephone=no" />
    <meta name="viewport" content="user-scalable=no, width=device-width, height=device-height" />
    <meta name="robots" content="noindex, nofollow">
    <link rel="stylesheet" media="screen" href="dist/css/style.min.css?version=ef5c380d">
    <link rel="shortcut icon" href="dist/img/ynhadmin_icon.png">
    <script type="text/javascript" src="dist/js/script.min.js?version=ef5c380d"></script>
</head>
<body>

    <div id="slider" role="application">

        <header id="masthead" class="page-header">
            <a href="#/" class="homelink slide back">
                <img alt="accueil Yunohost" src="dist/img/icon.png" style="width: 70px;">
            </a>
            <span class="buttons">
                <a role="button" class="user-interface-btn" href="/yunohost/sso/" title="Logout" data-y18n-title="user_interface_link">
                    <span data-y18n="user_interface_link">User interface</span>&nbsp;
                    <i class="fa-user"></i>
                </a>
                <a role="button" class="logout-btn" href="#/logout" title="Logout" data-y18n-title="logout">
                    <span data-y18n="logout">Logout</span>&nbsp;
                    <i class="fa-sign-out"></i>
                </a>
            </span>
        </header>

        <div id="flashMessage">
            <button id="toggle-btn" data-y18n-title="pin">
                <span class="sr-only">Pin&nbsp;</span><span class="fa-thumb-tack"></span>
            </button>
            <button id="clear-btn" data-y18n-title="clear">
                <span class="sr-only">Clear&nbsp;</span><span class="fa-trash-o"></span>
            </button>
            <div class="messages"></div>
        </div>

        <div id="slider-container">

            <div id="slideBack" style="display: none;"></div>

            <div id="main" role="main">
                <a class="slide" href="#/">
                    <span class="ajax-loader" data-y18n="loading">loading…</span>
                </a>
                <noscript>
                    <div class="alert alert-warning">
                        <p> <strong> Warning ! </strong> You must enable Javascript to view this page properly. </p>
                    </div>
                </noscript>
            </div>

            <div id="slideTo" style="display: none; z-index: 100;"></div>

        </div><!--/#slider-container-->

        <footer class="page-footer">
            <p id="yunohost-version"></p>
        </footer>
    </div>

    <div id="modal" tabindex="-1" role="dialog" aria-labelledby="modalLabel" aria-hidden="true">
        <div><div>
            <header>
                <button type="button" class="close" data-dismiss="modal">
                    <span aria-hidden="true">&times;</span>
                    <span class="sr-only" data-y18n="close">Close</span>
                </button>
                <h4 class="title" id="modalLabel"></h4>
            </header>
            <div class="content"></div>
            <footer>
                <button type="button" id="modal-cancel" data-action="cancel" data-y18n="cancel">Cancel</button>
                <button type="button" id="modal-confirm" data-action="confirm" data-y18n="ok">OK</button>
            </footer>
        </div></div>
    </div>

</body>
</html>
#

I am not quite sure how to proceed from here. In what order should I place the rewrites? How to check?

You forgot this interesting test:

curl -i https://sub.doma.in/chat/http-bind/

You should see the same output as with the test you did earlier:

curl -i http://localhost:5280/http-bind/

Thanks for staying interested :slight_smile:

I thought it was there, but I tested the non secure version:

# curl -i http://sub.doma.in/chat/http-bind/
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Fri, 27 Sep 2019 16:03:56 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Location: https://sub.doma.in/chat/http-bind/

<html>
<head><title>301 Moved Permanently</title><script type="text/javascript" src="/ynh_portal.js"></script><link type="text/css" rel="stylesheet" href="/ynh_overlay.css"></link><script type="text/javascript" src="/ynhtheme/custom_portal.js"></script><link type="text/css" rel="stylesheet" href="/ynhtheme/custom_overlay.css"></link></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
#

Visiting the secure location, I get a certificate error:

    # curl -i https://localhost/chat/http-bind/
    curl: (60) SSL certificate problem: unable to get local issuer certificate
    More details here: https://curl.haxx.se/docs/sslcerts.html

    curl performs SSL certificate verification by default, using a "bundle"
     of Certificate Authority (CA) public keys (CA certs). If the default
     bundle file isn't adequate, you can specify an alternate file
     using the --cacert option.
    If this HTTPS server uses a certificate signed by a CA represented in
     the bundle, the certificate verification probably failed due to a
     problem with the certificate (it might be expired, or the name might
     not match the domain name in the URL).
    If you'd like to turn off curl's verification of the certificate, use
     the -k (or --insecure) option.
    # curl -ik https://localhost/chat/http-bind/
    HTTP/2 302
    server: nginx
    date: Fri, 27 Sep 2019 21:16:19 GMT
    content-type: text/html
    content-length: 154
    location: https://localhost/yunohost/admin
    strict-transport-security: max-age=63072000; includeSubDomains; preload
    referrer-policy: 'same-origin'
    content-security-policy: upgrade-insecure-requests; object-src 'none'; script-src https: 'unsafe-eval'
    x-content-type-options: nosniff
    x-xss-protection: 1; mode=block
    x-download-options: noopen
    x-permitted-cross-domain-policies: none
    x-frame-options: SAMEORIGIN

    <html>
    <head><title>302 Found</title></head>
    <body bgcolor="white">
    <center><h1>302 Found</h1></center>
    <hr><center>nginx</center>
    </body>
    </html>

After that I wondered what it was 301’d to, with

# curl -Li http://sub.doma.in/chat/http-bind/

That gave me a certificate error, which I surpressed with -k. That gave the larger HTML-output, which looks like the ynh admin-interface.

Just visiting the URL (https://online.osba.nl/chat/http-bind , by the way) in a browser gives a bad gateway.

The curl-result gives me to think that rewriting is done when it should not. Should I look in the my_webapp.conf (is it self contained), or should I also look in the other nginx-conf-files? All (about 5) apps have just the standard install, only for nextcloud I tried to get social stuff working which involved rewrites. I don’t master the configuration well enough to see whether there is/can be a conflict.

I am also not sure whether the certificate error is serious, because nginx is configured to use the non secure location internally (though, I just realize, that could become forwarded to the secure location).

(edits: misunderstanding and formatting)

Beware that when testing URLs handled by nginx you have to avoid localhost.
Nginx is aware of the hostname requested and gives a response from the corresponding virtual host config. Querying localhost will match no particular virtual host and will redirect to the yunohost admin page.

I guess you have defined a virtualhost with servername sub.doma.in somewhere in your nginx config, so try this instead:

curl -ik https://sub.doma.in/chat/http-bind/

Look at the log files in /var/log/nginx/xxxxx.error.log, you may have useful information explaining the * 502 Bad Gateway* error.

Indeed, quite so! The connection is made to the loopback interface at port 5290, instead of 5280, and there the connection is refused:

2019/09/27 22:51:44 [error] 29479#29479: *10598 connect() failed (111: Connection refused) while connecting to upstream, client: (my IPv6), server: online.osba.nl, request: "GET /chat/http-bind HTTP/2.0", upstream: "http://[::1]:5290/http-bind", host: "online.osba.nl"
2019/09/27 22:51:44 [error] 29479#29479: *10598 connect() failed (111: Connection refused) while connecting to upstream, client: (my IPv6), server: online.osba.nl, request: "GET /chat/http-bind HTTP/2.0", upstream: "http://127.0.0.1:5290/http-bind", host: "online.osba.nl"

I might not have reloaded/restarted nginx before, because the config is pointing at 5280; after restarting nginx to be sure, this is the result:

2019/09/27 22:58:32 [error] 22206#22206: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 2001:982:1768:1:225:90ff:fe37:b6f8, server: online.osba.nl, request: "GET /chat/http-bind HTTP/2.0", upstream: "http://[::1]:5280/http-bind", host: "online.osba.nl"

One peculiar thing is that this only gives one line of error, for IPv6, while port 5290 gives two lines.

Curl can find the user sign on page this way:

# curl -Li http://online.osba.nl/chat/http-bind/ 
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Fri, 27 Sep 2019 23:05:29 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Location: https://online.osba.nl/chat/http-bind/

HTTP/2 302 
server: nginx
date: Fri, 27 Sep 2019 23:05:30 GMT
content-type: text/html
content-length: 154
location: https://online.osba.nl/yunohost/sso/?r=aHR0cHM6Ly9vbmxpbmUub3NiYS5ubGluZGV4LnBocA==
x-sso-wat: You've just been SSOed
set-cookie: SSOwAuthRedirect=;; Path=/yunohost/sso/; Expires=Thu, 01 Jan 1970 00:00:00 UTC; Secure; HttpOnly; SameSite=Lax ;;
strict-transport-security: max-age=63072000; includeSubDomains; preload
content-security-policy: upgrade-insecure-requests
content-security-policy-report-only: default-src https: data: 'unsafe-inline' 'unsafe-eval'
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-frame-options: SAMEORIGIN

HTTP/2 200 
server: nginx
date: Fri, 27 Sep 2019 23:05:30 GMT
content-type: text/html
x-sso-wat: You've just been SSOed

Nginx’s acces.log shows about the same:

fe80::5080:1faf:2160:a5c5 - - [27/Sep/2019:23:10:27 +0000] "GET /chat/http-bind/ HTTP/1.1" 301 476 "-" "curl/7.52.1"
fe80::5080:1faf:2160:a5c5 - - [27/Sep/2019:23:10:27 +0000] "GET /chat/http-bind/ HTTP/2.0" 302 679 "-" "curl/7.52.1"
fe80::5080:1faf:2160:a5c5 - - [27/Sep/2019:23:10:27 +0000] "GET /yunohost/sso/?r=aHR0cHM6Ly9vbmxpbmUub3NiYS5ubGluZGV4LnBocA== HTTP/2.0" 200 3392 "-" "curl/7.52.1"

The portal catches all traffic before it has a chance to arrive at the destination it should arrive.
Any idea why curl arrives at the SSO-page, while Firefox gets a 404?
Is there a smart way to figure out which rewrite is responsible for each redirect?

Sorry for quoting myself :slight_smile: I found I can add rewrite-logging to the error log, at notice level:
/etc/nginx/nginx.conf

http {
        ...
        ##
        # Logging Settings
        ##
        ###wbk 20190928, debug rewrites voor online.osba.nl/chat/http-bind
        rewrite_log on;
        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log notice;
}

I have reloaded nginx, and restarted it as well. The error log does not show anything more when using curl. Should I add the rewrite_log on to another config file, the config specific for the domain that I want to troubleshoot?

It seems that nginx tries to reach metronome with IPv6 while nginx only listens on ipv4 addresses.

Try this change in nginx config:
Replace

proxy_pass http://localhost:5280/http-bind;

with

proxy_pass http://127.0.0.1:5280/http-bind;

I think the rewrite for nextcloud social / webfinger is catching all. The nginx online.osba.nl-error.log does not get any new entries when I try to reach online.osba.nl/chat/http-bind, but access.log does get an extra entry (404).

The 404 I get with curl is not standard:

root@online:~# curl -Li http://online.osba.nl/chat/http-bind
HTTP/1.1 404 Not Found                                                                                                                                                                                                                                                                                                                
Server: nginx                                                                                                                                                                                                                                                                                                                         
Date: Sat, 28 Sep 2019 11:31:23 GMT                                                                                                                                                                                                                                                                                                   
Content-Type: application/octet-stream                                                                                                                                                                                                                                                                                                
Content-Length: 460                                                                                                                                                                                                                                                                                                                   
Connection: keep-alive                                                                                                                                                                                                                                                                                                                
X-SSO-WAT: You've just been SSOed                                                                                                                                                                                                                                                                                                     
Set-Cookie: SSOwAuthRedirect=;; Path=/yunohost/sso/; Expires=Thu, 01 Jan 1970 00:00:00 UTC; Secure; HttpOnly; SameSite=Lax ;;                                                                                                                                                                                                         
                                                                                                                                                                                                                                                                                                                                      
<!DOCTYPE html>                                                                                                                                                                                                                                                                                                                       
<html>                                                                                                                                                                                                                                                                                                                                
<head><link rel="icon" type="image/png" href="/assets/favicon.png" /><meta charset="utf-8"><style>body{margin-top:14%;text-align:center;background-color:#F8F8F8;font-family:sans-serif;}h1{font-size:xx-large;}p{font-size:x-large;}p+p { font-size: large; font-family: courier }</style>                                           
</head>                                                                                                                                                                                                                                                                                                                               
<body><h1>404 Not Found</h1><p>Whatever you were looking for is not here. It's behind you.</p><p>Unknown host: online.osba.nl</p>                                                                                                                                                                                                     
</body>                                                                                                                                                                                                                                                                                                                               
</html>

When I try to reach the domain at this port, there is a get in the nextcloud-directory in the access.log, via IPv4!

curl -Li http://online.osba.nl:5280
HTTP/1.1 404 Not Found
Date: Sat, 28 Sep 2019 11:34:56 GMT
Content-Length: 460
Connection: Keep-Alive
Server: Metronome/3.11.8 (net.http.server; https://metronome.im)

<!DOCTYPE html>
<html>
<head><link rel="icon" type="image/png" href="/assets/favicon.png" /><meta charset="utf-8"><style>body{margin-top:14%;text-align:center;background-color:#F8F8F8;font-family:sans-serif;}h1{font-size:xx-large;}p{font-size:x-large;}p+p { font-size: large; font-family: courier }</style>
</head>
<body><h1>404 Not Found</h1><p>Whatever you were looking for is not here. It's behind you.</p><p>Unknown host: online.osba.nl</p>
</body>
</html>

# tail -f /var/log/nginx/online.osba.nl-access.log
fe80::5080:1faf:2160:a5c5 - - [28/Sep/2019:11:32:52 +0000] "GET /chat/http-bind HTTP/1.1" 404 460 "-" "curl/7.52.1"
192.168.168.52 - linh [28/Sep/2019:11:33:15 +0000] "GET /nextcloud/index.php/204 HTTP/1.1" 204 0 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.7.1"

Do you know enough about nginx to tell whether my config (above, post 10) should catch the rewrites to the error log?

I will be out of the door until the evening, and hope to continue then.

At last I found the right log definition line to add ‘notice’ in order to receive rewrites in the log, not in the general /etc/nginx/nginx.conf, but in the specific configuration for that particular virtual host; then there are still two error-log-definitions, one for the server listening on port 80 and one for the server listening on port 443.

The access is on port 443, so the ‘notice’ directive needs to go there. It fills the log rapidly with rewrites from all traffic, so there is the reason it is not a nginx-wide setting, but per-virtual host.

Now, when browsing to https://sub.doma.in/chat/http-bind, there are entries for all installed applications, telling (and surprising) me none of them match this location:

tail -f /var/log/nginx/online.osba.nl-error.log

2019/09/28 22:16:37 [notice] 3965#3965: *7 "^/chat$" does not match "/chat/http-bind", client: (my IPv6), server: online.osba.nl, request: "GET /chat/http-bind HTTP/2.0", host: "online.osba.nl"

I had another look at my_webapp.conf, I found I was missing a slash at the end of the location:

location = /chat/http-bind {

instead of

location = /chat/http-bind/ {

After saving the file, I still get the wrong page, but at least I get ‘a’ page:

404 Not Found

Whatever you were looking for is not here. Keep looking.
Unknown host: online.osba.nl

Now at least the behaviour of Firefox is in correspondence with the behaviour in curl.

There still is an error in a rewriting rule: the logging has not changed:

2019/09/28 22:34:13 [notice] 4192#4192: *9 "^/chat$" does not match "/chat/http-bind/", client: 2001:982:1768:1:225:90ff:fe37:b6f8, server: online.osba.nl, request: "GET /chat/http-bind/ HTTP/2.0", host: "online.osba.nl"

This is on top of the my_webapp.conf, with the more specific location (/chat/http-bind/) near the bottom of the file. Should the more specific location be encapsulated in the upper level, or should it be a seperate location? (with location chat/http-bind{} outside of chat{})

rewrite ^/chat$ /chat/ permanent;
location /chat/ {
...
location = /chat/http-bind/ {}
}

No luck yet. As time permits I have been browsing the basics of nginX- rewriting,falling quite a bit short of what Yunohost has already set up for me.

I can see that at some point ‘control’ is being forwarded to the nextcloud-virtual server. At some point I added a rewrite there to get activitypub running (or ambling forward, as things go); it seems I have to check that rewrite and make it more specific.

For anyone struggling with the same issue: please chime in; I will update anyway in case I strike gold.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.