yunohost
yunohost copied to clipboard
YunoHost
[muc subdomain] add to domain's certificate the alt subdomain muc
The problem
In metronome SASL on multi user chat always failed and fallback on dialback method. For some servers (eg. 404.city) this is not acceptable and they refuse to connect the user to the room.
Solution
Add muc subdomain as subjectAltName in the letsencrypt certificate.
PR Status
Need to be approved.
How to test
Create a room hosted on yunohost server, with participants from other servers.
- You should see in metronome log file (/var/log/metronome/metronome.log) "muc.{domain}.*SASL.*fail" and also "dialback"
- You shouldn't be able to add in the conversation a user from 404.city
Apply the change, regenerate your domain certificate.
- You should be able to add a user from 404.city
Good idea this PR.
I don't have time to test it right now but I've already spotted a possible problem: what would happen if the admin creates a yunohost domain muc.maindomain.tld? I know this is a bit different, but for xmpp-upload subdomain we had to take care of this use case, to avoid conflicts in nginx configuration. Maybe we should do something similar for muc subdomain, even if there is no nginx configuration involved. What do you think about it?
I'll try to test your PR this week-end, if I find FOSDEM's conferences boring :)
I was thinking the muc domain was a xmpp reserved one. But yes it surely can run with other services on other ports.
For my part I can live with this domain only set for xmpp multi user chat as it is currently the case.
Also migrating to something like xmpp-muc.domain.tld will need me to make all my conversation group again. This will not be very welcomed.
I don't think pitchum was suggesting to change the name, i think the point is just to add a validation like what's done for xmpp-upload here like if domain.startswith("muc.") ... and maybe we can have a more generic message like "This domain is reserved for specific feature"
It's not a huge deal but just in a safety thing because from experience, sooner or later an admin will try to add muc.domain.tld as a domain and then everything will explode (pretty sure it would already explode right now because of conflict in the metronome conf, but a conflict in the nginx conf is even worse ;P)
I see. I will gladly add the lines ... but I don't know how to modify/add a commit to the PR.
Just added the "validation if". what do I need to do for the translation in locales ?
Works for me.
Two operations need to be performed manually before it works:
- yunohost tools regen-conf nginx --force
- yunohost domain cert-renew --force mydomain.net
It would be nice if we could find a way to make this transparent for the users.
what do I need to do for the translation in locales ?
Add key "domain_cannot_add_muc" in locales/en.json like Aleks did here.
Works for me.
Good
Two operations need to be performed manually before it works:
* yunohost tools regen-conf nginx --force
* yunohost domain cert-renew --force mydomain.net
This will eventually be done at certification renewal and if nginx is not restarted it will fail dramatically ...
It would be nice if we could find a way to make this transparent for the users.
Agreed, but I have no clue how to proceed. Is there a mechanism in yunohost to apply "migration patches" or requirements for each version bump?
what do I need to do for the translation in locales ?
Add key "domain_cannot_add_muc" in locales/en.json like Aleks did here.
done