Merge branch 'master' into mx-puppet-twitter

This commit is contained in:
Slavi Pantaleev
2020-06-30 17:37:19 +03:00
18 changed files with 458 additions and 23 deletions

View File

@ -1,6 +1,6 @@
# Alternative architectures
As stated in the [Prerequisites](prerequisites.md), currently only x86_64 is supported. However, it is possible to set the target architecture, and some tools can be built on the host or other measures can be used.
As stated in the [Prerequisites](prerequisites.md), currently only `x86_64` is fully supported. However, it is possible to set the target architecture, and some tools can be built on the host or other measures can be used.
To that end add the following variable to your `vars.yaml` file:
@ -21,9 +21,6 @@ matrix_architecture: "arm32"
## Implementation details
This subsection is used for a reminder, how the different roles implement architecture differences. This is **not** aimed at the users, so one does not have to do anything based on this subsection.
For `amd64`, prebuilt images are used everywhere (because all images are available for this architecture).
On most roles [self-building](self-building.md) is used if the architecture is not `amd64`, however there are some special cases:
- `matrix-bridge-mautrix-facebook`: there is a pre-built Docker image for `arm64` as well
- `matrix-bridge-mautrix-hangouts`: there is a pre-built Docker image for `arm64` as well
- `matrix-nginx-proxy`: Certbot has a pre-built Docker image for both `arm32` and `arm64`, however tagging is used, which requires special handling.
For other architectures, components which have a prebuilt image make use of it. If the component is not available for the specific architecture, [self-building](self-building.md) will be used. Not all components support self-building though, so your mileage may vary.

View File

@ -0,0 +1,36 @@
# Setting up mx-puppet-instagram (optional)
The playbook can install and configure
[mx-puppet-instagram](https://github.com/Sorunome/mx-puppet-instagram) for you.
This allows you to bridge Instagram DirectMessages into Matrix.
To enable the [Instagram](https://www.instagram.com/) bridge just use the following
playbook configuration:
```yaml
matrix_mx_puppet_instagram_enabled: true
```
## Usage
Once the bot is enabled, you need to start a chat with `Instagram Puppet Bridge` with
the handle `@_instagrampuppet_bot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base
domain, not the `matrix.` domain).
Send `link <username> <password>` to the bridge bot to link your instagram account.
The `list` commands shows which accounts are linked and which `puppetId` is associated.
For double-puppeting, you probably want to issue these commands:
- `settype $puppetId puppet` to enable puppeting for the link (instead of relaying)
- `setautoinvite $puppetId 1` to automatically invite you to chats
- `setmatrixtoken $accessToken` to set the access token to enable puppeting from the other side (the "double" in double puppeting)
If you are linking only one Instagram account, your `$puppetId` is probably 1, but use the `list` command find out.
The `help` command shows which commands are available, though at the time of writing, not every command is fully implemented.

View File

@ -2,22 +2,23 @@
**Caution: self-building does not have to be used on its own. See the [Alternative Architectures](alternative-architectures.md) page.**
The playbook supports the self-building of some of its components. This may be useful for architectures besides x86_64, which have no Docker images right now (e g. the armv7 for the Raspberry Pi). Some playbook roles have been updated, so they build the necessary image on the host. It needs more space, as some build tools need to be present (like Java, for ma1sd).
The playbook supports the self-building of various components, which don't have a container image for your architecture. For `amd64`, self-building is not required.
To use these modification there is a variable that needs to be switched to enable this functionality. Add this to your `vars.yaml` file:
```yaml
matrix_container_images_self_build: true
```
Setting that variable will self-build every role which supports self-building. Self-building can be set on a per-role basis as well.
For other architectures (e.g. `arm32`, `arm64`), ready-made container images are used when available. If there's no ready-made image for a specific component and said component supports self-building, an image will be built on the host. Building images like this takes more time and resources (some build tools need to get installed by the playbook to assist building).
To make use of self-building, you don't need to do anything besides change your architecture variable (e.g. `matrix_architecture: arm64`). If a component has an image for the specified architecture, the playbook will use it. If not, it will build the image.
Note that **not all components support self-building yet**.
List of roles where self-building the Docker image is currently possible:
- `matrix-synapse`
- `matrix-riot-web`
- `matrix-coturn`
- `matrix-ma1sd`
- `matrix-mailer`
- `matrix-mautrix-facebook`
- `matrix-mautrix-hangouts`
- `matrix-mx-puppet-skype`
- `matrix-bridge-mautrix-facebook`
- `matrix-bridge-mautrix-hangouts`
- `matrix-bridge-mx-puppet-skype`
Adding self-building support to other roles is welcome. Feel free to contribute!
If you'd like **to force self-building** even if an image is available for your architecture, look into the `matrix_*_self_build` variables provided by individual roles.