Document/support running the server separately

[emansom]

Is your feature request related to a problem? Please describe.
From reading the documentation and very briefly some of the source code, it seems this plugin spawns its own server for chatting?

As a sysadmin I rather stay in control of which apps run where and how.

Describe the solution you'd like
This plugin to support bring your own chatserver configurations.

[JohnXLivingston]

Hi,

Indeed, this plugin includes the Prosody XMPP server, and spawns it as a child process.
It also spawns another process, for the moderation bot (https://github.com/JohnXLivingston/xmppjs-chat-bot).

By default, the Prosody server only listen on one port, and only on localhost interface. There are settings to open other ports, to allow XMPP clients or servers to connect, but this is totally optional. By default, all communications are proxyfied through Peertube (using Websocket or HTTP polling).

First versions of the plugin required admins to install Prosody manually. But many admins complained, finding it "too difficult" (...). Or there were some instance admins who were not root on the server, so they can't install the plugin.
That's why one of my sponsor asked me to include the Prosody server in the plugin.

If you don't trust the Prosody packaged in the plugin, you can install Prosody on your server (using debian packages, prosody source files, ... as you want). Then go to the plugin settings, and enable "use system prosody".
It will work with Prosody 0.12.x, and probably 0.11.x (but i can't garantee that).

If you do so, Peertube will still spawn prosody as child process, you don't have to enable the Prosody service on your system. This is mainly for following reasons:

• running prosody with the peertube user, to ensure it will have access to some files, and to be able to have multiple Peertube with different running users, for security reason
• be sure it will stop when peertube is stopped
• to be sure it will work in all Peertube setup, including docker installations
• and maybe others i don't have in mind yet (did not finished my morning cofee ;))

If this is still a problem for you, can you explicit your concerns?

[emansom]

But many admins complained, finding it "too difficult" (...). Or there were some instance admins who were not root on the server, so they can't install the plugin. That's why one of my sponsor asked me to include the Prosody server in the plugin.

Then they shouldn't be running internet facing web applications if they can't administrate a server. In docker setups: add another container to the compose/pod configuration. OS wide it'd be setting up a daemon -- all pretty simple.

If you don't trust the Prosody packaged in the plugin, you can install Prosody on your server (using debian packages, prosody source files, ... as you want). Then go to the plugin settings, and enable "use system prosody". It will work with Prosody 0.12.x, and probably 0.11.x (but i can't garantee that).

Quite frankly, yes, I don't trust it. This is the reason package repositories exist and are cryptographically signed.

If you do so, Peertube will still spawn prosody as child process, you don't have to enable the Prosody service on your system. This is mainly for following reasons:

I don't want it to spawn any process. I have my PeerTube instance jailed using SELinux and don't want it to log thousands of security policy events.

--
Edit: re-reading your comment the last part makes it seem like the plugin would still spawn its own Prosody server even when configured for system use. I assume this is not the case, and configuring the plugin to utilize a different Prosody server suffices?

If that is the case, that'd meet my requirements.

[JohnXLivingston]

But many admins complained, finding it "too difficult" (...). Or there were some instance admins who were not root on the server, so they can't install the plugin. That's why one of my sponsor asked me to include the Prosody server in the plugin.

Then they shouldn't be running internet facing web applications if they can't administrate a server. In docker setups: add another container to the compose/pod configuration. OS wide it'd be setting up a daemon -- all pretty simple.

Trying to satisfy everyone is not easy...

NB: in any case, Peertube needs to write the prosody configuration files. So, without root access, it can't be in /etc/prosody, so in any case i can't use the system daemon. And in docker installation, it would require some configuration to share files between containers.

If you do so, Peertube will still spawn prosody as child process, you don't have to enable the Prosody service on your system. This is mainly for following reasons:

I don't want it to spawn any process. I have my PeerTube instance jailed using SELinux and don't want it to log thousands of security policy events.

Can you just authorize prosody and prosodyctl?
Please note that in any case, Peertube already spawns some commands (ffmpeg for example).

-- Edit: re-reading your comment the last part makes it seem like the plugin would still spawn its own Prosody server even when configured for system use. I assume this is not the case, and configuring the plugin to utilize a different Prosody server suffices?

If that is the case, that'd meet my requirements.

Not sure to fully understand this comment. Just to be clear: if you enable this settings, instead of running the build in binary, it will use prosody and prosodyctl commands (that will be resolved using $PATH). It will not use the running daemon (as explained, this is to allow multiple instance to run on the server, and to allow peertube writing the configuration file).

[emansom]

NB: in any case, Peertube needs to write the prosody configuration files. So, without root access, it can't be in /etc/prosody, so in any case i can't use the system daemon. And in docker installation, it would require some configuration to share files between containers.

Why does it need to do that? I can modify those configuration files myself just fine.

Can you just authorize prosody and prosodyctl? Please note that in any case, Peertube already spawns some commands (ffmpeg for example).

I rather not. Why does it need these binaries?

Not sure to fully understand this comment. Just to be clear: if you enable this settings, instead of running the build in binary, it will use prosody and prosodyctl commands (that will be resolved using $PATH). It will not use the running daemon (as explained, this is to allow multiple instance to run on the server, and to allow peertube writing the configuration file).

I was under the assumption it'd connect on a protocol level only, not spawn binaries.

[emansom]

And instead of hardcoding localhost from here all over the place, can this be made configurable?

That'd allow Prosody to run in another container and communicate via internal docker networking afaict.

[JohnXLivingston]

NB: in any case, Peertube needs to write the prosody configuration files. So, without root access, it can't be in /etc/prosody, so in any case i can't use the system daemon. And in docker installation, it would require some configuration to share files between containers.

Why does it need to do that? I can modify those configuration files myself just fine.

Some options need to be set depending on the plugin configuration on Peertube (there are API keys, filepaths, some component that can be enabled/disabled, ...).

Can you just authorize prosody and prosodyctl? Please note that in any case, Peertube already spawns some commands (ffmpeg for example).

I rather not. Why does it need these binaries?

prosody is the XMPP server.
prosodyctl is a command line tool to manage the server (restart, reload, ...).

Not sure to fully understand this comment. Just to be clear: if you enable this settings, instead of running the build in binary, it will use prosody and prosodyctl commands (that will be resolved using $PATH). It will not use the running daemon (as explained, this is to allow multiple instance to run on the server, and to allow peertube writing the configuration file).

I was under the assumption it'd connect on a protocol level only, not spawn binaries.

And instead of hardcoding localhost from here all over the place, can this be made configurable?

That'd allow Prosody to run in another container and communicate via internal docker networking afaict.

Sorry, but what you are asking is to difficult to maintain and document. I don't have the budget and the time to do so. Unless you can sponsor such features (and on the long term, because it will require additional work on each new feature).

[emansom]

Some options need to be set depending on the plugin configuration on Peertube (there are API keys, filepaths, some component that can be enabled/disabled, ...).

An sysadmin is perfectly able to modify prosody.conf (or w/e its path may be) to the desired behavior of the plugin.

prosody is the XMPP server. prosodyctl is a command line tool to manage the server (restart, reload, ...).

I can restart and reload Prosody myself when required.

Sorry, but what you are asking is to difficult to maintain and document. I don't have the budget and the time to do so. Unless you can sponsor such features (and on the long term, because it will require additional work on each new feature).

Will submit a PR.

[JohnXLivingston]

An sysadmin is perfectly able to modify prosody.conf (or w/e its path may be) to the desired behavior of the plugin.

There are some settings that have to be modified dynamically from the Peertube settings.

Will submit a PR.

As i said, such feature would require a lot of additional work for me on the long term. This plugins needs to interact with the Prosody server in several ways (files on the filesystem, options in the configuration, tcp connections, ...). Maintaining and testing such features on such setup will require a lot of development time, documentation time and testing time.
I can't do it without a consequent funding. I will not merge such PR without guarantees. Sorry.

[emansom]

There are some settings that have to be modified dynamically from the Peertube settings.

Those features could be hidden and/or disabled when using remote Prosody is preferred.

As i said, such feature would require a lot of additional work for me on the long term. This plugins needs to interact with the Prosody server in several ways (files on the filesystem, options in the configuration, tcp connections, ...). Maintaining and testing such features on such setup will require a lot of development time, documentation time and testing time. I can't do it without a consequent funding. I will not merge such PR without guarantees. Sorry.

All features I can do without, the tcp connection handling is a proxy which once configurable suffices. I fail to see how this would be a maintenance burden. I'll maintain a fork then.

[JohnXLivingston]

Those features could be hidden and/or disabled when using remote Prosody is preferred.

Yes, but that means extra work each time i add a new option: should it be hidden?, test that it works in your use case, ...

All features I can do without, the tcp connection handling is a proxy which once configurable suffices. I fail to see how this would be a maintenance burden. I'll maintain a fork then.

Yes, be my guest. Please just respect the AGPL-v3 license, and publish your code.
If you achieve to do it, and if the code seems pretty simple to merge (and to maintain regarding future work i planned), i'm ok to reconsider mergin it upstream.

[emansom]

Yes, but that means extra work each time i add a new option: should it be hidden?, test that it works in your use case, ...

You can add a notice that there's no support offered for remote Prosody configurations. If it breaks I fix it.

Yes, be my guest. Please just respect the AGPL-v3 license, and publish your code. If you achieve to do it, and if the code seems pretty simple to merge (and to maintain regarding future work i planned), i'm ok to reconsider mergin it upstream.

Ofcourse! I'll maintain a fork on my profile here on GitHub.

[JohnXLivingston]

Feel free to propose any modification you want. If it seems relevant and clean to me, i will see if i merge or not.
Anyway, thanks for this, and sorry i can't help.

[JohnXLivingston]

Tips: if you have the plugin installed somewhere, you can see how looks the prosody.cfg file generated by the plugin, using the diagnostic tool.
Here are screenshots of mine, with some comments.
As you will see, prosody needs to have access to some directories where Peertube will write files.
These directories are described here:
https://livingston.frama.io/peertube-plugin-livechat/technical/data/

[JohnXLivingston]

This file is generated by the ProsodyConfigContent class:
https://github.com/JohnXLivingston/peertube-plugin-livechat/blob/main/server/lib/prosody/config/content.ts

It contains several methods, to enable/configure some features (for example usePeertubeBoshAndWebsocket to configure Websocket and Bosh access).
This class is used starting here:

peertube-plugin-livechat/server/lib/prosody/config.ts

Line 242 in 2047282

const config = new ProsodyConfigContent(paths, prosodyDomain)

[JohnXLivingston]

And please note that this file will be subject to change in a very near future. I'm working on many new features that will require new configuration entries.
It would definitively be simplier if you let Peertube somehow write part or all of this file (if you want, you can force certain values, such as port and listening interfaces).