Well, each user would have to override it anyway, because `-c /etc/synapse/appservice-irc-config.yaml -f /etc/synapse/appservice-irc-registration.yaml -p 9009` is user specific (I actually have different values for the three of them). Your `WantedBy` also is not necessarily the same for everyone (you can run both on different machines, VMs, etc.

That being said, we could still provide a default with a list of hardening bits enabled.

My service file (before decommissioning, I don’t run one anymore):
```
[Unit]
Description=Matrix IRC Bridge
After=network.target synapse.service

[Service]
Type=simple
User=synapse
Group=synapse
ExecStart=/usr/bin/matrix-appservice-irc -c /etc/synapse/irc.config.yaml -f /etc/synapse/irc.registration.yaml -p 9999
Restart=on-failure

[Install]
WantedBy=multi-user.target
```

Hardening would be required. ExecStart is likely to be overridden by user as stated above.

Couldn't this be handled much like the webapps packages are handled (ex: nextcloud, riot, phpmyadmin, etc)? Right now installing this package as an arch package is rather weird; it's not entirely clear what benefit the package provides vs just installing from the git repo. The webapps all have symlinks to their config files an expected location in `/etc`, a sample config, and then I configure a webserver to host them.

Looking at this more closely, I'm not sure most users should need to customize the ExecStart. There's `bindPort` in the config.yaml, so no reason to put the port in the systemd unit. A single appservice can handle multiple IRC servers, so running multiple appservices might not be something that needs to be supported BUT if we want to support that (ie, for someone running appservices for multiple synapse servers), it should be done via systemd template services.
Ex:

[Unit]
Description=Matrix IRC Bridge
After=network.target synapse.service

[Service]
Type=simple
User=synapse
Group=synapse
WorkingDirectory=/usr/lib/node_modules/matrix-appservice-irc/
ExecStart=/usr/bin/matrix-appservice-irc -c /etc/synapse/matrix-appservice-irc/config-%i.yaml \
-f /etc/synapse/matrix-appservice-irc/registration-%i.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

@damjan: Thanks for bringing up this issue.

@bobpaul and @damjan: I've just pushed matrix-appservice-irc 0.16.0 to [community-testing]. Please give it a spin.
Note: I've removed a lot of clutter from the package (and I hope I didn't accidentally break anything). I currently sadly have no setup to test this with, so it would be very awesome, if you could report back on any issues you might have!
Make sure to backup any configuration files/services files you are currently using before running the service!

matrix-appservice-irc is now run as its own user/group. The configuration files are installed 0640 to /etc/matrix-appservice-irc/ and I've added many hardening options to the service file.
Please report back on any problems, that you run into with the service or the package itself!

Last, but not least: I have not added synapse.service to After=, as there is the use-case of running the bridge on a host, that is not running synapse. If you require it, you can of course add it in an override.

> Last, but not least: I have not added synapse.service to After=, as there is the use-case of running the bridge on a host, that is not running synapse.

I don't mind that, although After=synapse.service only has any effect if both services *are* enqueued to start on the same host. Otherwise it's a noop (in other words, After/Before only specifies ordering, not dependencies).

I'll test the package soon.

> I don't mind that, although After=synapse.service only has any effect if both services *are* enqueued to start on the same host. Otherwise it's a noop (in other words, After/Before only specifies ordering, not dependencies).

Oh, you are right! Didn't think clearly. Definitely worth adding back...


Thanks for the feedback!

seems it can't import bluebird

@damjan: Thanks! Seems I was too overly eager to remove unneeded things. Turns out package.json files are required ;-)

I've pushed a new version to [community-testing] (also with small changes to the service). Please try again!

seems to work nice now.

btw, why did you add CapabilityBoundingSet=CAP_NET_BIND_SERVICE ?
That doesn't add a capability (if you had that in mind) - and since it's a non-root user it doesn't have any capabilities. you maybe wanted to use AmbientCapabilities=

@damjan: Glad to hear! I'm not entirely sure. I think I was under the assumption, that the service might need a to be able to assign a port, but just now realized, that this is only valid for ports < 1024, which this service should never use.
It can be removed altogether.

Thanks again for all the great feedback!