Просмотр исходного кода

Merge remote-tracking branch 'github/master'

pull/581/head
benkuly 5 лет назад
Родитель
Сommit
2561d9c0c9
9 измененных файлов: 111 добавлений и 16 удалений
  1. +1
    -0
      docs/configuring-playbook-s3.md
  2. +2
    -2
      docs/howto-server-delegation.md
  3. +51
    -0
      docs/importing-postgres.md
  4. +0
    -5
      roles/matrix-base/tasks/main.yml
  5. +0
    -1
      roles/matrix-base/tasks/validate_config.yml
  6. +1
    -1
      roles/matrix-bridge-mautrix-telegram/defaults/main.yml
  7. +24
    -2
      roles/matrix-bridge-mautrix-telegram/templates/config.yaml.j2
  8. +1
    -1
      roles/matrix-synapse/defaults/main.yml
  9. +31
    -4
      roles/matrix-synapse/templates/synapse/homeserver.yaml.j2

+ 1
- 0
docs/configuring-playbook-s3.md Просмотреть файл

@@ -47,5 +47,6 @@ You can use any S3-compatible object store by **additionally** configuring these

```yaml
matrix_s3_media_store_custom_endpoint_enabled: true
# Example: "https://storage.googleapis.com"
matrix_s3_media_store_custom_endpoint: "your-custom-endpoint"
```

+ 2
- 2
docs/howto-server-delegation.md Просмотреть файл

@@ -82,8 +82,8 @@ Based on your setup, you have different ways to go about it:
#
# NOTE: these are in-container paths. `/matrix/ssl` on the host is mounted into the container
# at the same path (`/matrix/ssl`) by default, so if that's the path you need, it would be seamless.
matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate: /matrix/ssl/config/live/<your-domain>/fullchain.pem
matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate_key: /matrix/ssl/config/live/<your-domain>/privkey.pem
matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate: /matrix/ssl/config/live/matrix.<your-domain>/fullchain.pem
matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate_key: /matrix/ssl/config/live/matrix.<your-domain>/privkey.pem
```

If your files are not in `/matrix/ssl` but in some other location, you would need to mount them into the container:


+ 51
- 0
docs/importing-postgres.md Просмотреть файл

@@ -24,3 +24,54 @@ To import, run this command (make sure to replace `<server-path-to-postgres-dump
ansible-playbook -i inventory/hosts setup.yml --extra-vars='server_path_postgres_dump=<server-path-to-postgres-dump.sql>' --tags=import-postgres

**Note**: `<server-path-to-postgres-dump.sql>` must be a file path to a Postgres dump file on the server (not on your local machine!).

## Troubleshooting

A table ownership issue can occur if you are importing from a Synapse installation which was both:

- migrated from SQLite to Postgres, and
- used a username other than 'synapse'

In this case you may run into the following error during the import task:

```
"ERROR: role \"synapse_user\" does not exist"
```

where `synapse_user` is the database username from the previous Synapse installation.

This can be verified by examining the dump for ALTER TABLE statements which set OWNER TO that username:

```Shell
$ grep "ALTER TABLE" homeserver.sql"
ALTER TABLE public.access_tokens OWNER TO synapse_user;
ALTER TABLE public.account_data OWNER TO synapse_user;
ALTER TABLE public.account_data_max_stream_id OWNER TO synapse_user;
ALTER TABLE public.account_validity OWNER TO synapse_user;
ALTER TABLE public.application_services_state OWNER TO synapse_user;
...
```

It can be worked around by changing the username to `synapse`, for example by using `sed`:

```Shell
$ sed -i "s/synapse_user/synapse/g" homeserver.sql"
```

This uses sed to perform an 'in-place' (`-i`) replacement globally (`/g`), searching for `synapse user` and replacing with `synapse` (`s/synapse_user/synapse`). If your database username was different, change `synapse_user` to that username instead.

Note that if the previous import failed with an error it may have made changes which are incompatible with re-running the import task right away; if you do so it may fail with an error such as:

```
ERROR: relation \"access_tokens\" already exists
```

In this case you can use the command suggested in the import task to clear the database before retrying the import:

```Shell
# systemctl stop matrix-postgres
# rm -rf /matrix/postgres/data/*
# systemctl start matrix-postgres
```

Once the database is clear and the ownership of the tables has been fixed in the SQL file, the import task should succeed.

+ 0
- 5
roles/matrix-base/tasks/main.yml Просмотреть файл

@@ -2,11 +2,6 @@
tags:
- always

- import_tasks: "{{ role_path }}/tasks/validate_config.yml"
when: "run_setup|bool"
tags:
- setup-all

- import_tasks: "{{ role_path }}/tasks/clean_up_old_files.yml"
when: run_setup|bool
tags:


