README: rewrite installation instructions
parent
bb3d0c270d
commit
77bf92e3c6
65
README.rst
65
README.rst
|
@ -151,29 +151,56 @@ Also, Martin Giess has created an auto-deployment process with vagrant/ansible,
|
||||||
tested with VirtualBox/AWS/DigitalOcean - see https://github.com/EMnify/matrix-synapse-auto-deploy
|
tested with VirtualBox/AWS/DigitalOcean - see https://github.com/EMnify/matrix-synapse-auto-deploy
|
||||||
for details.
|
for details.
|
||||||
|
|
||||||
To set up your homeserver, run (in your virtualenv, as before)::
|
Configuring synapse
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
Before you can start Synapse, you will need to generate a configuration
|
||||||
|
file. To do this, run (in your virtualenv, as before)::
|
||||||
|
|
||||||
cd ~/.synapse
|
cd ~/.synapse
|
||||||
python -m synapse.app.homeserver \
|
python -m synapse.app.homeserver \
|
||||||
--server-name machine.my.domain.name \
|
--server-name my.domain.name \
|
||||||
--config-path homeserver.yaml \
|
--config-path homeserver.yaml \
|
||||||
--generate-config \
|
--generate-config \
|
||||||
--report-stats=[yes|no]
|
--report-stats=[yes|no]
|
||||||
|
|
||||||
...substituting your host and domain name as appropriate.
|
... substituting an appropriate value for ``--server-name``. The server name
|
||||||
|
determines the "domain" part of user-ids for users on your server: these will
|
||||||
|
all be of the format ``@user:my.domain.name``. It also determines how other
|
||||||
|
matrix servers will reach yours for `Federation`_. For a test configuration,
|
||||||
|
set this to the hostname of your server. For a more production-ready setup, you
|
||||||
|
will probably want to specify your domain (``example.com``) rather than a
|
||||||
|
matrix-specific hostname here (in the same way that your email address is
|
||||||
|
probably ``user@example.com`` rather than ``user@email.example.com``) - but
|
||||||
|
doing so may require more advanced setup - see `Setting up Federation`_.
|
||||||
|
|
||||||
This will generate you a config file that you can then customise, but it will
|
This command will generate you a config file that you can then customise, but it will
|
||||||
also generate a set of keys for you. These keys will allow your Home Server to
|
also generate a set of keys for you. These keys will allow your Home Server to
|
||||||
identify itself to other Home Servers, so don't lose or delete them. It would be
|
identify itself to other Home Servers, so don't lose or delete them. It would be
|
||||||
wise to back them up somewhere safe. If, for whatever reason, you do need to
|
wise to back them up somewhere safe. If, for whatever reason, you do need to
|
||||||
change your Home Server's keys, you may find that other Home Servers have the
|
change your Home Server's keys, you may find that other Home Servers have the
|
||||||
old key cached. If you update the signing key, you should change the name of the
|
old key cached. If you update the signing key, you should change the name of the
|
||||||
key in the <server name>.signing.key file (the second word) to something different.
|
key in the ``<server name>.signing.key`` file (the second word) to something different.
|
||||||
|
|
||||||
By default, registration of new users is disabled. You can either enable
|
The default configuration exposes two TCP ports: 8008 and 8448. Port 8008 is
|
||||||
registration in the config by specifying ``enable_registration: true`` (it is
|
configured without TLS; it is not recommended this be exposed outside your
|
||||||
then recommended to also set up CAPTCHA - see `<docs/CAPTCHA_SETUP.rst>`_), or
|
local network. Port 8448 is configured to use TLS with a self-signed
|
||||||
you can use the command line to register new users::
|
certificate. This is fine for testing with but you will almost certainly want
|
||||||
|
to use another certificate for production purposes. You can do so by changing
|
||||||
|
``tls_certificate_path``, ``tls_private_key_path`` and ``tls_dh_params_path``
|
||||||
|
in ``homeserver.yaml``; alternatively, you can use a reverse-proxy, but be sure
|
||||||
|
to read `Using a reverse proxy with Synapse`_ when doing so.
|
||||||
|
|
||||||
|
Registering a user
|
||||||
|
------------------
|
||||||
|
|
||||||
|
You will need at least one user on your server in order to use a Matrix
|
||||||
|
client. Users can be registered either `via a Matrix client`__, or via a
|
||||||
|
commandline script.
|
||||||
|
|
||||||
|
.. __: `client-user-reg`_
|
||||||
|
|
||||||
|
To get started, is easiest to use the command line to register new users::
|
||||||
|
|
||||||
$ source ~/.synapse/bin/activate
|
$ source ~/.synapse/bin/activate
|
||||||
$ synctl start # if not already running
|
$ synctl start # if not already running
|
||||||
|
@ -183,6 +210,16 @@ you can use the command line to register new users::
|
||||||
Confirm password:
|
Confirm password:
|
||||||
Success!
|
Success!
|
||||||
|
|
||||||
|
This process uses a setting ``registration_shared_secret`` in
|
||||||
|
``homeserver.yaml``, which is shared between Synapse itself and the
|
||||||
|
``register_new_matrix_user`` script. It doesn't matter what it is (a random
|
||||||
|
value is generated by ``--generate-config``), but it should be kept secret, as
|
||||||
|
anyone with knowledge of it can register users on your server even if
|
||||||
|
``enable_registration`` is ``false``.
|
||||||
|
|
||||||
|
Setting up a TURN server
|
||||||
|
------------------------
|
||||||
|
|
||||||
For reliable VoIP calls to be routed via this homeserver, you MUST configure
|
For reliable VoIP calls to be routed via this homeserver, you MUST configure
|
||||||
a TURN server. See `<docs/turn-howto.rst>`_ for details.
|
a TURN server. See `<docs/turn-howto.rst>`_ for details.
|
||||||
|
|
||||||
|
@ -215,9 +252,18 @@ start sending messages.
|
||||||
as of the time of writing it is somewhat outdated and not really recommended -
|
as of the time of writing it is somewhat outdated and not really recommended -
|
||||||
https://github.com/matrix-org/synapse/issues/1527).
|
https://github.com/matrix-org/synapse/issues/1527).
|
||||||
|
|
||||||
|
.. _`client-user-reg`:
|
||||||
|
|
||||||
Registering a new user from a client
|
Registering a new user from a client
|
||||||
------------------------------------
|
------------------------------------
|
||||||
|
|
||||||
|
By default, registration of new users via Matrix clients is disabled. To enable
|
||||||
|
it, specify ``enable_registration: true`` in ``homeserver.yaml``. (It is then
|
||||||
|
recommended to also set up CAPTCHA - see `<docs/CAPTCHA_SETUP.rst>`_.)
|
||||||
|
|
||||||
|
Once ``enable_registration`` is set to ``true``, it is possible to register a
|
||||||
|
user via `riot.im <https://riot.im/app/#/register>`_ or other Matrix clients.
|
||||||
|
|
||||||
Your new user name will be formed partly from the ``server_name`` (see
|
Your new user name will be formed partly from the ``server_name`` (see
|
||||||
`Configuring synapse`_), and partly from a localpart you specify when you
|
`Configuring synapse`_), and partly from a localpart you specify when you
|
||||||
create the account. Your name will take the form of::
|
create the account. Your name will take the form of::
|
||||||
|
@ -432,6 +478,7 @@ versions of synapse.
|
||||||
|
|
||||||
.. _UPGRADE.rst: UPGRADE.rst
|
.. _UPGRADE.rst: UPGRADE.rst
|
||||||
|
|
||||||
|
.. _federation:
|
||||||
|
|
||||||
Setting up Federation
|
Setting up Federation
|
||||||
=====================
|
=====================
|
||||||
|
|
Loading…
Reference in New Issue