prosody
9061f9621330
man/prosodyctl.markdown
Software / code / prosody
File
man/prosodyctl.markdown @ 12642:9061f9621330
Switch to a new role-based authorization framework, removing is_admin()
We began moving away from simple "is this user an admin?" permission checks
before 0.12, with the introduction of mod_authz_internal and the ability to
dynamically change the roles of individual users.
The approach in 0.12 still had various limitations however, and apart from
the introduction of roles other than "admin" and the ability to pull that info
from storage, not much actually changed.
This new framework shakes things up a lot, though aims to maintain the same
functionality and behaviour on the surface for a default Prosody
configuration. That is, if you don't take advantage of any of the new
features, you shouldn't notice any change.
The biggest change visible to developers is that usermanager.is_admin() (and
the auth provider is_admin() method) have been removed. Gone. Completely.
Permission checks should now be performed using a new module API method:
module:may(action_name, context)
This method accepts an action name, followed by either a JID (string) or
(preferably) a table containing 'origin'/'session' and 'stanza' fields (e.g.
the standard object passed to most events). It will return true if the action
should be permitted, or false/nil otherwise.
Modules should no longer perform permission checks based on the role name.
E.g. a lot of code previously checked if the user's role was prosody:admin
before permitting some action. Since many roles might now exist with similar
permissions, and the permissions of prosody:admin may be redefined
dynamically, it is no longer suitable to use this method for permission
checks. Use module:may().
If you start an action name with ':' (recommended) then the current module's
name will automatically be used as a prefix.
To define a new permission, use the new module API:
module:default_permission(role_name, action_name)
module:default_permissions(role_name, { action_name[, action_name...] })
This grants the specified role permission to execute the named action(s) by
default. This may be overridden via other mechanisms external to your module.
The built-in roles that developers should use are:
- prosody:user (normal user)
- prosody:admin (host admin)
- prosody:operator (global admin)
The new prosody:operator role is intended for server-wide actions (such as
shutting down Prosody).
Finally, all usage of is_admin() in modules has been fixed by this commit.
Some of these changes were trickier than others, but no change is expected to
break existing deployments.
EXCEPT: mod_auth_ldap no longer supports the ldap_admin_filter option. It's
very possible nobody is using this, but if someone is then we can later update
it to pull roles from LDAP somehow.
| author | Matthew Wild <mwild1@gmail.com> |
|---|---|
| date | Wed, 15 Jun 2022 12:15:01 +0100 |
| 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/>
