XMPP Server - Prosody
-
@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 whatmydomain.compoints to?
@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 - 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.
@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": truein the manifest. Once you do that the tls addon should provide with the cert as well. -
@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": truein the manifest. Once you do that the tls addon should provide with the cert as well.@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.
-
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.
-
@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
-
@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
-
@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!
-
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 said in XMPP Server - Prosody:
@djxx check the VoceChat custom app install in the meantime.
That's not really comparable to an XMPP server.
-
@jdaviescoates Neither is Jitsi.
-
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.
-
@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
@djxx said in XMPP Server - Prosody:
@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
I know the feeling! We lose a lot if we suspend focus on a project for a while.
-
D djxx referenced this topic on
-
@djxx Is https://github.com/DerekJarvis/cloudron-prosody still the latest code? We should have some free cycles coming up, so I thought we can take a look if this is something easily doable. I can't promise we will publish it since it seems quite complicated (it's why we had to remove Jitsi too, it became way too hard to fight their system). Was the cert issue the blocker for you to just use your custom image yourself?
