prosody
a08065207ef0
man/prosodyctl.markdown
Software / code / prosody
File
man/prosodyctl.markdown @ 13652:a08065207ef0
net.server_epoll: Call :shutdown() on TLS sockets when supported
Comment from Matthew:
This fixes a potential issue where the Prosody process gets blocked on sockets
waiting for them to close. Unlike non-TLS sockets, closing a TLS socket sends
layer 7 data, and this can cause problems for sockets which are in the process
of being cleaned up.
This depends on LuaSec changes which are not yet upstream.
From Martijn's original email:
So first my analysis of luasec. in ssl.c the socket is put into blocking
mode right before calling SSL_shutdown() inside meth_destroy(). My best
guess to why this is is because meth_destroy is linked to the __close
and __gc methods, which can't exactly be called multiple times and
luasec does want to make sure that a tls session is shutdown as clean
as possible.
I can't say I disagree with this reasoning and don't want to change this
behaviour. My solution to this without changing the current behaviour is
to introduce a shutdown() method. I am aware that this overlaps in a
conflicting way with tcp's shutdown method, but it stays close to the
OpenSSL name. This method calls SSL_shutdown() in the current
(non)blocking mode of the underlying socket and returns a boolean
whether or not the shutdown is completed (matching SSL_shutdown()'s 0
or 1 return values), and returns the familiar ssl_ioerror() strings on
error with a false for completion. This error can then be used to
determine if we have wantread/wantwrite to finalize things. Once
meth_shutdown() has been called once a shutdown flag will be set, which
indicates to meth_destroy() that the SSL_shutdown() has been handled
by the application and it shouldn't be needed to set the socket to
blocking mode. I've left the SSL_shutdown() call in the
LSEC_STATE_CONNECTED to prevent TOCTOU if the application reaches a
timeout for the shutdown code, which might allow SSL_shutdown() to
clean up anyway at the last possible moment.
Another thing I've changed to luasec is the call to socket_setblocking()
right before calling close(2) in socket_destroy() in usocket.c.
According to the latest POSIX[0]:
Note that the requirement for close() on a socket to block for up to
the current linger interval is not conditional on the O_NONBLOCK
setting.
Which I read to mean that removing O_NONBLOCK on the socket before close
doesn't impact the behaviour and only causes noise in system call
tracers. I didn't touch the windows bits of this, since I don't do
windows.
For the prosody side of things I've made the TLS shutdown bits resemble
interface:onwritable(), and put it under a combined guard of self._tls
and self.conn.shutdown. The self._tls bit is there to prevent getting
stuck on this condition, and self.conn.shutdown is there to prevent the
code being called by instances where the patched luasec isn't deployed.
The destroy() method can be called from various places and is read by
me as the "we give up" error path. To accommodate for these unexpected
entrypoints I've added a single call to self.conn:shutdown() to prevent
the socket being put into blocking mode. I have no expectations that
there is any other use here. Same as previous, the self.conn.shutdown
check is there to make sure it's not called on unpatched luasec
deployments and self._tls is there to make sure we don't call shutdown()
on tcp sockets.
I wouldn't recommend logging of the conn:shutdown() error inside
close(), since a lot of clients simply close the connection before
SSL_shutdown() is done.
| author | Martijn van Duren <martijn@openbsd.org> |
|---|---|
| date | Thu, 06 Feb 2025 15:04:38 +0000 |
| parent | 12246:51930f685c16 |
line wrap: on
line source
--- author: - Dwayne Bent <dbb.1@liqd.org> - Kim Alvefur date: 2022-02-02 section: 1 title: PROSODYCTL --- # NAME prosodyctl - Manage a Prosody XMPP server # SYNOPSIS prosodyctl command [--help] # DESCRIPTION prosodyctl is the control tool for the Prosody XMPP server. It may be used to control the server daemon and manage users. prosodyctl needs to be executed with sufficient privileges to perform its commands. This typically means executing prosodyctl as the root user. If a user named "prosody" is found then prosodyctl will change to that user before executing its commands. # COMMANDS ## User Management In the following commands users are identified by a Jabber ID, jid, of the usual form: user@domain. adduser jid : Adds a user with Jabber ID, jid, to the server. You will be prompted to enter the user's password. passwd jid : Changes the password of an existing user with Jabber ID, jid. You will be prompted to enter the user's new password. deluser jid : Deletes an existing user with Jabber ID, jid, from the server. ## Daemon Management Although prosodyctl has commands to manage the prosody daemon it is recommended that you utilize your distributions daemon management features if you attained Prosody through a package. To perform daemon control commands prosodyctl needs a pidfile value specified in `/etc/prosody/prosody.cfg.lua`. Failure to do so will cause prosodyctl to complain. start : Starts the prosody server daemon. If run as root prosodyctl will attempt to change to a user named "prosody" before executing. This operation will block for up to five seconds to wait for the server to execute. stop : Stops the prosody server daemon. This operation will block for up to five seconds to wait for the server to stop executing. restart : Restarts the prosody server daemon. Equivalent to running prosodyctl stop followed by prosodyctl start. reload : Signals the prosody server daemon to reload configuration and reopen log files. status : Prints the current execution status of the prosody server daemon. ## Certificates prosodyctl can create self-signed certificates, certificate requests and private keys for use with Prosody. Commands are of the form `prosodyctl cert subcommand`. Commands take a list of hosts to be included in the certificate. `request hosts` : Create a certificate request (CSR) file for submission to a certificate authority. Multiple hosts can be given, sub-domains are automatically included. `generate hosts` : Generate a self-signed certificate. `key host [size]` : Generate a private key of 'size' bits (defaults to 2048). Invoked automatically by 'request' and 'generate' if needed. `config hosts` : Produce a config file for the list of hosts. Invoked automatically by 'request' and 'generate' if needed. `import hosts paths` : Copy certificates for hosts into the certificate path and reload prosody. ## Debugging prosodyctl can also show some information about the environment, dependencies and such to aid in debugging. `about` : Shows environment, various paths used by Prosody and installed dependencies. `check [what]` : Performs various sanity checks on the configuration, DNS setup and configured TLS certificates. `what` can be one of `config`, `dns` `certs`, `disabled` and `connectivity` to run only that check. ## Ejabberd Compatibility ejabberd is another XMPP server which provides a comparable control tool, ejabberdctl, to control its server's operations. prosodyctl implements some commands which are compatible with ejabberdctl. For details of how these commands work you should see ejabberdctl(8). register user server password unregister user server # OPTIONS `--config filename` : Use the specified config file instead of the default. `--root` : Don't drop root privileges (e.g. when invoked with sudo). `--help` : Display help text for the specified command. `--verbose` : Increase log level to show debug messages. `--quiet` : Reduce log level to only show errors. `--silent` : Disable logging completely, leaving only command output. # FILES `/etc/prosody/prosody.cfg.lua` : The main prosody configuration file. prosodyctl reads this to determine the process ID file of the prosody server daemon and to determine if a host has been configured. # ONLINE More information may be found online at: <https://prosody.im/>