+ 0
- 1
roles/matrix-base/tasks/validate_config.yml Просмотреть файл

@@ -1 +0,0 @@
---

+ 1
- 1
roles/matrix-bridge-mautrix-telegram/defaults/main.yml Просмотреть файл

@@ -4,7 +4,7 @@
matrix_mautrix_telegram_enabled: true

# See: https://mau.dev/tulir/mautrix-telegram/container_registry
matrix_mautrix_telegram_docker_image: "dock.mau.dev/tulir/mautrix-telegram:v0.7.2"
matrix_mautrix_telegram_docker_image: "dock.mau.dev/tulir/mautrix-telegram:v0.8.1"
matrix_mautrix_telegram_docker_image_force_pull: "{{ matrix_mautrix_telegram_docker_image.endswith(':latest') }}"

matrix_mautrix_telegram_base_path: "{{ matrix_base_data_path }}/mautrix-telegram"


+ 24
- 2
roles/matrix-bridge-mautrix-telegram/templates/config.yaml.j2 Просмотреть файл

@@ -124,8 +124,8 @@ bridge:
# Whether or not to automatically sync the Matrix room state (mostly unpuppeted displaynames)
# at startup and when creating a bridge.
sync_matrix_state: true
# Allow logging in within Matrix. If false, the only way to log in is using the out-of-Matrix
# login website (see appservice.public config section)
# Allow logging in within Matrix. If false, users can only log in using login-qr or the
# out-of-Matrix login website (see appservice.public config section)
allow_matrix_login: true
# Whether or not to bridge plaintext highlights.
# Only enable this if your displayname_template has some static part that the bridge can use to
@@ -184,6 +184,28 @@ bridge:
# Default to encryption, force-enable encryption in all portals the bridge creates
# This will cause the bridge bot to be in private chats for the encryption to work properly.
default: false
# Database for the encryption data. Currently only supports Postgres and an in-memory
# store that's persisted as a pickle.
# If set to `default`, will use the appservice postgres database
# or a pickle file if the appservice database is sqlite.
#
# Format examples:
# Pickle: pickle:///filename.pickle
# Postgres: postgres://username:password@hostname/dbname
database: default

# Whether or not to explicitly set the avatar and room name for private
# chat portal rooms. This will be implicitly enabled if encryption.default is true.
private_chat_portal_meta: false
# Whether or not the bridge should send a read receipt from the bridge bot when a message has
# been sent to Telegram.
delivery_receipts: false
# Whether or not delivery errors should be reported as messages in the Matrix room.
delivery_error_reports: false
# Set this to true to tell the bridge to re-send m.bridge events to all rooms on the next run.
# This field will automatically be changed back to false after it,
# except if the config file is not writable.
resend_bridge_info: false

# Overrides for base power levels.
initial_power_level_overrides:


+ 1
- 1
roles/matrix-synapse/defaults/main.yml Просмотреть файл

@@ -5,7 +5,7 @@ matrix_synapse_enabled: true

matrix_synapse_container_image_self_build: false

matrix_synapse_docker_image: "matrixdotorg/synapse:v1.16.0"
matrix_synapse_docker_image: "matrixdotorg/synapse:v1.17.0"
matrix_synapse_docker_image_force_pull: "{{ matrix_synapse_docker_image.endswith(':latest') }}"

matrix_synapse_base_path: "{{ matrix_base_data_path }}/synapse"


+ 31
- 4
roles/matrix-synapse/templates/synapse/homeserver.yaml.j2 Просмотреть файл

@@ -1781,12 +1781,39 @@ sso:
#template_dir: "res/templates"


# The JWT needs to contain a globally unique "sub" (subject) claim.
# JSON web token integration. The following settings can be used to make
# Synapse JSON web tokens for authentication, instead of its internal
# password database.
#
# Each JSON Web Token needs to contain a "sub" (subject) claim, which is
# used as the localpart of the mxid.
#
# Note that this is a non-standard login type and client support is
# expected to be non-existant.
#
# See https://github.com/matrix-org/synapse/blob/master/docs/jwt.md.
#
#jwt_config:
# enabled: true
# secret: "a secret"
# algorithm: "HS256"
# Uncomment the following to enable authorization using JSON web
# tokens. Defaults to false.
#
#enabled: true

# This is either the private shared secret or the public key used to
# decode the contents of the JSON web token.
#
# Required if 'enabled' is true.
#
#secret: "provided-by-your-issuer"

# The algorithm used to sign the JSON web token.
#
# Supported algorithms are listed at
# https://pyjwt.readthedocs.io/en/latest/algorithms.html
#
# Required if 'enabled' is true.
#
#algorithm: "provided-by-your-issuer"


password_config:


Загрузка…
Отмена
Сохранить