General idea¶

Installing matrix-synapse on an IPv6-only system.

Choosen way¶

Using the official matrix-synapse package by Debian or derivatives.

What has been done¶

• Installed matrix-synapse package from unstable on a Raspberry Pi running Debian Unstable with Apache 2.4 and only being reachable via IPv6.
• Installed matrix-synapse package from stable-backports on an IPv6-only Devuan 2.0 Ascii VM with h2o. (Connection unreliable, often reconnects)
• Connecting to both with quaternion.

Solved Issues¶

Doesn't work out of the box, several issues:

• starting the daemon exits with "file /etc/matrix-synapse/homeserver.signing.key not found" (or similar). Solve by calling

  /usr/bin/python3 -m synapse.app.homeserver --config-path=/etc/matrix-synapse/homeserver.yaml --config-path=/etc/matrix-synapse/conf.d/ --generate-keys

  manually.
• starting the daemon exits with "TLS certificate file not found". Solved by pointing to certbot-generated certificates.
• Hangs upon package configuration (Debian #920339) due to debconf waiting for daemon to close its inherited file descriptors. Solved by doing daemonization via start-stop-daemon's --background instead of matrix-synapse's buggy --daemonize in the init script. Sent a patch to the Debian bug report. (sysvinit-only issue)
• Tries to listen on the HTTPS port which is already in use. Set no_tls: True.
• Due to fiddling with the above, I once had a daemon which was no more exiting upon service matrix-synapse stop or service matrix-synapse restart, but the daemon only noticed seconds after the start that the port is already in use and only mentioned it in the log file. Hence also changed configurations had no effect. Killing that process solved the issue.

Configuration¶

• Use makepasswd --chars=42 generated password as secret registration_shared_secret and then call register_new_matrix_user -u abe -a -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008. It is important to not add a trailing slash to the URL as this results in only 400 Bad Request return codes.
• Pass all requests to /_matrix… on the webserver (reverse proxy) to http://localhost:8000/_matrix…:
  • Apache:
    

    ProxyPass        "/_matrix" "http://localhost:8008/_matrix" 
    ProxyPassReverse "/_matrix" "http://localhost:8008/_matrix" 
    

  • h2o:
    

        paths:
          /_matrix:
            proxy.reverse.url: http://localhost:8008/_matrix
    

Unsolved Issues¶

• Both instances don't talk with each other.
• Permissions to access the certbot-generated SSL keys and and certificates. (Client access is proxied through a proper webserver which handles HTTPS and is hence not affected.)

(These two issues might be related.)

• Very frequent connection loss to the Devuan VM with h2o. Likely caused by h2o (despite timeouts have been raised for the /_matrix* paths).

Conclusion¶

Not ready for prime time. The official Debian packaging (by Debian) still not ready for prime time either.