You are not logged in.

Pages: 1

#1 2022-04-21 16:46:57

Morta
Member
Registered: 2019-07-07
Posts: 655

Mautrix-Signal bridge

Hi I want to start mautrix-signal bridge

I get following error:

[morta@5erver webapps]$ journalctl -xeu mautrix-signal
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/mautrix_signal/__main__.py", line 146, in <module>
Apr 21 18:36:42 5erver python[3021134]:     SignalBridge().run()
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/mautrix/util/program.py", line 91, in run
Apr 21 18:36:42 5erver python[3021134]:     self._prepare()
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/mautrix/util/program.py", line 97, in _prepare
Apr 21 18:36:42 5erver python[3021134]:     self.preinit()
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/mautrix/bridge/bridge.py", line 103, in preinit
Apr 21 18:36:42 5erver python[3021134]:     super().preinit()
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/mautrix/util/program.py", line 117, in preinit
Apr 21 18:36:42 5erver python[3021134]:     self.prepare_config()
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/mautrix/bridge/bridge.py", line 120, in prepare_config
Apr 21 18:36:42 5erver python[3021134]:     self.load_and_update_config()
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/mautrix/util/program.py", line 156, in load_and_update_config
Apr 21 18:36:42 5erver python[3021134]:     self.config.update(save=not self.args.no_update)
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/mautrix/util/config/base.py", line 72, in update
Apr 21 18:36:42 5erver python[3021134]:     base = self.load_base()
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/mautrix/util/config/file.py", line 45, in load_base
Apr 21 18:36:42 5erver python[3021134]:     return RecursiveDict(yaml.load(stream), CommentedMap)
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/ruamel/yaml/main.py", line 434, in load
Apr 21 18:36:42 5erver python[3021134]:     return constructor.get_single_data()
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/ruamel/yaml/constructor.py", line 119, in get_single_data
Apr 21 18:36:42 5erver python[3021134]:     node = self.composer.get_single_node()
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/ruamel/yaml/composer.py", line 76, in get_single_node
Apr 21 18:36:42 5erver python[3021134]:     document = self.compose_document()
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/ruamel/yaml/composer.py", line 99, in compose_document
Apr 21 18:36:42 5erver python[3021134]:     node = self.compose_node(None, None)
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/ruamel/yaml/composer.py", line 143, in compose_node
Apr 21 18:36:42 5erver python[3021134]:     node = self.compose_mapping_node(anchor)
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/ruamel/yaml/composer.py", line 216, in compose_mapping_node
Apr 21 18:36:42 5erver python[3021134]:     while not self.parser.check_event(MappingEndEvent):
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/ruamel/yaml/parser.py", line 146, in check_event
Apr 21 18:36:42 5erver python[3021134]:     self.current_event = self.state()
Apr 21 18:36:42 5erver python[3021134]:   File "/usr/lib/python3.10/site-packages/ruamel/yaml/parser.py", line 612, in parse_block_mapping_key
Apr 21 18:36:42 5erver python[3021134]:     raise ParserError(
Apr 21 18:36:42 5erver python[3021134]: ruamel.yaml.parser.ParserError: while parsing a block mapping
Apr 21 18:36:42 5erver python[3021134]:   in "/usr/share/mautrix-signal/example-config.yaml", line 2, column 1
Apr 21 18:36:42 5erver python[3021134]: expected <block end>, but found '<block mapping start>'
Apr 21 18:36:42 5erver python[3021134]:   in "/usr/share/mautrix-signal/example-config.yaml", line 20, column 3
Apr 21 18:36:42 5erver systemd[1]: mautrix-signal.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ An ExecStart= process belonging to unit mautrix-signal.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 1.
Apr 21 18:36:42 5erver systemd[1]: mautrix-signal.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit mautrix-signal.service has entered the 'failed' state with result 'exit-code'.

My registration.yaml is empty

My config-example.yaml looks

# Homeserver details
homeserver:
    # The address that this appservice can use to connect to the homeserver.
    address: https://chat.xxx.ch
    # The domain of the homeserver (for MXIDs, etc).
    domain: chat.xxx.ch
    # Whether or not to verify the SSL certificate of the homeserver.
    # Only applies if address starts with https://
    verify_ssl: true
    asmux: false
    # Number of retries for all HTTP requests if the homeserver isn't reachable.
    http_retry_count: 4
    # The URL to push real-time bridge status to.
    # If set, the bridge will make POST requests to this URL whenever a user's Signal connection state changes.
    # The bridge will use the appservice as_token to authorize requests.
    status_endpoint: null
    # Endpoint for reporting per-message status.
    message_send_checkpoint_endpoint: null
    # Maximum number of simultaneous HTTP connections to the homeserver.
  connection_limit: 100

# Application service host/registration related details
# Changing these values requires regeneration of the registration.
appservice:
    # The address that the homeserver can use to connect to this appservice.
    address: http://192.168.1.100:29328
    # When using https:// the TLS certificate and key files for the address.
    tls_cert: false
    tls_key: false

    # The hostname and port where this appservice should listen.
    hostname: 192.168.1.100
    port: 29328
    # The maximum body size of appservice API requests (from the homeserver) in mebibytes
    # Usually 1 is enough, but on high-traffic bridges you might need to increase this to avoid 413s
    max_body_size: 1

    # The full URI to the database. SQLite and Postgres are supported.
    # However, SQLite support is extremely experimental and should not be used.
    # Format examples:
    #   SQLite:   sqlite:///filename.db
    #   Postgres: postgres://username:password@hostname/dbname
    database: postgres://admin:PWD@localhost/matrix
    # Additional arguments for asyncpg.create_pool() or sqlite3.connect()
    # https://magicstack.github.io/asyncpg/current/api/index.html#asyncpg.pool.create_pool
    # https://docs.python.org/3/library/sqlite3.html#sqlite3.connect
    # For sqlite, min_size is used as the connection thread pool size and max_size is ignored.
    database_opts:
        min_size: 5
        max_size: 10

    # The unique ID of this appservice.
    id: signal
    # Username of the appservice bot.
    bot_username: signalbot
    # Display name and avatar for bot. Set to "remove" to remove display name/avatar, leave empty
    # to leave display name/avatar as-is.
    bot_displayname: Signal bridge bot
    bot_avatar: mxc://maunium.net/wPJgTQbZOtpBFmDNkiNEMDUp

    # Whether or not to receive ephemeral events via appservice transactions.
    # Requires MSC2409 support (i.e. Synapse 1.22+).
    # You should disable bridge -> sync_with_custom_puppets when this is enabled.
    ephemeral_events: false

    # Authentication tokens for AS <-> HS communication. Autogenerated; do not modify.
    as_token: "This value is generated when generating the registration"
    hs_token: "This value is generated when generating the registration"

# Prometheus telemetry config. Requires prometheus-client to be installed.
metrics:
    enabled: false
    listen_port: 8000

# Manhole config.
manhole:
    # Whether or not opening the manhole is allowed.
    enabled: false
    # The path for the unix socket.
    path: /var/tmp/mautrix-signal.manhole
    # The list of UIDs who can be added to the whitelist.
    # If empty, any UIDs can be specified in the open-manhole command.
    whitelist:
    - 0

signal:
    # Path to signald unix socket
    socket_path: /var/run/signald/signald.sock
    # Directory for temp files when sending files to Signal. This should be an
    # absolute path that signald can read. For attachments in the other direction,
    # make sure signald is configured to use an absolute path as the data directory.
    outgoing_attachment_dir: /tmp
    # Directory where signald stores avatars for groups.
    avatar_dir: /var/lib/signald/avatars
    # Directory where signald stores auth data. Used to delete data when logging out.
    data_dir: /var/lib/signald/data
    # Whether or not unknown signald accounts should be deleted when the bridge is started.
    # When this is enabled, any UserInUse errors should be resolved by restarting the bridge.
    delete_unknown_accounts_on_start: false
    # Whether or not message attachments should be removed from disk after they're bridged.
    remove_file_after_handling: true
    # Whether or not users can register a primary device
    registration_enabled: true
    # Whether or not to enable disappearing messages in groups. If enabled, then the expiration
    # time of the messages will be determined by the first users to read the message, rather
    # than individually. If the bridge has a single user, this can be turned on safely.
    enable_disappearing_messages_in_groups: false

# Bridge config
bridge:
    # Localpart template of MXIDs for Signal users.
    # {userid} is replaced with an identifier for the Signal user.
    username_template: "signal_{userid}"
    # Displayname template for Signal users.
    # {displayname} is replaced with the displayname of the Signal user, which is the first
    # available variable in displayname_preference. The variables in displayname_preference
    # can also be used here directly.
    displayname_template: "{displayname} (Signal)"
    # Whether or not contact list displaynames should be used.
    # Possible values: disallow, allow, prefer
    #
    # Multi-user instances are recommended to disallow contact list names, as otherwise there can
    # be conflicts between names from different users' contact lists.
    contact_list_names: disallow
    # Available variables: full_name, first_name, last_name, phone, uuid
    displayname_preference:
    - full_name
    - phone

    # Whether or not to create portals for all groups on login/connect.
    autocreate_group_portal: true
    # Whether or not to create portals for all contacts on login/connect.
    autocreate_contact_portal: false
    # Whether or not to use /sync to get read receipts and typing notifications
    # when double puppeting is enabled
    sync_with_custom_puppets: true
    # Whether or not to update the m.direct account data event when double puppeting is enabled.
    # Note that updating the m.direct event is not atomic (except with mautrix-asmux)
    # and is therefore prone to race conditions.
    sync_direct_chat_list: false
    # Allow using double puppeting from any server with a valid client .well-known file.
    double_puppet_allow_discovery: false
    # Servers to allow double puppeting from, even if double_puppet_allow_discovery is false.
    double_puppet_server_map:
        example.com: https://chat.joelmueller.ch
    # Shared secret for https://github.com/devture/matrix-synapse-shared-secret-auth
    #
    # If set, custom puppets will be enabled automatically for local users
    # instead of users having to find an access token and run `login-matrix`
    # manually.
    # If using this for other servers than the bridge's server,
    # you must also set the URL in the double_puppet_server_map.
    login_shared_secret_map:
        example.com: false
    # Whether or not created rooms should have federation enabled.
    # If false, created portal rooms will never be federated.
    federate_rooms: true
    # End-to-bridge encryption support options. You must install the e2be optional dependency for
    # this to work. See https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html
    encryption:
        # Allow encryption, work in group chat rooms with e2ee enabled
        allow: false
        # 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
        # Options for automatic key sharing.
        key_sharing:
            # Enable key sharing? If enabled, key requests for rooms where users are in will be fulfilled.
            # You must use a client that supports requesting keys from other users to use this feature.
            allow: false
            # Require the requesting device to have a valid cross-signing signature?
            # This doesn't require that the bridge has verified the device, only that the user has verified it.
            # Not yet implemented.
            require_cross_signing: false
            # Require devices to be verified by the bridge?
            # Verification by the bridge is not yet implemented.
            require_verification: true
    # 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 Signal. This let's you check manually whether the bridge is receiving your
    # messages.
    # Note that this is not related to Signal delivery receipts.
    delivery_receipts: false
    # Whether or not delivery errors should be reported as messages in the Matrix room. (not yet implemented)
    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
    # Interval at which to resync contacts (in seconds).
    periodic_sync: 0

    # Provisioning API part of the web server for automated portal creation and fetching information.
    # Used by things like mautrix-manager (https://github.com/tulir/mautrix-manager).
    provisioning:
        # Whether or not the provisioning API should be enabled.
        enabled: true
        # The prefix to use in the provisioning API endpoints.
        prefix: /_matrix/provision/v1
        # The shared secret to authorize users of the API.
        # Set to "generate" to generate and save a new token.
        shared_secret: generate

    # The prefix for commands. Only required in non-management rooms.
    command_prefix: "!signal"

    # Messages sent upon joining a management room.
    # Markdown is supported. The defaults are listed below.
    management_room_text:
        # Sent when joining a room.
        welcome: "Hello, I'm a Signal bridge bot."
        # Sent when joining a management room and the user is already logged in.
        welcome_connected: "Use `help` for help."
        # Sent when joining a management room and the user is not logged in.
        welcome_unconnected: "Use `help` for help or `register` to log in."
        # Optional extra text sent when joining a management room.
        additional_help: ""

    # Send each message separately (for readability in some clients)
    management_room_multiple_messages: false

    # Permissions for using the bridge.
    # Permitted values:
    #      relay - Allowed to be relayed through the bridge, no access to commands.
    #       user - Use the bridge with puppeting.
    #      admin - Use and administrate the bridge.
    # Permitted keys:
    #        * - All Matrix users
    #   domain - All users on that homeserver
    #     mxid - Specific user
    permissions:
        "*": "relay"
        "example.com": "user"
        "@admin:example.com": "admin"

    relay:
        # Whether relay mode should be allowed. If allowed, `!signal set-relay` can be used to turn any
        # authenticated user into a relaybot for that chat.
        enabled: false
        # The formats to use when sending messages to Signal via a relay user.
        #
        # Available variables:
        #   $sender_displayname - The display name of the sender (e.g. Example User)
        #   $sender_username    - The username (Matrix ID localpart) of the sender (e.g. exampleuser)
        #   $sender_mxid        - The Matrix ID of the sender (e.g. @exampleuser:example.com)
        #   $message            - The message content
        message_formats:
            m.text: '$sender_displayname: $message'
            m.notice: '$sender_displayname: $message'
            m.emote: '* $sender_displayname $message'
            m.file: '$sender_displayname sent a file'
            m.image: '$sender_displayname sent an image'
            m.audio: '$sender_displayname sent an audio file'
            m.video: '$sender_displayname sent a video'
            m.location: '$sender_displayname sent a location'

# Python logging configuration.
#
# See section 16.7.2 of the Python documentation for more info:
# https://docs.python.org/3.6/library/logging.config.html#configuration-dictionary-schema
logging:
    version: 1
    formatters:
        colored:
            (): mautrix_signal.util.ColorFormatter
            format: "[%(asctime)s] [%(levelname)s@%(name)s] %(message)s"
        normal:
            format: "[%(asctime)s] [%(levelname)s@%(name)s] %(message)s"
    handlers:
        file:
            class: logging.handlers.RotatingFileHandler
            formatter: normal
            filename: ./mautrix-signal.log
            maxBytes: 10485760
            backupCount: 10
        console:
            class: logging.StreamHandler
            formatter: colored
    loggers:
        mau:
            level: DEBUG
        aiohttp:
            level: INFO
    root:
        level: DEBUG

What is wrong?

Offline

#2 2022-04-21 16:50:21

Morta
Member
Registered: 2019-07-07
Posts: 655

Re: Mautrix-Signal bridge

I tried also

sudo ansible-playbook -i /usr/share/mautrix-signal example-config.yaml --tags=setup-all
[WARNING]:  * Failed to parse /usr/share/mautrix-signal/example-config.yaml with auto plugin: We were unable to read either as JSON nor YAML, these are the errors we got from each: JSON: Expecting value: line 1 column 1 (char 0)  Syntax
Error while loading YAML.   did not find expected key  The error appears to be in '/usr/share/mautrix-signal/example-config.yaml': line 20, column 3, but may be elsewhere in the file depending on the exact syntax problem.  The offending
line appears to be:      # Maximum number of simultaneous HTTP connections to the homeserver.   connection_limit: 100   ^ here
[WARNING]:  * Failed to parse /usr/share/mautrix-signal/example-config.yaml with yaml plugin: We were unable to read either as JSON nor YAML, these are the errors we got from each: JSON: Expecting value: line 1 column 1 (char 0)  Syntax
Error while loading YAML.   did not find expected key  The error appears to be in '/usr/share/mautrix-signal/example-config.yaml': line 20, column 3, but may be elsewhere in the file depending on the exact syntax problem.  The offending
line appears to be:      # Maximum number of simultaneous HTTP connections to the homeserver.   connection_limit: 100   ^ here
[WARNING]:  * Failed to parse /usr/share/mautrix-signal/example-config.yaml with ini plugin: Invalid host pattern 'homeserver:' supplied, ending in ':' is not allowed, this character is reserved to provide a port.
[WARNING]: Unable to parse /usr/share/mautrix-signal/example-config.yaml as an inventory source
[WARNING]: Unable to parse /usr/share/mautrix-signal as an inventory source
[WARNING]: No inventory was parsed, only implicit localhost is available
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
ERROR! We were unable to read either as JSON nor YAML, these are the errors we got from each:
JSON: Expecting value: line 1 column 1 (char 0)

Syntax Error while loading YAML.
  did not find expected key

The error appears to be in '/usr/share/mautrix-signal/example-config.yaml': line 20, column 3, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

    # Maximum number of simultaneous HTTP connections to the homeserver.
  connection_limit: 100
  ^ here

Offline

#3 2022-04-21 17:34:54

ayekat
Member
Registered: 2011-01-17
Posts: 1,589

Re: Mautrix-Signal bridge

Not quite sure if this matters, but your connection_limit line (the line 20 it's referring to) is not indented the same way as all the other lines above. Potentially this then trips up the YAML parser.

That being said, you try to run an Ansible playbook, but that example-config.yml doesn't look like a playbook. Are you sure it's supposed to be done like that? (I don't know Mautrix-Signal at all)

pkgs │ hacks │ cfg │ blag

Offline

#4 2022-04-21 17:46:01

Morta
Member
Registered: 2019-07-07
Posts: 655

Re: Mautrix-Signal bridge

ayekat wrote:

Not quite sure if this matters, but your connection_limit line (the line 20 it's referring to) is not indented the same way as all the other lines above. Potentially this then trips up the YAML parser.

Ok i will fix it. Thanks

That being said, you try to run an Ansible playbook, but that example-config.yml doesn't look like a playbook. Are you sure it's supposed to be done like that? (I don't know Mautrix-Signal at all)


No I‘m not shure. I try to get work the mautrix bridge wit my matrix server synapse and I fail instantly.

So why?

I did not found any tutorial which works.

Last edited by Morta (2022-04-21 17:49:46)

Offline

#5 2022-04-21 20:25:17

ayekat
Member
Registered: 2011-01-17
Posts: 1,589

Re: Mautrix-Signal bridge

So did you fix the indentation issue? Did it change anything?

What resource/documentation are you using to try to make it work? Where did you see the thing with `ansible-playbook`?
The upstream documentation appears to assume you want to run this thing inside Docker.

pkgs │ hacks │ cfg │ blag

Offline

#6 2022-04-22 04:37:58

Morta
Member
Registered: 2019-07-07
Posts: 655

Re: Mautrix-Signal bridge

ayekat wrote:

So did you fix the indentation issue? Did it change anything?

What resource/documentation are you using to try to make it work? Where did you see the thing with `ansible-playbook`?
The upstream documentation appears to assume you want to run this thing inside Docker.

I will test in the afternoon. No I run as systemd service with Postgres database.

I read that I have adjust registration.yaml too

Offline

#7 2022-04-22 17:32:04

Morta
Member
Registered: 2019-07-07
Posts: 655

Re: Mautrix-Signal bridge

pr 22 19:24:28 5erver python[3306740]: Failed to create tempfile to write updated config to disk: [Errno 13] Permission denied: '/etc/mautrix-signal/tmp3_qmpw7f.yaml'
Apr 22 19:24:28 5erver python[3306740]: [2022-04-22 19:24:28,547] [CRITICAL@mau.init] Configuration error: homeserver.address not configured

I got following errors. I don't understand why homeserver address is faulty.

Offline

#8 2022-04-22 18:50:35

ayekat
Member
Registered: 2011-01-17
Posts: 1,589

Re: Mautrix-Signal bridge

Again, please specify which instructions you are following, and what commands exactly you are running.

As that looks like journal logs, is that a service (if so, which one)?
Is its unit file provided by a package (if so, which package?) or did you write it yourself (if so, please paste the content).

pkgs │ hacks │ cfg │ blag

Offline

#9 2022-04-23 10:41:20

Morta
Member
Registered: 2019-07-07
Posts: 655

Re: Mautrix-Signal bridge

I run mautrix-bridge from AUR and run it as systemd service. I have no instruction. I adjust only example-config.yaml

[Service]
User=mautrix-signal
WorkingDirectory=~
ExecStart=python -m mautrix_signal -b /usr/share/mautrix-signal/example-config.yaml -c /etc/mautrix-signal/config.yaml -r /etc/mautrix-signal/registration.yaml

Restart=on-failure
RestartSec=30s

# ProtectSystem=on
# ProtectHome=on

[Install]
WantedBy=multi-user.target

synapse is running under https://chat.joelmueller.ch

config.yaml

# Homeserver details
homeserver:
    # The address that this appservice can use to connect to the homeserver.
    address: https://example.com
    # The domain of the homeserver (for MXIDs, etc).
    domain: example.com
    # Whether or not to verify the SSL certificate of the homeserver.
    # Only applies if address starts with https://
    verify_ssl: true
    asmux: false
    # Number of retries for all HTTP requests if the homeserver isn't reachable.
    http_retry_count: 4
    # The URL to push real-time bridge status to.
    # If set, the bridge will make POST requests to this URL whenever a user's Signal connection state changes.
    # The bridge will use the appservice as_token to authorize requests.
    status_endpoint: null
    # Endpoint for reporting per-message status.
    message_send_checkpoint_endpoint: null
    # Maximum number of simultaneous HTTP connections to the homeserver.
    connection_limit: 100

# Application service host/registration related details
# Changing these values requires regeneration of the registration.
appservice:
    # The address that the homeserver can use to connect to this appservice.
    address: http://localhost:29328
    # When using https:// the TLS certificate and key files for the address.
    tls_cert: false
    tls_key: false

    # The hostname and port where this appservice should listen.
    hostname: 0.0.0.0
    port: 29328
    # The maximum body size of appservice API requests (from the homeserver) in mebibytes
    # Usually 1 is enough, but on high-traffic bridges you might need to increase this to avoid 413s
    max_body_size: 1

    # The full URI to the database. SQLite and Postgres are supported.
    # However, SQLite support is extremely experimental and should not be used.
    # Format examples:
    #   SQLite:   sqlite:///filename.db
    #   Postgres: postgres://username:password@hostname/dbname
    database: postgres://username:password@hostname/db
    # Additional arguments for asyncpg.create_pool() or sqlite3.connect()
    # https://magicstack.github.io/asyncpg/current/api/index.html#asyncpg.pool.create_pool
    # https://docs.python.org/3/library/sqlite3.html#sqlite3.connect
    # For sqlite, min_size is used as the connection thread pool size and max_size is ignored.
    database_opts:
        min_size: 5
        max_size: 10

    # The unique ID of this appservice.
    id: signal
    # Username of the appservice bot.
    bot_username: signalbot
    # Display name and avatar for bot. Set to "remove" to remove display name/avatar, leave empty
    # to leave display name/avatar as-is.
    bot_displayname: Signal bridge bot
    bot_avatar: mxc://maunium.net/wPJgTQbZOtpBFmDNkiNEMDUp

    # Whether or not to receive ephemeral events via appservice transactions.
    # Requires MSC2409 support (i.e. Synapse 1.22+).
    # You should disable bridge -> sync_with_custom_puppets when this is enabled.
    ephemeral_events: false

    # Authentication tokens for AS <-> HS communication. Autogenerated; do not modify.
    as_token: "This value is generated when generating the registration"
    hs_token: "This value is generated when generating the registration"

# Prometheus telemetry config. Requires prometheus-client to be installed.
metrics:
    enabled: false
    listen_port: 8000

# Manhole config.
manhole:
    # Whether or not opening the manhole is allowed.
    enabled: false
    # The path for the unix socket.
    path: /var/tmp/mautrix-signal.manhole
    # The list of UIDs who can be added to the whitelist.
    # If empty, any UIDs can be specified in the open-manhole command.
    whitelist:
    - 0

signal:
    # Path to signald unix socket
    socket_path: /var/run/signald/signald.sock
    # Directory for temp files when sending files to Signal. This should be an
    # absolute path that signald can read. For attachments in the other direction,
    # make sure signald is configured to use an absolute path as the data directory.
    outgoing_attachment_dir: /tmp
    # Directory where signald stores avatars for groups.
    avatar_dir: /var/lib/signald/avatars
    # Directory where signald stores auth data. Used to delete data when logging out.
    data_dir: /var/lib/signald/data
    # Whether or not unknown signald accounts should be deleted when the bridge is started.
    # When this is enabled, any UserInUse errors should be resolved by restarting the bridge.
    delete_unknown_accounts_on_start: false
    # Whether or not message attachments should be removed from disk after they're bridged.
    remove_file_after_handling: true
    # Whether or not users can register a primary device
    registration_enabled: true
    # Whether or not to enable disappearing messages in groups. If enabled, then the expiration
    # time of the messages will be determined by the first users to read the message, rather
    # than individually. If the bridge has a single user, this can be turned on safely.
    enable_disappearing_messages_in_groups: false

# Bridge config
bridge:
    # Localpart template of MXIDs for Signal users.
    # {userid} is replaced with an identifier for the Signal user.
    username_template: "signal_{userid}"
    # Displayname template for Signal users.
    # {displayname} is replaced with the displayname of the Signal user, which is the first
    # available variable in displayname_preference. The variables in displayname_preference
    # can also be used here directly.
    displayname_template: "{displayname} (Signal)"
    # Whether or not contact list displaynames should be used.
    # Possible values: disallow, allow, prefer
    #
    # Multi-user instances are recommended to disallow contact list names, as otherwise there can
    # be conflicts between names from different users' contact lists.
    contact_list_names: disallow
    # Available variables: full_name, first_name, last_name, phone, uuid
    displayname_preference:
    - full_name
    - phone

    # Whether or not to create portals for all groups on login/connect.
    autocreate_group_portal: true
    # Whether or not to create portals for all contacts on login/connect.
    autocreate_contact_portal: false
    # Whether or not to use /sync to get read receipts and typing notifications
    # when double puppeting is enabled
    sync_with_custom_puppets: true
    # Whether or not to update the m.direct account data event when double puppeting is enabled.
    # Note that updating the m.direct event is not atomic (except with mautrix-asmux)
    # and is therefore prone to race conditions.
    sync_direct_chat_list: false
    # Allow using double puppeting from any server with a valid client .well-known file.
    double_puppet_allow_discovery: false
    # Servers to allow double puppeting from, even if double_puppet_allow_discovery is false.
    double_puppet_server_map:
        example.com: https://example.com
    # Shared secret for https://github.com/devture/matrix-synapse-shared-secret-auth
    #
    # If set, custom puppets will be enabled automatically for local users
    # instead of users having to find an access token and run `login-matrix`
    # manually.
    # If using this for other servers than the bridge's server,
    # you must also set the URL in the double_puppet_server_map.
    login_shared_secret_map:
        example.com: foo
    # Whether or not created rooms should have federation enabled.
    # If false, created portal rooms will never be federated.
    federate_rooms: true
    # End-to-bridge encryption support options. You must install the e2be optional dependency for
    # this to work. See https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html
    encryption:
        # Allow encryption, work in group chat rooms with e2ee enabled
        allow: false
        # 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
        # Options for automatic key sharing.
        key_sharing:
            # Enable key sharing? If enabled, key requests for rooms where users are in will be fulfilled.
            # You must use a client that supports requesting keys from other users to use this feature.
            allow: false
            # Require the requesting device to have a valid cross-signing signature?
            # This doesn't require that the bridge has verified the device, only that the user has verified it.
            # Not yet implemented.
            require_cross_signing: false
            # Require devices to be verified by the bridge?
            # Verification by the bridge is not yet implemented.
            require_verification: true
    # 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 Signal. This let's you check manually whether the bridge is receiving your
    # messages.
    # Note that this is not related to Signal delivery receipts.
    delivery_receipts: false
    # Whether or not delivery errors should be reported as messages in the Matrix room. (not yet implemented)
    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
    # Interval at which to resync contacts (in seconds).
    periodic_sync: 0

    # Provisioning API part of the web server for automated portal creation and fetching information.
    # Used by things like mautrix-manager (https://github.com/tulir/mautrix-manager).
    provisioning:
        # Whether or not the provisioning API should be enabled.
        enabled: true
        # The prefix to use in the provisioning API endpoints.
        prefix: /_matrix/provision/v1
        # The shared secret to authorize users of the API.
        # Set to "generate" to generate and save a new token.
        shared_secret: generate

    # The prefix for commands. Only required in non-management rooms.
    command_prefix: "!signal"

    # Messages sent upon joining a management room.
    # Markdown is supported. The defaults are listed below.
    management_room_text:
        # Sent when joining a room.
        welcome: "Hello, I'm a Signal bridge bot."
        # Sent when joining a management room and the user is already logged in.
        welcome_connected: "Use `help` for help."
        # Sent when joining a management room and the user is not logged in.
        welcome_unconnected: "Use `help` for help or `register` to log in."
        # Optional extra text sent when joining a management room.
        additional_help: ""

    # Send each message separately (for readability in some clients)
    management_room_multiple_messages: false

    # Permissions for using the bridge.
    # Permitted values:
    #      relay - Allowed to be relayed through the bridge, no access to commands.
    #       user - Use the bridge with puppeting.
    #      admin - Use and administrate the bridge.
    # Permitted keys:
    #        * - All Matrix users
    #   domain - All users on that homeserver
    #     mxid - Specific user
    permissions:
        "*": "relay"
        "example.com": "user"
        "@admin:example.com": "admin"

    relay:
        # Whether relay mode should be allowed. If allowed, `!signal set-relay` can be used to turn any
        # authenticated user into a relaybot for that chat.
        enabled: false
        # The formats to use when sending messages to Signal via a relay user.
        #
        # Available variables:
        #   $sender_displayname - The display name of the sender (e.g. Example User)
        #   $sender_username    - The username (Matrix ID localpart) of the sender (e.g. exampleuser)
        #   $sender_mxid        - The Matrix ID of the sender (e.g. @exampleuser:example.com)
        #   $message            - The message content
        message_formats:
            m.text: '$sender_displayname: $message'
            m.notice: '$sender_displayname: $message'
            m.emote: '* $sender_displayname $message'
            m.file: '$sender_displayname sent a file'
            m.image: '$sender_displayname sent an image'
            m.audio: '$sender_displayname sent an audio file'
            m.video: '$sender_displayname sent a video'
            m.location: '$sender_displayname sent a location'

# Python logging configuration.
#
# See section 16.7.2 of the Python documentation for more info:
# https://docs.python.org/3.6/library/logging.config.html#configuration-dictionary-schema
logging:
    version: 1
    formatters:
        colored:
            (): mautrix_signal.util.ColorFormatter
            format: "[%(asctime)s] [%(levelname)s@%(name)s] %(message)s"
        normal:
            format: "[%(asctime)s] [%(levelname)s@%(name)s] %(message)s"
    handlers:
        file:
            class: logging.handlers.RotatingFileHandler
            formatter: normal
            filename: ./mautrix-signal.log
            maxBytes: 10485760
            backupCount: 10
        console:
            class: logging.StreamHandler
            formatter: colored
    loggers:
        mau:
            level: DEBUG
        aiohttp:
            level: INFO
    root:
        level: DEBUG
        handlers: [file, console]

registration.yaml is empty

and example-config.yaml looks like

cat example-config.yaml 
# Homeserver details
homeserver:
    # The address that this appservice can use to connect to the homeserver.
    address: https://chat.joelmueller.ch
    # The domain of the homeserver (for MXIDs, etc).
    domain: chat.joelmueller.ch
    # Whether or not to verify the SSL certificate of the homeserver.
    # Only applies if address starts with https://
    verify_ssl: true
    asmux: false
    # Number of retries for all HTTP requests if the homeserver isn't reachable.
    http_retry_count: 4
    # The URL to push real-time bridge status to.
    # If set, the bridge will make POST requests to this URL whenever a user's Signal connection state changes.
    # The bridge will use the appservice as_token to authorize requests.
    status_endpoint: null
    # Endpoint for reporting per-message status.
    message_send_checkpoint_endpoint: null
    # Maximum number of simultaneous HTTP connections to the homeserver.
    connection_limit: 100

# Application service host/registration related details
# Changing these values requires regeneration of the registration.
appservice:
    # The address that the homeserver can use to connect to this appservice.
    address: http://192.168.1.100:29328
    # When using https:// the TLS certificate and key files for the address.
    tls_cert: false
    tls_key: false

    # The hostname and port where this appservice should listen.
    hostname: 192.168.1.100
    port: 29328
    # The maximum body size of appservice API requests (from the homeserver) in mebibytes
    # Usually 1 is enough, but on high-traffic bridges you might need to increase this to avoid 413s
    max_body_size: 1

    # The full URI to the database. SQLite and Postgres are supported.
    # However, SQLite support is extremely experimental and should not be used.
    # Format examples:
    #   SQLite:   sqlite:///filename.db
    #   Postgres: postgres://username:password@hostname/dbname
    database: postgres://admin:PWD@localhost/matrix
    # Additional arguments for asyncpg.create_pool() or sqlite3.connect()
    # https://magicstack.github.io/asyncpg/current/api/index.html#asyncpg.pool.create_pool
    # https://docs.python.org/3/library/sqlite3.html#sqlite3.connect
    # For sqlite, min_size is used as the connection thread pool size and max_size is ignored.
    database_opts:
        min_size: 5
        max_size: 10

    # The unique ID of this appservice.
    id: signal
    # Username of the appservice bot.
    bot_username: signalbot
    # Display name and avatar for bot. Set to "remove" to remove display name/avatar, leave empty
    # to leave display name/avatar as-is.
    bot_displayname: Signal bridge bot
    bot_avatar: mxc://maunium.net/wPJgTQbZOtpBFmDNkiNEMDUp

    # Whether or not to receive ephemeral events via appservice transactions.
    # Requires MSC2409 support (i.e. Synapse 1.22+).
    # You should disable bridge -> sync_with_custom_puppets when this is enabled.
    ephemeral_events: false

    # Authentication tokens for AS <-> HS communication. Autogenerated; do not modify.
    as_token: "This value is generated when generating the registration"
    hs_token: "This value is generated when generating the registration"

# Prometheus telemetry config. Requires prometheus-client to be installed.
metrics:
    enabled: false
    listen_port: 8000

# Manhole config.
manhole:
    # Whether or not opening the manhole is allowed.
    enabled: false
    # The path for the unix socket.
    path: /var/tmp/mautrix-signal.manhole
    # The list of UIDs who can be added to the whitelist.
    # If empty, any UIDs can be specified in the open-manhole command.
    whitelist:
    - 0

signal:
    # Path to signald unix socket
    socket_path: /var/run/signald/signald.sock
    # Directory for temp files when sending files to Signal. This should be an
    # absolute path that signald can read. For attachments in the other direction,
    # make sure signald is configured to use an absolute path as the data directory.
    outgoing_attachment_dir: /tmp
    # Directory where signald stores avatars for groups.
    avatar_dir: /var/lib/signald/avatars
    # Directory where signald stores auth data. Used to delete data when logging out.
    data_dir: /var/lib/signald/data
    # Whether or not unknown signald accounts should be deleted when the bridge is started.
    # When this is enabled, any UserInUse errors should be resolved by restarting the bridge.
    delete_unknown_accounts_on_start: false
    # Whether or not message attachments should be removed from disk after they're bridged.
    remove_file_after_handling: true
    # Whether or not users can register a primary device
    registration_enabled: true
    # Whether or not to enable disappearing messages in groups. If enabled, then the expiration
    # time of the messages will be determined by the first users to read the message, rather
    # than individually. If the bridge has a single user, this can be turned on safely.
    enable_disappearing_messages_in_groups: false

# Bridge config
bridge:
    # Localpart template of MXIDs for Signal users.
    # {userid} is replaced with an identifier for the Signal user.
    username_template: "signal_{userid}"
    # Displayname template for Signal users.
    # {displayname} is replaced with the displayname of the Signal user, which is the first
    # available variable in displayname_preference. The variables in displayname_preference
    # can also be used here directly.
    displayname_template: "{displayname} (Signal)"
    # Whether or not contact list displaynames should be used.
    # Possible values: disallow, allow, prefer
    #
    # Multi-user instances are recommended to disallow contact list names, as otherwise there can
    # be conflicts between names from different users' contact lists.
    contact_list_names: disallow
    # Available variables: full_name, first_name, last_name, phone, uuid
    displayname_preference:
    - full_name
    - phone

    # Whether or not to create portals for all groups on login/connect.
    autocreate_group_portal: true
    # Whether or not to create portals for all contacts on login/connect.
    autocreate_contact_portal: false
    # Whether or not to use /sync to get read receipts and typing notifications
    # when double puppeting is enabled
    sync_with_custom_puppets: true
    # Whether or not to update the m.direct account data event when double puppeting is enabled.
    # Note that updating the m.direct event is not atomic (except with mautrix-asmux)
    # and is therefore prone to race conditions.
    sync_direct_chat_list: false
    # Allow using double puppeting from any server with a valid client .well-known file.
    double_puppet_allow_discovery: false
    # Servers to allow double puppeting from, even if double_puppet_allow_discovery is false.
    double_puppet_server_map:
        example.com: https://chat.joelmueller.ch
    # Shared secret for https://github.com/devture/matrix-synapse-shared-secret-auth
    #
    # If set, custom puppets will be enabled automatically for local users
    # instead of users having to find an access token and run `login-matrix`
    # manually.
    # If using this for other servers than the bridge's server,
    # you must also set the URL in the double_puppet_server_map.
    login_shared_secret_map:
        example.com: false
    # Whether or not created rooms should have federation enabled.
    # If false, created portal rooms will never be federated.
    federate_rooms: true
    # End-to-bridge encryption support options. You must install the e2be optional dependency for
    # this to work. See https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html
    encryption:
        # Allow encryption, work in group chat rooms with e2ee enabled
        allow: false
        # 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
        # Options for automatic key sharing.
        key_sharing:
            # Enable key sharing? If enabled, key requests for rooms where users are in will be fulfilled.
            # You must use a client that supports requesting keys from other users to use this feature.
            allow: false
            # Require the requesting device to have a valid cross-signing signature?
            # This doesn't require that the bridge has verified the device, only that the user has verified it.
            # Not yet implemented.
            require_cross_signing: false
            # Require devices to be verified by the bridge?
            # Verification by the bridge is not yet implemented.
            require_verification: true
    # 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 Signal. This let's you check manually whether the bridge is receiving your
    # messages.
    # Note that this is not related to Signal delivery receipts.
    delivery_receipts: false
    # Whether or not delivery errors should be reported as messages in the Matrix room. (not yet implemented)
    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
    # Interval at which to resync contacts (in seconds).
    periodic_sync: 0

    # Provisioning API part of the web server for automated portal creation and fetching information.
    # Used by things like mautrix-manager (https://github.com/tulir/mautrix-manager).
    provisioning:
        # Whether or not the provisioning API should be enabled.
        enabled: true
        # The prefix to use in the provisioning API endpoints.
        prefix: /_matrix/provision/v1
        # The shared secret to authorize users of the API.
        # Set to "generate" to generate and save a new token.
        shared_secret: generate

    # The prefix for commands. Only required in non-management rooms.
    command_prefix: "!signal"

    # Messages sent upon joining a management room.
    # Markdown is supported. The defaults are listed below.
    management_room_text:
        # Sent when joining a room.
        welcome: "Hello, I'm a Signal bridge bot."
        # Sent when joining a management room and the user is already logged in.
        welcome_connected: "Use `help` for help."
        # Sent when joining a management room and the user is not logged in.
        welcome_unconnected: "Use `help` for help or `register` to log in."
        # Optional extra text sent when joining a management room.
        additional_help: ""

    # Send each message separately (for readability in some clients)
    management_room_multiple_messages: false

    # Permissions for using the bridge.
    # Permitted values:
    #      relay - Allowed to be relayed through the bridge, no access to commands.
    #       user - Use the bridge with puppeting.
    #      admin - Use and administrate the bridge.
    # Permitted keys:
    #        * - All Matrix users
    #   domain - All users on that homeserver
    #     mxid - Specific user
    permissions:
        "*": "relay"
        "example.com": "user"
        "@admin:example.com": "admin"

    relay:
        # Whether relay mode should be allowed. If allowed, `!signal set-relay` can be used to turn any
        # authenticated user into a relaybot for that chat.
        enabled: false
        # The formats to use when sending messages to Signal via a relay user.
        #
        # Available variables:
        #   $sender_displayname - The display name of the sender (e.g. Example User)
        #   $sender_username    - The username (Matrix ID localpart) of the sender (e.g. exampleuser)
        #   $sender_mxid        - The Matrix ID of the sender (e.g. @exampleuser:example.com)
        #   $message            - The message content
        message_formats:
            m.text: '$sender_displayname: $message'
            m.notice: '$sender_displayname: $message'
            m.emote: '* $sender_displayname $message'
            m.file: '$sender_displayname sent a file'
            m.image: '$sender_displayname sent an image'
            m.audio: '$sender_displayname sent an audio file'
            m.video: '$sender_displayname sent a video'
            m.location: '$sender_displayname sent a location'
y
# Python logging configuration.
#
# See section 16.7.2 of the Python documentation for more info:
# https://docs.python.org/3.6/library/logging.config.html#configuration-dictionary-schema
logging:
    version: 1
    formatters:
        colored:
            (): mautrix_signal.util.ColorFormatter
            format: "[%(asctime)s] [%(levelname)s@%(name)s] %(message)s"
        normal:
            format: "[%(asctime)s] [%(levelname)s@%(name)s] %(message)s"
    handlers:
        file:
            class: logging.handlers.RotatingFileHandler
            formatter: normal
            filename: ./mautrix-signal.log
            maxBytes: 10485760
            backupCount: 10
        console:
            class: logging.StreamHandler
            formatter: colored
    loggers:
        mau:
            level: DEBUG
        aiohttp:
            level: INFO
    root:
        level: DEBUG
        handlers: [file, console]

mautrix as systemd service

https://docs.mau.fi/bridges/python/setu … dge=signal

mautrix with registration

https://docs.mau.fi/bridges/general/reg … vices.html

Offline

#10 2022-04-23 14:20:24

ayekat
Member
Registered: 2011-01-17
Posts: 1,589

Re: Mautrix-Signal bridge

It appears you're supposed to edit /etc/mautrix-signal/config.yaml, not /usr/share/mautrix-signal/example-config.yaml (as the name says; also you're generally not supposed to edit things in /usr anyway).

The way I see it behaving is that it probably takes the (now modified) example-config.yaml as the base configuration (with -b), then overrides the settings there with the configuration file you were supposed to have edited (with -c). But since you have it backwards there, it complains about invalid config values (e.g. homeserver.address is simply `https://example.com`. I guess that explains the second error.

About the first error, the install file says the following:

post_install() {
	cat <<- 'EOF'
		##################################
		#    Installation instructions   #
		##################################
		See: https://docs.mau.fi/bridges/python/setup/index.html?bridge=signal
		## config.yaml
		After editing /etc/mautrix-signal/config.yaml, generate a registration file using:
		# python -m mautrix_signal -b /usr/share/mautrix-signal/example-config.yaml -c /etc/mautrix-signal/config.yaml -r /etc/mautrix-signal/registration.yaml -g
		Add the path to the registration file ("/etc/mautrix-signal/registration.yaml" by default, requires permission for synapse user) to your Synapse's homeserver under app_service_config_files. Restart Synapse to apply changes.
		If you encounter an error like "cannot write tmp file, start the bridge once manually as root and check the file permissions on the config files afterwards:
		# sudo python -m mautrix_signal -b /usr/share/mautrix-signal/example-config.yaml -c /etc/mautrix-signal/config.yaml -r /etc/mautrix-signal/registration.yaml
	EOF
}

I find that hint about the tmp file a bit weird, though, because the directory is owned by mautrix-signal, so it shouldn't have any issues creating temporary files there… I haven't got any Synapse instance running, so I my ability to try out and test things is unfortunately a bit limited.

pkgs │ hacks │ cfg │ blag

Offline

#11 2022-04-23 14:34:15

Morta
Member
Registered: 2019-07-07
Posts: 655

Re: Mautrix-Signal bridge

Ok thanks for reply ! so I will edit config.yaml restore example-config.yaml

What I not understand really is following:

Add the path to the registration file ("/etc/mautrix-signal/registration.yaml" by default, requires permission for synapse user) to your Synapse's homeserver under app_service_config_files.

What is inside this file? Need read permission for the synapse user who runs the synapse server?!

And Where is app_service_config_files? In config.yaml of mautrix bridge or inside the config of synapse server?

Offline

Pages: 1

Board footer

Powered by FluxBB