Synology Docker install: Everything extremely slow [redundant dns delay]

Installation Issues
1

Passbolt 3.11.0 running in docker from passbolt/passbolt:latest on a Synology DS1821+, connecting to a mariadb 10 on another machine.

Going to the web UI, after about 20 seconds the grey banner with “passbolt” show up, takes another 20 seconds before it shows the password list (which only has 12 entries). Using MS edge on windows 10.

Likewise, when I click on the toolbar button for the extension, it takes about 12 seconds of “connecting your account” before it goes to the login screen.

I’ve checked DB access manually, and both login and queries come back quickly; I’ve also tried the DB option to skip DNS lookups, but that didn’t make any difference. Also don’t see any issues with other apps that use the same DB server.

Enabling the query log on the sql server shows it takes ±6 seconds before passbolt even tries to connect after clicking the toolbar button.

If i do a curl from inside the passbolt container, I see it takes >5 seconds to even get the initial redirect back:

root@passbolt:/usr/share/php/passbolt# time curl -v --header 'Host: XXXXXX' http://localhost
*   Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: XXXXXXXXXX
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Server: nginx
< Date: Sat, 04 Mar 2023 18:40:51 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Keep-Alive: timeout=5
< Set-Cookie: passbolt_session=XXXXXXXXX; path=/; HttpOnly; SameSite=Lax
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< location: /auth/login?redirect=%2F
< Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self';frame-src 'self' https://*.duosecurity.com;
<
* Connection #0 to host localhost left intact

real    0m5.048s
user    0m0.005s
sys     0m0.005s

Only error in healthcheck is about the certs, which I think is normal when not using a custom cert?

 SSL Certificate

 [FAIL] SSL peer certificate does not validate
 [FAIL] Hostname does not match when validating certificates.
 [WARN] Using a self-signed certificate
 [HELP] Check https://help.passbolt.com/faq/hosting/troubleshoot-ssl
 [HELP] cURL Error (60) SSL certificate problem: unable to get local issuer certificate

Log warns about low entropy at the start, and there’s a bunch of

INFO reaped unknown pid xxx (exit status 0)

messages, but no other errors.

Any ideas or next debug steps to try?

2

Hi @desmej Welcome to the forum!

I would take a look at the help site for SSL certs noted in the healthcheck. Resources there are helpful and then that can be ruled out.

Posting any changes in your docker compose file will be good and we can double check that, especially since you are running the db on a different machine.

3

Disregard the following as potentially unhelpful @desmej but your post caught my eye as I’ve just gotten running using docker on my DS1019+.

I’ve tested setups using a custom cert and without (currently without) and instead use traefik to provide front edge TLS. Below is my healthcheck output…

 Core config

 [PASS] Debug mode is off.
 [PASS] Cache is working.
 [PASS] Unique value set for security.salt
 [PASS] Full base url is set to https://passbolt.mydomain.co.uk
 [PASS] App.fullBaseUrl validation OK.
 [PASS] /healthcheck/status is reachable.

 SSL Certificate

 [PASS] SSL peer certificate validates
 [PASS] Hostname is matching in SSL certificate.
 [PASS] Not using a self-signed certificate

Out of interest have you set the ‘APP_FULL_BASE_URL’ variable and is DNS working for it through to the app?

4

I’m doubtful SSL is the issue since that generally seems to be a black/white works/fails type thing, not a performance impact. But I will have a look anyway to try and rule it out completely.

I’m installing directly through the Synology docker app, so I’m not using docker-compose.

Here’s the exported settings:

{
   "CapAdd" : null,
   "CapDrop" : null,
   "cmd" : "/docker-entrypoint.sh",
   "cpu_priority" : 50,
   "enable_publish_all_ports" : false,
   "enable_restart_policy" : false,
   "enable_service_portal" : null,
   "enabled" : true,
   "env_variables" : [
      {
         "key" : "PATH",
         "value" : "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      },
      {
         "key" : "PASSBOLT_PKG_KEY",
         "value" : "0xDE8B853FC155581D"
      },
      {
         "key" : "PHP_VERSION",
         "value" : "7.4"
      },
      {
         "key" : "GNUPGHOME",
         "value" : "/var/lib/passbolt/.gnupg"
      },
      {
         "key" : "PASSBOLT_FLAVOUR",
         "value" : "ce"
      },
      {
         "key" : "PASSBOLT_PKG",
         "value" : "passbolt-ce-server"
      },
      {
         "key" : "DATASOURCES_DEFAULT_HOST",
         "value" : "XXXXXXXXX"
      },
      {
         "key" : "DATASOURCES_DEFAULT_PASSWORD",
         "value" : "XXXXXXXXX"
      },
      {
         "key" : "DATASOURCES_DEFAULT_USERNAME",
         "value" : "passbolt"
      },
      {
         "key" : "DATASOURCES_DEFAULT_DATABASE",
         "value" : "passbolt"
      },
      {
         "key" : "DATASOURCES_DEFAULT_PORT",
         "value" : "3307"
      },
      {
         "key" : "EMAIL_DEFAULT_FROM",
         "value" : "passbolt@XXXXXX"
      },
      {
         "key" : "EMAIL_TRANSPORT_DEFAULT_HOST",
         "value" : "XXXXXXXXX"
      },
      {
         "key" : "APP_FULL_BASE_URL",
         "value" : "https://XXXXXXXXX"
      },
      {
         "key" : "EMAIL_DEFAULT_FROM_NAME",
         "value" : "Passbolt"
      }
   ],
   "exporting" : false,
   "id" : "a9635c6c3c4ecaa2e38874597ff3ec09bc6e1aa336a3e19500e550200154451a",
   "image" : "passbolt/passbolt:latest",
   "is_ddsm" : false,
   "is_package" : false,
   "links" : [],
   "memory_limit" : 0,
   "name" : "passbolt",
   "network" : [
      {
         "driver" : "bridge",
         "name" : "bridge"
      }
   ],
   "network_mode" : "bridge",
   "port_bindings" : [
      {
         "container_port" : 443,
         "host_port" : 8743,
         "type" : "tcp"
      },
      {
         "container_port" : 80,
         "host_port" : 8780,
         "type" : "tcp"
      }
   ],
   "privileged" : false,
   "shortcut" : {
      "enable_shortcut" : false,
      "enable_status_page" : false,
      "enable_web_page" : false,
      "web_page_url" : ""
   },
   "use_host_network" : false,
   "volume_bindings" : []
}
5

I have set APP_FULL_BASE_URL.

DNS to it is working fine through the browser and browser extention. I can’t use the mobile app cause my phone’s tool old, so can’t check on that right now.

6

@desmej As the specs of the model you provided should have sufficient resources, it’s interesting that you had a message regarding low entropy. I suspect it’s not the app but another process or service. Do you have any other security apps running, like Snort or a firewall filter or scanner?

DNS resolution from the browser will use your local machine’s but within the container it would be a different story, of course. If you have more than one method of resolution, there may be a timeout occurring on the first before it goes to the second. In Linux systems the /etc/nsswitch.conf file is used to set the preferred resolution order.

Another thought since you said curl was slow is whether you have any other resource that is monitoring the container at the same time. Or firewall outgoing that gets blocked.

Another troubleshooting step could be to end any process that is not absolutely required and see if it makes any different.

7

Right mixed bag of trix here but I span up a test container to try and recreate your issues/validate log outputs.

Compose below. Thats just my pref but use docker cli also…I stopped using the Synology browser app given there is (or was when I started years back) a sizable feature difference between what the Synology app was able to do vs. the stock docker binaries you can run via ssh. Ignore the commented lines for now I’ll come on to that shortly.

version: '3.3'
services:
    
    test:
        container_name: test
        hostname: test
        restart: unless-stopped
        network_mode: bridge                # comment me when using blacknet
        ports:                              # comment me when using blacknet
            - 8743:443/tcp                  # comment me when using blacknet
        #networks:                          # comment me when using bridge
        #  blacknet:                        # comment me when using bridge
        #    ipv4_address: 192.168.10.10    # comment me when using bridge
        environment:
            APP_FULL_BASE_URL: https://test.mydomain.co.uk
            DATASOURCES_DEFAULT_HOST: mysql.mydomain.co.uk
            DATASOURCES_DEFAULT_USERNAME: test
            DATASOURCES_DEFAULT_PASSWORD: test
            DATASOURCES_DEFAULT_DATABASE: test
        image: passbolt/passbolt:latest
#networks:                                  # comment me when using bridge
#  blacknet:                                # comment me when using bridge
#    external: true                         # comment me when using bridge

With the above the healthcheck report I get gives me the following…

Core config

 [PASS] Debug mode is off.
 [PASS] Cache is working.
 [PASS] Unique value set for security.salt
 [PASS] Full base url is set to https://test.mydomain.co.uk
 [PASS] App.fullBaseUrl validation OK.
 [FAIL] Could not reach the /healthcheck/status with the url specified in App.fullBaseUrl
 [HELP] Check that the domain name is correct in /etc/passbolt/passbolt.php
 [HELP] Check the network settings

 SSL Certificate

 [PASS] SSL peer certificate validates
 [PASS] Hostname is matching in SSL certificate.
 [PASS] Not using a self-signed certificate

Leads me to conclude your SSL/TLS warnings could be the root issue and maybe DNS as @garrett says is a problem from your container itself.

However the above said, I can’t load the damn page either. Chrome or Edge just refuse…I experience a few browser challenges early on with getting my prod environment running but these seem to be resolved by a Chrome reset, however not in this instance. I can’t get past the below point…

passbolt-test
passbolt-test1279×722 10.4 KB

Its odd as the browser initially connects to the container as the redirects to the /auth/login are followed and you can see in the container an initial connection…
test | 172.17.0.1 - - [08/Mar/2023:20:37:25 +0000] "GET /auth/login?redirect=%2F HTTP/2.0" 200 1111 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36 Edg/110.0.1587.63"

Okay so try as I might I could not get a full page load on either http to https until…I moved the network stack off the docker default bridge and onto a macvlan network I use on the Synology. This is where the commented lines in the compose file come in.

By switching to us my “blacknet” macvlan network then boom the initial login pages loads without issue. Now is this the same as your issue…not convinced but its possible as its not beyond the realms of imagination that Synologys implementation of docker networking and nat are non-standard.

But I also noted a further difference between your scenario and my working prod, you are using the root image and I’m using the non-root. If testing on a macvlan network isn’t within easy reach for you then I’d suggest switching the image to test that?

1 Like
8

Solved! It was indeed a DNS issue. I have two DNS servers configured, the first one is the Synology box the container is running on, the second one is elsewhere on the network. And for some reason, the container can reach everything on the network except for its own host. (I think I’ve seen that before)

For now I’ve just removed the host from resolv.conf so it always immediately goes to the second server. And things are running as fast as expected now, with the extension connecting in well under a second.

Thanks to both of you for helping me fix this!

4 Likes
9

A relevant haiku

image
image550×707 39.4 KB

10

I’m glad to see you have solved your problem. And welcome to Passbolt!
In my experience, it’s better to have just one DNS server (the one in the domain provider) unless you are a super pro DNS admin hahahaha