Setup an IRC Matrix bridge system

[strk]

Libera.chat operators are ok with us doing this. We could limit the bridge to known OSGeo channels and the bridge could be represented as a single IRC user to reduce the traffic.

[robe]

Are these instructions still valid:

​https://matrix-org.github.io/matrix-appservice-irc/latest/bridge_setup

[robe]

Another one ​https://github.com/hifi/heisenbridge

[robe]

I'm leaning toward heisenbridge. As best I understand from reading, it needs to be installed in the matrix container or same server so it can communicate with matrix on local port and share secrets.

I'm debating if I should install in venv, I'm leaning toward not since our matrix isn't in a venv either.

[robe]

Okay updated matrix page ​https://git.osgeo.org/gitea/sac/osgeo3/wiki/matrix-container#installing-irc-bridge-in-progress with my efforts so far and sadly failing on ERROR:root:Unexpected failure when registering appservice user.

It generated the heisenbridge yaml file okay but maybe /etc/matrix-synapse/conf.d/heisenbridge.yaml or /etc/matrix-synapse/heisenbridge.yaml are neither the right place or the port matrix is running on is not default

[robe]

Okay got a bit farther. I added the path to the config in /etc/matrix-synapse/home-server.yaml and it started without error

[strk]

I'd recommend using an ansible role to deploy the bridge

[strk]

It looks like an ansible role for the whole matrix ecosystem exists here: ​https://github.com/spantaleev/matrix-docker-ansible-deploy

It may be used to deploy both synapse and the bridge (and optionally a lot more). It is docker based.

[strk]

With ​https://git.osgeo.org/gitea/sac/ansible-deployment/commit/d7961f62b22015b923b5475f756b3e6f970712c4 I've stubbed an ansible role for heisenbridge, startign from a version received on IRC by "hifi" in the Heisenbridge channel.

I didn't use it yet.

Instead I've restarted the bridge with the correct --owner (was lacking the @ suffix) so now I could DM the bot. I've updated ​https://git.osgeo.org/gitea/sac/osgeo3/wiki/matrix-container

[strk]

I've plumbed #sac:osgeo.org to #osgeo-sac on libera.chat Tests welcome.

[strk]

I think we should ensure both heisenbridge (the bot) and the puppeted IRC users use a name which is forbidden to be registered in LDAP, for security reasons.

[strk]

I've filed ​https://git.osgeo.org/gitea/sac/web-cgi-bin/issues/19 to reserve a class/prefix

[strk]

As reported upstream, we found dashes are already reserved, so the heisenbridge user should be renamed to something like osgeo-service-heisenbridge or osgeo-matrix or something. I like short names more

[strk]

The other thing to fix is the ident service, doesn't seem to be working

[strk]

The service is now being deployed via ansible, see ​https://git.osgeo.org/gitea/sac/ansible-deployment/commit/b8e5e633967222d73d9192fd877dc465b2187dc4

The only change on the server machine is that the bridge is now controlled by a proper systemd service. I failed to change the heisenbridge MXID so far, as changing the sender_localpart setting in /etc/matrix-synapse/heisenbridge.yaml had no effect.

We're also still missing running as an unprivileged user (and the ident part)

[strk]

I've now deployed the updated LDAP user creation script to forbid creation of "heisenbridge" as a name.

[strk]

With help of Greyshade we now have heisenbridge running as an unprivileged user so we changed the ident port to 9113 and the firewall needs be updated. See ​https://git.osgeo.org/gitea/sac/ansible-deployment/commit/07f5243f500764f9eedcb62320490f4be6af68bb

I suggest the firewall configuration is also done via ansible as it already does ufw: ​https://git.osgeo.org/gitea/sac/ansible-deployment/src/branch/master/deployment/roles/osgeo3/tasks/main.yml#L144

[strk]

I've pushed a task in ansible to setup the matrix container: ​https://git.osgeo.org/gitea/sac/ansible-deployment/src/branch/master/deployment/roles/osgeo3/tasks/main.yml#L73

I didnt' deploy it so it's to be tested carefully. The container configuration in ansible was copied from the running system except for base image (set to debian-11 in ansible but the current container is running debian-10, see #2988) and the configuration of the proxy device to use "proxy_protocol":

​https://git.osgeo.org/gitea/sac/ansible-deployment/src/branch/master/deployment/roles/osgeo3/defaults/main/container_matrix.yml

I'm not sure if "proxy_protocol" is what we need but I know we need the identd server inside the container to see the real IP address of the ident client contacting it.

[strk]

The proxy_protocol=true setting on the proxy is now active but we're still not good, probably not receiving the correct IP

[strk]

ident calls to the IP of the container on port 9113 are received while calls to the IP of the host on port 113 seem to never reach the container

[strk]

I've reverted to proxy_protocol=false as Heisenbridge does not support that, and now we're listening on any IP. This makes requests to osgeo3 ident reach the container, but the container will check source IP and always refuse to give a proper answer, until we upgrade Heisenbridge to a new version or patch it locally.

New version requires newer python (3.9) which is not packaged on the debian versino in that matrix container, so if we want to improve things we should upgrade the whole container to Debian 11 (if not 12)

[robe]

As I recall you have to do each major upgrade so we need to go to debian 11 before 12 anyway. I'll experiment with upgrading it in staging. Is there any harm you can think of. I assume since all the stuff is matrix.osgeo.org, it wouldn't be reachable anyway.

Alternatively we could just take a snapshot, upgrade and revert to snapshot if anything goes wrong. I feel like this would be hard to test in staging anyway.

[robe]

Oh speaking of the proxy, as I mentioned I think nat proxy might be the best way to go as described here: detailed here - ​https://discuss.linuxcontainers.org/t/using-nat-true-on-proxy-devices/9538

The key benefit with nat=true is that the container sees the source of the true ip without need for proxy and you also get slightly better performance. The key con, is then you need to give the container a fixed IP using the ip override command. I don't see this as a huge deal since containers tend to keep their ips anyway once assigned

[strk]

Ok ident is now fixed by a monkey-patching of the heisenbridge ident script: ​https://git.osgeo.org/gitea/sac/ansible-deployment/commit/b629346467da95bbf641a96a0ce9e73a765183a6

Somewhat fragile but there we are. identd now works, I've configured it and the osgeo-matrix libera-chat nick (registered) is now reported as being a nice service user:

20:29:04 -- | [osgeo-matrix] (heisenbr@osgeo/services): heisenbridge
20:29:04 -- | [osgeo-matrix] zirconium.libera.chat (Milano, IT)
20:29:04 -- | [osgeo-matrix] is using a secure connection
20:29:04 -- | [osgeo-matrix] is logged in as osgeo-matrix
20:29:04 -- | [osgeo-matrix] End of /WHOIS list.

[strk]

I'd love to control IPs of those containers, setting them via ansible

[robe]

Yes we should do that.

[strk]

I'll close this ticket as completed, we can always file new tickets for new problems. Newer versions of Heisenbridge will not check source IP on identd requests so not a big deal.