Difference between revisions of "Prosody"
m (→SSL) |
(→SSL: MUC cert) |
||
| Line 46: | Line 46: | ||
If using ''LetsEncrypt'' certificates, then you need to ensure that the private keys are readable by ''Prosody'' (they same thing applies when using them with other services like ''Exim'' and ''Dovecot'' too). | If using ''LetsEncrypt'' certificates, then you need to ensure that the private keys are readable by ''Prosody'' (they same thing applies when using them with other services like ''Exim'' and ''Dovecot'' too). | ||
| − | For server-to-server communications to work, there must be a valid certificate defined for the MUC sub-domain as well. | + | For server-to-server communications to work (which is needed for when users from other servers wish to join a room), there must be a valid certificate defined for the MUC sub-domain as well. The main certificate specified in the virtual host container can be used without any specific settings in the MUC component as long as it covers the sub-domain in it's alt-name field. |
== Using the Prosody server that ships with Jitsi == | == Using the Prosody server that ships with Jitsi == | ||
Revision as of 00:16, 11 May 2020
|
Prosody is a light-weight, easy to configure, XMPP server. XMPP is an open and extensible Internet protocol used for communications, presence, identification, authentication etc. It's a big part of the Semantic Web movement which is all about achieving the functionality we need using open standards instead of specific applications.
Contents
Configuration
The prosody configuration is in /etc/prosody with a similar style to Apache or Nginx where individual site's configuration each exist in their own file in the conf.avail sub-directory usually having a filename matching the domain name. Sites are then enabled by creating sym-links in the conf.d sub-directory pointing to the available sites.
Here's an example configurtion file for a specific domain which is set up as a chatroom server starting with the familiar VirtualHost directive to indicate the domain that this configuration covers.
VirtualHost "xmpp.organicdesign.nz"
ssl = {
key = "/etc/prosody/certs/xmpp.organicdesign.nz.key";
certificate = "/etc/prosody/certs/xmpp.organicdesign.nz.crt";
}
-- use an empty admins list to disable all remote administration functions
admins = { "foo@xmpp.organicdesign.nz" }
Component "conference.xmpp.organicdesign.nz" "muc"
name = "The dharma.casa XMPP chatrooms server"
allow_registration = false
c2s_require_encryption = true
s2s_require_encryption = true
-- set admins for the room and ensure only they can create new rooms
admins = { "admin@xmpp.organicdesign.nz" }
restrict_room_creation = true
modules_enabled = {
"tls",
"roster",
"register"
}Users
Users are managed from the CLI with prosodyctl, or can be added from a client with sufficient capabilities such as Pidgin if you're using an administrator account. Users can also change their own passwords and other personal information if the client supports it.
prosodyctl adduser foo@example.comChatrooms
The domain of the chat server is the domain of the "muc" component as as defined in the config, in our case muc.xmpp.organicdesign.nz. Using the configuration above, administrators of the MUC component are able to create new rooms from within their client if it has sufficient capabilities such as Pidgin or Dino.
SSL
If using LetsEncrypt certificates, then you need to ensure that the private keys are readable by Prosody (they same thing applies when using them with other services like Exim and Dovecot too).
For server-to-server communications to work (which is needed for when users from other servers wish to join a room), there must be a valid certificate defined for the MUC sub-domain as well. The main certificate specified in the virtual host container can be used without any specific settings in the MUC component as long as it covers the sub-domain in it's alt-name field.
Using the Prosody server that ships with Jitsi
Jitsi comes needs an XMPP server as part of its infrastructure and uses Prosody, so if you're running a Jitsi, then you can easily add another virtual hosts configuration for a dedicated XMPP server as well using the same procedure shown above.
