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.
djxx
Posts
-
XMPP Server - Prosody -
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
-
XMPP Server - ProsodyI 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.
-
XMPP Server - Prosody@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.
-
XMPP Server - Prosody@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.
-
XMPP Server - ProsodyOk! 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, likeme@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 isxmpp.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 formydomain.com
which is required for the standard usernameme@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. Thetls
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 - Thetls
addon should allow an application to request the primarymydomain.com
cert for cases like this. -
XMPP Server - ProsodyAfter 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.
-
XMPP Server - Prosody@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 :).
-
XMPP Server - ProsodyI made a few attempts to get around the permission issues - but they're pretty hacky. I'd appreciate some advice on the best way to approach this. I've pushed up the latest code and docker images of my attempts.
-
XMPP Server - ProsodyThis ties into the following wishlist items:
- https://forum.cloudron.io/topic/7755/openfire-xmpp-server
- https://forum.cloudron.io/topic/2486/ejabberd-robust-scalable-and-extensible-realtime-server-using-xmpp-mqtt-and-sip
- https://forum.cloudron.io/topic/4188/snikket-server-your-own-messaging-server-in-a-box
These are the three "main" XMPP servers out there (with Snikket being a simplified deploment of Prosody). I think most of the people making these requests don't actually care which server is used - as long as it has the common modules, like roster, OMEMO encryption, file upload, etc.
I have chosen to package Prosody over the others because:
- OpenFire - I know nothing about it
- ejabberd - It's what is running on my server and the configuration for it is a pain
- Snikket - it's TOO simple, not giving us options to configure things
While Prosody does have its own docker image, I started from a different one because it has a sensible set of defaults baked in, is easy to extend, and is making use of environment variables for a lot of the configuration. Since Cloudron can inject environment variables with addons, I thought it would be easy to map Cloudron's environment variables to the ones expected by this container.
Here's where I'm at:
- I've made a repostory
- I've built a docker image
- I've tried to install it
Addons being used:
- tls - The app needs the certs to secure information on a number of ports other than HTTP
- ldap - I want to do SSO
- storage - The app needs to store data for message history, uploads, etc.
Upon install I'm getting an error related to me trying to create the cert structure described here: https://github.com/SaraSmiseth/prosody/tree/dev#ssl-certificates
mkdir: cannot create directory '/usr/local/etc/prosody/certs/upload.xmpp.domain.tld': Read-only file system
My plan for managing the SSL certs was to have the entrypoint script create the directory structure required by the app within the
/app/data
folder, copy the certs as provided by the tls addon, and symlink that directory to the expected directory/usr/local/var/lib/prosody
. From what I've read, there are a few hard-coded things in prosody that may be difficult to change - which is why I'm trying to find a way to put the certs where it expects to find them.So now I need some help figuring out the best way to deal with this read-only file system issue. Help would be greatly appreciated!
Other Notes:
There's a health check module for prosody that can also serve up a status through HTTP. I am planning to use this for the required healthcheck endpoint, and since an HTTP endpoint is generally not used for this application I also want to put it behind auth. The only purpose this HTTP endpoint serves is for the mandatory health check for the Manifest. -
Gitlab Runner - OK on the same machine? -
Gitlab Runner - OK on the same machine?and running now a gitlab runner as a custom cloudron app.
Thanks :). Can you tell me how you did this? What impact does docker in docker not working have on being able to run builds and have a container registry?
-
Gitlab Runner - OK on the same machine?I read this post (https://forum.cloudron.io/topic/1373/gitlab-runner-for-ci) as well as the docs (https://docs.cloudron.io/apps/gitlab/#gitlab-runner-for-ci) and it seems to suggest it's possible to install a runner directly on the same Cloudron machine. I've read in other topics that we should not use regular docker images for apps on Cloudron because it can conflict with Cloudron's special packaging approach.
Is it OK to follow the instructions in the docs on my Cloudron machine directly? Where is the line that I shouldn't cross when it comes to running custom Docker images or installing extra packages?
-
Snikket Server - Your own messaging server in a box@murgero - sorry, not seeing an option to PM you. Can you give us an update here on how Snikket is working for you? I'm willing to put some money towards making a custom app for this. I think doing Snikket + 2-3 more configuration options will be enough for more self hosters.
-
Current state of XMPP on Cloudron?@jdaviescoates That's really a shame. It's a bit annoying to see duplicates of other applications (invoicing, GIT, image sharing) and not a single one for XMPP. Is it possible to down-vote existing duplicate applications to free-up time for new ones?
-
Current state of XMPP on Cloudron?I see a post from 2022 talking about OpenFire and the code repository is from that same timeframe - 1 year and no update. Is this a viable option for XMPP on Cloudron, and if not - has there been any progress on Snikket?
For some background, I've used both NethServer and YunoHost to self-host and I'm eager to move to something with a bit more support. I'm really liking all the apps I see here on Cloudron, but I can't believe there's not a single XMPP option!
For me, this is a must-have because I use the wonderful https://jmp.chat/ service to give me access to a fully functioning phone number (voice + SMS) anywhere I have internet.
I can't move my server without XMPP support, so I'm hoping for some good news.