Project

General

Profile

Actions

Task #6753

closed

Installing a Matrix server on IPv6 only

Added by Axel Beckert about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Start date:
06/01/2019
Due date:
% Done:

0%

Estimated time:
PM Check date:
Actions #1

Updated by Axel Beckert about 3 years ago

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.

Actions #2

Updated by Nico Schottelius about 3 years ago

  • Status changed from In Progress to Resolved

Thanks everyone for participating! It was great seeing all of you!

Actions #3

Updated by Nico Schottelius about 3 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF