XMPP Server - Prosody

[robi]

Until @staff takes a look, have you taken a look at the other apps in the cloudron git already packaged and how they handle things?

[djxx]

@robi I did look at a few, but didn't see anything that jumped out at me as useful. I'm hoping someone can point me to a specific application that has done similar things so I can copy from there :).

[djxx]

After a lot of banging my head, not to music - but against the wall, I've made progress. I was writing files into /app/data in the Dockerfile directly, which the docs has a small footnote saying this is a bad idea. Another "great" thing is that the location prosody searches for files is hard-coded at compile time, so I had to adjust that to get it to look in the right place.

The latest code is up now. The xmpp server starts, but it's not connecting properly. I think there are some cert issues that I'll need to spend more time debugging. At this point, I think it requires more Prosody expertise than Cloudron expertise.

[djxx]

Ok! I've taken this as far as I can go without some support from @staff . The app launches and mostly gets its certs right. Until the certs are fully correct I can't get it to actually run, start the healthcheck endpoint, or debug the rest.

XMPP typically expects to use the primary domain, e.g. mydomain.com . It uses SRV records to point to the specific sub-domain (if there is one) that should be used for XMPP. The reason for this is so XMPP ID's look the same as e-mails, like me@mydomain.com. This is also very convenient for XMPP that has LDAP enabled since people will type in their same username and password they do elsewhere. If you tell XMPP its domain is xmpp.mydomain.com, then user IDs look like: me@xmpp.mydomain.com, which isn't the same as e-mail addresses, and people often forget.

This is where the limitations come in. XMPP expects lots of sub-domains, like: upload, conference, proxy, and pubsub.mydomain.com. It also expects certs for each of these, and the primary domain.

The tls add-on only fetches a cert for the application's sub-domain. IF you are lucky enough to use a registrar that gives you API access, then you COULD use the wildcard certificate option which will cover all the sub-domains. However, this still doesn't give you the cert for mydomain.com which is required for the standard username me@mydomain.com .

There are a few adjustments needed to solve these problems.
1 - The application manifest should let an application define multiple domains. If the domain registrar API is being used it should set them all up at once.
2 - The application manifest should allow getting individual certs for multiple subdomains in the event a registrar API is unavailable for a wildcard cert. The user can configure the domains, but still let Cloudron get the individual certs. The tls addon should pass all of these certs through.
3 - The application manifest should allow other record types to be configured - like SRV records - so the registrar API can be used for a seamless install.
4 - The tls addon should allow an application to request the primary mydomain.com cert for cases like this.

[robi]

@djxx Excellent work and points raised!

@girish will need to chime in here for the points, however we may have an app or two that does use multi-sub-domain deploys, like cryptpad which can provide an example of how that is handled certs wise.

[girish]

@djxx Great write up! I have some questions:

• How should the sub-domains be configured? For example - upload, conference, proxy ... Are these a) http or tcp b) If http, are these separate http services from the parent xmpp service itself?
• About the bare domain mydomain.com . So XMPP just needs the cert for this, but doesn't actually require any configuration as such? Meaning, no TCP or HTTP related configuration is required to what mydomain.com points to?

[djxx]

@girish - As far as I know, all ports except 5280 don't serve HTTP - they're just TCP traffic. The 5280 port is just for some modules, one of which is a "status" module I planned to use for the required healthcheck endpoint. I did my best to put the data in the manifest file, but honestly I got the port information from here: https://github.com/SaraSmiseth/prosody#ports

As for the bare domain, yes - it just needs the cert. It won't actually communicate through this domain; It relies on SRV DNS records to point XMPP clients to the sub-domain that is actually serving XMPP: https://github.com/SaraSmiseth/prosody#dns

It's possible some of these ports and domains could be consolidated - but there will for sure be more than one domain, port, and cert needed to set XMPP up properly.

[girish]

@djxx Ah ok, then this requires the platform feature to set up DNS when using TCP ports. Currently, we support this via aliases only when using HTTP.

But this shouldn't be a blocker because one can anyway put these DNS entries manually (for now, till we have all the requirements charted out).

Also, for your initial problem of not having the certs of the bare domain - just add the bare domain as an alias . You can do this by setting "multiDomain": true in the manifest. Once you do that the tls addon should provide with the cert as well.

[djxx]

@girish Thanks. Does enabling multiDomain result in the cert requested from Lets Encrypt using alternate names, or does it put multiple certs into /etc/certs ? Also, is there a way to specify the multiple domains in the manifest - or does it need to be done manually after the application is set up? This could make installation difficult if we need to partially start the application, then add some domain entries, and then do another action to complete the application's setup.

[djxx]

I went ahead and tried it, and I do see two certs now:

• tls_cert.pem
• xmpp.mydomain.com.cert

But both of these have CN and alternate name set to: *.mydomain.com and are the exact same cert.

[girish]

https://docs.trueelena.org/self_hosting/modern_xmpp_server/index.html has some XMPP setup . I haven't read through that in close detail.

[girish]

@djxx said in XMPP Server - Prosody:

But both of these have CN and alternate name set to: *.mydomain.com and are the exact same cert.

Will investigate when I find some time

[djxx]

@girish Any update on this? I'd like to be able to keep tinkering on this before I forget all the prosody and cloudron stuff I crammed in my head

[girish]

@djxx can only look into this after Christmas

[LoudLemur]

@djxx - thank you for doing this difficult work and helping Cloudron support XMPP.

I hope that we are able to make Prosody an officially supported application soon. Maybe your write up of the packaging experience will help others who might want to try supporting ejabberd.

Most people say ejabberd is tricky for configuration. I think that supporting it on Cloudron is one way to accomplish all that effort and make it available with one click.

Well done!

[LoudLemur]

Peertube has a chat plugin. One of the options is for XMPP Prosody:

[djxx]

Hello - any update on this? A standalone app is still needed; even though some apps like Jitsi use XMPP internally (like Jitsi) it doesn't mean it's useful for general external usage.

[robi]

@djxx check the VoceChat custom app install in the meantime.

[jdaviescoates]

@robi said in XMPP Server - Prosody:

@djxx check the VoceChat custom app install in the meantime.

That's not really comparable to an XMPP server.

[robi]

@jdaviescoates Neither is Jitsi.