Comments 35
Полезная статья, я у себя поднимал матрикс какое-то время назад (скорее из любопытства) и практически сразу понял что нужно его перецеплять на Postgres, но так руки и не дошли всё привести в порядок.
А тут всё расписано, да ещё и с админкой и TURN сервером.
Некоторые вещи я бы сделал по-другому, но это не принципиально, скорее дело вкуса.
Похоже большинство людей разворачивают матрикс просто в виде докера, но это наверное не совсем правильно, ведь если сам матрикс про privacy etc, то желательно знать что там внутри докер образа и как оно настроено/работает. Поэтому я в данном случае врукопашную предпочитаю всё сделать.
Спасибо за статью. Скажите, вот вы сделали кучу A записей: element..., matrix..., matrix-admin.YOUR-DOMAIN.COM. а не безопаснее ли YOUR-DOMAIN.COM/blabla1 т.д.? Что бы всякие боты непрерывно не ломали сервер.
Добрый.
У меня так и не получилось запустить админку под общим YOUR-DOMAIN.COM. Она наотрез отказывалась работать.
Поэтому для меня оказалось проще зарегистрировать отдельный субдомен matrix-admin.YOUR-DOMAIN.COM исключительно для админки. Для обеспечения безопасности в конфигурацию nginx proxy был добавлен src IP фильтр. Ботам админка не доступна.
Вообще Ваш вопрос больше уже про настройку самого nginx proxy.
Если вы обладаете необходимыми знаниями как можно спрятать все компоненты под одним YOUR-DOMAIN.COM можете поделиться вашей конфигурацией, я её проверю и дополню статью.
Если вкратце, то nginx proxy manager или вручную, тут ключевой момент - nginx proxy_pass. В моих намерениях применить Ваши знания, только на Debian. По срокам ничего не скажу, но постараюсь дать фидбек)
Добрый день.
Пытаюсь развернуть Matrix на Ubuntu из коробки в ВМ. Всё нормально идёт аккурат до получения сертификатов. При вводе certbot --nginx -d *** выдаёт ошибку DNS Problem: NXDOMAIN looking A for *** - check that a DNS record exists for this domain. Необходимо ли было как то дополнительно регистрировать днс, либо же это проблема настроек nginx\чего то ещё?
Добрый.
Да, вам необходимо иметь уже зарегистрированные DNS записи и ваша машина должна быть доступна из сети по 80/443 порту для автоматической выдачи Let's Encrypt сертификата.
Если у вас машина за NAT, то вам необходимо на роутере настроить проброс портов и убедиться, что на самой машине firewall не блокирует входящие ссоединения.
по-хорошему надо все компоненты ставить в докер
и на выходе будет один композ, который ставится одной командой
Полезная статья, я у себя поднимал матрикс какое-то время назад (скорее из любопытства) и практически сразу понял что нужно его перецеплять на Postgres, но так руки и не дошли всё привести в порядок.
А тут всё расписано, да ещё и с админкой и TURN сервером.
Некоторые вещи я бы сделал по-другому, но это не принципиально, скорее дело вкуса.
Похоже большинство людей разворачивают матрикс просто в виде докера, но это наверное не совсем правильно, ведь если сам матрикс про privacy etc, то желательно знать что там внутри докер образа и как оно настроено/работает. Поэтому я в данном случае врукопашную предпочитаю всё сделать.
Благодарю за фидбэк.
Да, правда, я не претендую на истину в первой инстанции. OpenSource на то и OpenSource где каждый в праве делать всё так, как ему ближе / понятнее / правильнее / проще.
В моём случае мне было необходимо минимальными усилиями поднять систему с нуля. Ну а что доробатывать и донастраивать - непаханое поле. Можно SSO прикрутить, можно дополнительные сервера поднять, можно все компоненты развести по разным инстансам. Можно всё!
И именно отсутствие в сети (не только рунете) годного гайда подтолкнуло меня к написанию такового.
Всем добра!
Поэтому я в данном случае врукопашную предпочитаю всё сделать.
Было бы полезно полный мануал увидеть — может я бы наконец-то и сам стал членом сообщества пользователей. Я сам-то поклонник виртуалок, а не контейнеров, поэтому врукопашную только приветствуется.
Пока не планирую.
Если Вы изложите конструктивные мысли, то с удовольствием проверю и дополню статью.
С другой стороны нет желания перегружать публикацию информацией и переписывать официальный гайд.
Изначально писал как шпаргалку для себя любимого. Так и родилась идея опубликовать и поделиться наработками. Не более.
Статья хорошая, спасибо.
Однако, перед прочтением мне пришлось погуглить все слова из заголовка кроме ubuntu и PostgreSQL, так вышло, что с остальными технологиями мне работать не приходилось.
Думаю, было бы полезно добавить в начало статьи краткий абзац буквально по паре строк про каждую из технологий и так же кратко рассказать, какую проблему решает данная связака.
Благодарю за фидбэк.
Соберусь с мыслями и добавлю информацию. Основная идея была в том, что если вы ищите ответы на данные вопросы, то вы уже в теме про Matrix.
Раз у Вас возник данный вопрос, то вероятнее всего он возник не только у вас.
Не обещаю, что это будет быстро, но обязательно доработаю данный вопрос.
Дополню, что synapse лучше ставить не из пакета который сделал мантейнер, а через pip. Для этого лучше использовать питоновский venv что бы не засорять систему.
Если надо на попробовать, то можно и не ставить psql базу данных, а использовать sqlite. После тестов и если все устраивает можно сделать миграцию в psql.
Когда вы в конфедерации, вы будите делится своим сервером со всеми. Хотите вы этого или нет. Лимиты по месту на сервере вы поставить не можете, но скажу, что особо критично место и не съедается. Другой момент, что вы можете хранить чье то порно.
Еще один момент, что все в matrix представлено как пространство. Сообщение от пользователя к пользователю, новые сервера, комнаты в комнатах итд. Любой пользователь который попал к вам на сервер, может создать сервер и выкладывать там, что угодно и вы знать об этом не будите. Пока у вас не начнется заканчиваться место. Контролировать этот процесс почти не возможно. Предложение со стороны разработчиков, это блокировать определенные post запросы на создание. Посмотреть какие у вас сервера и комнаты, которые создали не вы, вы так же можете только через определенные запросы. В итоге это все поставили лично для меня жирный крест. Надеюсь кому то будет полезно.
Спасибо за хороший гайд.
По поводу NGINX: в оф.документации есть вариант с Caddy. Лично проверял - сделает этот гайд еще проще (но дело вкуса конечно): https://matrix-org.github.io/synapse/latest/reverse_proxy.html?highlight=caddy#caddy-v2
В статье дважды упоминается "только локальная авторизация". Значит ли это, что в гайде рассмотрен не федерируемый (изолированный) сервер и если да, почему?
Благодарю за Ваш вопрос.
Задача поднять сервер возникла из вопроса безопасности в компании. Следовательно, поднимая свой сервер, нам на сервере никто, кроме авторизированных пользователей не нужен.
Следовательно было запрещено аутентифицироваться пользователям, которые зарегистрированы на вышестоящих Matrix серверах:names: [client]
Благодаря вашему вопросу я обратил внимание на одно упущение, у меня была включена Matrix Federation. Статью уже дополнил и добавил:matrix_synapse_federation_enabled: falsematrix_synapse_federation_port_enabled: false
Мне не нужно, чтобы мой сервер каким-либо образом взаимодействовал с сетью Matrix и отлично устраивает полностью изолированный сервер для личных нужд и общения внутри компании.
Немного теории из сети по Matrix Synapse Federation.
Matrix Synapse Federation (федерация Matrix Synapse) относится к способу взаимодействия различных серверов Matrix Synapse в сети Matrix. Федерация позволяет пользователям, зарегистрированным на одном сервере Matrix Synapse, общаться и отправлять сообщения пользователям, зарегистрированным на других серверах Matrix Synapse.
Принцип работы федерации Matrix Synapse следующий:
Регистрация на сервере: Пользователи выбирают сервер Matrix Synapse и регистрируются на нем. Каждый сервер имеет свой собственный домен (например, example.com), и пользователи получают идентификаторы вида @username:example.com.
Распространение информации: Когда пользователь отправляет сообщение другому пользователю на другом сервере, его сервер Matrix Synapse устанавливает соединение с сервером получателя и передает сообщение через эту связь. Это позволяет серверам сети Matrix обмениваться информацией о пользователях, комнатах чата и сообщениях.
Синхронизация данных: Когда пользователь получает новые сообщения или изменения в комнате чата, его сервер Matrix Synapse синхронизирует эти данные с его устройствами, чтобы он мог видеть все обновления на всех своих устройствах.
Ключи шифрования: Федерация Matrix Synapse также поддерживает шифрование end-to-end, где сообщения зашифрованы на устройстве отправителя и расшифровываются на устройстве получателя. Ключи шифрования обмениваются между серверами, чтобы обеспечить безопасность и приватность сообщений.
Федерация Matrix Synapse позволяет пользователям общаться и взаимодействовать с пользователями на разных серверах Matrix Synapse, расширяя сеть и возможности коммуникации. Это позволяет пользователям выбирать сервер по своему выбору, сохраняя при этом возможность общаться с пользователями на других серверах, распределенных по всей сети Matrix.
Отключение федерации в Matrix Synapse может быть достигнуто путем настройки вашего сервера. Вот общие шаги, которые можно предпринять для отключения федерации:
Откройте файл конфигурации Matrix Synapse: Обычно файл называется "homeserver.yaml" и находится в каталоге, где установлен сервер Matrix Synapse.
Найдите раздел "Federation" или "Федерация" в файле конфигурации.
В этом разделе установите параметр "enabled" или "включено" в значение "false" или "ложь". Это отключит возможность федерации на вашем сервере.
Сохраните изменения в файле конфигурации и перезапустите сервер Matrix Synapse, чтобы изменения вступили в силу.
После выполнения этих шагов ваш сервер Matrix Synapse будет отключен от федерации, и пользователи на других серверах не смогут обмениваться сообщениями или взаимодействовать с вашим сервером.
Обратите внимание, что отключение федерации ограничивает возможность общения с пользователями на других серверах и может ограничить функциональность и связность сети Matrix в целом.
у вас еще в конфигах nginx нет переключение на протокол 1.1 Это рекомендуется делать, если не хотим проблем с бекендом и это указанно в примерах https://matrix-org.github.io/synapse/latest/reverse_proxy.html Так же рекомендуется для клиентов в днс сделать записи, для быстрого обнаружения клиентами. Но в итоге все равно рано или поздно придете к тому, что нет возможности управлять и удалять что то старое, если кончается место на диски. Только пересоздовать комнату, а старое удалять. Кстати, можно еще упомянуть о разных версиях комнат (с тз API) так как они дают разный функционал.
еще не очень понятен смысл
allow 1.1.1.1; #Allowed IP
allow 8.8.8.8/24; #Allowed Subnet
deny all;Так же не очень понятно, почему бы серты nginx не объединить в один конфиг и в целом не использовать location, а не создавать новый domain name. Но тут наверно дело уже вкуса.
Добрый Вам день.
По поводу подсказки касательно недостающих настроек в конфигурации nginx - изучу документацию более подробно и дополню.
По поводу вашего вопроса на счёт Allowed IP и Allowed Subnet это пример того, как можно Admin UI хоть немного прикрыть от сети фильтруя src IP на уровне nginx proxy.
Если вы хотите прикрыть админку, лучше сделать дополнительную бейсик авторизацию
Это понятно, но не хотел совсем уж усложнять. IP фильтр тоже вполне себе нормально.
Как вариант можно было вынести на нестандартный порт и закрыть самим firewall машины или облака, где эта машина запущена.
Мне достаточно такого способа.
Бейсик авторизация 4 строчки вроде как, не очень понятно, что там может быть сложного ?
Позвольте мне прикрывать свою админку так, как мне это больше нравится! ;-)
Да это как угодно, только те кто будет повторять, будут обычно повторять копи пастом не читая документацию и будут беды.
Не совсем понимаю какие именно могут быть беды если прикрыто по src IP.
Тупо копи-пастом тут не получится поставить да и человек, который будет поднимать данный сервис подразумевается, что имеет определённую, пускай и минимальную, ИТ базу. Иначе не получится.
DNS, Firewall, port forward на рутере (если машина за натом) - в туториале я это не упоминал.
а почему не какой-нибудь rocket.chat/mattermost и подобные?
В организации у меня 350 чел, возможно сделать так, чтоб народ регистрировался, я подтверждал, и после этого все попадали в общий список контактов, ведь они не знают логинов друг друга
Отличный вопрос.
На счёт регистрация с одобрением не изучал. Нам было не нужно, т.к. проще и безопаснее создавать пользователей вручную. Поэтому не отвечу.
Если вы решите данную задачу и поделитесь Вашим способом с удовольствием дополню статью.
Касательно списка всех сотрудников я так и не решил, как можно обойти ручное добавление каждого сотрудника у каждого в список.
Нашёл для себя workaround в виде создания общей комнаты, в которую добавлены абсолютно все сотрудники. Таким образом зайдя в комнату видно абсолютно всех её участников.
Более годного решения пока не было найдено, я сам в процессе изучения матрицы...!!!
Уже не помню точно, но вроде как нет. Можно полностью отключить внешнею регистрацию и сделать свою через API с вашим подтверждением. Больше параметров можно глянуть тут - https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html Про общий список, можно настроить общую комнату в которую человек будет попадать после регистрации. Но замечу, что люди смогут сами создавать комнаты и творить любую дичь без вашего ведома.
Не поулчается понять как сделать полностью открытую регу для желающих. вроде в конфиге прописал enable_registration: true
enable_registration_without_verification: true, а все равно регистрация не работает через element. Может ктото может подсказать?
Спасибо за статью )
Если надо matrix быстро (ansible) - https://github.com/spantaleev/matrix-docker-ansible-deploy
Docs https://github.com/spantaleev/matrix-docker-ansible-deploy/tree/master/docs
Disabling federation https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/docs/configuring-playbook-federation.md
Спасибо
Установка и настройка сервера Matrix Synapse + PostgreSQL + Admin UI + Element WEB. Ubuntu 20 LTS / Ubuntu 22 LTS