Таки ZFS (как и любая другая ФС) - это просто инструмент. Ножом для масла невозможно порезаться, но работать все предпочитают, почему-то, острыми ножами. Разумеется, с соблюдением необходимой техники безопасности. Вот CoW файловые системы - именно такой инструмент
Таки давайте разбираться
Если мы говорим о неведомых космических лучах, которые могут вызвать сбой в RAM (надеюсь, мы же под “домашним сервером” не понимаем по совместительству игровой комп, где все разогнано так, что стресс-тест не проходит?), то в ваших силах уменьшить площадь атаки, ограничив размер ARC (zfs_arc_max). Врядли в домашнем сервере из описанной задачи (фоточки, аналог гуглодиска, хранение паролей) у вас настолько много иопсов, что вам нужен огроменный кэш
Используйте избыточность (хоть copies=3 для датасета). Вероятность того, что два космических луча пронзят ячейки памяти в вашем ARC еще ниже
Кстати, а вы считали эту вероятность? Вопрос не праздный. У обычных (не энтерпрайзных) дисков вероятность получения неустранимой ошибки - 1*10^14. Это около 12.5 ТБ всего. Т.е. для дисков в 14 ТБ уже попахивает тем, что безошибочно данные прочитать не удастся. Вот чего надо опасаться (а не космической радиации). И нет, я не стебусь над космической радиацией, я лишь уточняю вероятность. Скажем, у меня пучок пулов (и еще больше датасетов) работает уже долгие годы. С еженедельными скрабами пулов. И пока лучи в мой компьютер не попали. А вот дисков я поменял уже вагон. Бэды, знаете ли.
Вы говорите про LVM, но это не файловая система. Если в RAM произойдет ошибка, ничто не помешает ОС считать ее на EXT4 / XFS или что вы там используете. Более того, ситуация с надежностью даже обратная. ZFS пишет чексуммы для любого блока, независимо от типа пула. Если при чтении ошибка возникнет, ZFS скажет, что данные повреждены. Да, они повреждены, но вы об этом будете знать. LVM с EXT4 просто считает ошибочные данные и отдаст их вам.
С записью ситуация похожая. ОС хочет записать данные на диск, тут космические лучи внесли сумятицу. EXT4 ничего не проверяет и просто запишет данные на диск (flush). Как будет в ZFS? Если ошибка произойдет до подсчета чексуммы, то ZFS, конечно, точно так же запишет битые данные. Однако если сумма уже подсчитана, а ошибка произошла при записи, то ZFS это обнаружит
Вы пишите про то, что бэкапы не помогут, т.к. ошибка попадет туда. Помогут, конечно же. Если вы не смогли прочитать свой любимый файл - обратитесь к бэкапу. В последней версии та же поврежденная версия? Выбирайте более старую резервную копию. Домашние данные обычно скорее просто потихоньку дополняются, т.е. данные, единожды попавшие в бэкап, особо не меняются. Так что такие резервные копии отлично дедуплицируются. Можно хранить хоть за 10 лет. Конечно, если под резервной копией понимать “раз в полгода подключаю внешний жесткий диск и копирую на него все файлы, перезаписывая более старые”, то да, такой бэкап не поможет
безусловно, для людей, далеких от компухтеров, собственный хостинг - это за гранью фантастики. хотя, опять же, у некоторых насов уже есть все необходимое, включая бесплатный доступ снаружи через их облако. достаточно тынкуть в админке "хочу иммич" и подождать несколько минут
наш ркн день и ночь работает над повышением компьютерной грамотности пенсионеров, тут ограничивающий фактор скорее несоответствие нынешних цен на железо и размеров пенсий
а для тех, кто разбирается чуть глубже, чтобы состряпать правильный запрос бесплатному квену, последний вполне себе найдет в сети бесплатные ресурсы с бест-практисами по развертыванию всего этого и выдаст их в вольном переводе.
Еще лет 10 назад иметь свой собственный хостинг на антресолях действительно было доступно минимум эникейщикам. Сейчас этот путь уже прошли многие, достаточно просто следовать инструкциям
ZFS co-creator Matt Ahrens put it plainly in a widely cited statement: there's nothing special about ZFS that requires or encourages the use of ECC RAM more than any other filesystem. The official OpenZFS FAQ takes the same position: ECC is recommended for anyone who values their data, but it is not a ZFS requirement, and running ZFS without ECC still leaves you better protected than running a non-checksumming filesystem without ECC.
Если лень ходить по ссылке:
> If this were to occur OpenZFS (or any other filesystem) will write the damaged data to disk and be unable to automatically detect the corruption.
и, там же
For home users the additional safety brought by ECC memory might not justify the cost.
Хабр — место для обмена знаниями и приятного общения людей, интересующихся технологиями.
Несколько удивлен, что именно тут, а не на vc или t-j в комментах много людей, которые "ууу, это ж надо разбираться, чтобы настраивать. да еще поддерживать потом. проще за несколько облаков платить"...
Справедливо, но с оговорками. Минимальное понимание требуется, но в остальном ИИ-шки вполне решают. Т.е. развернуть самохостинг с контейнерами может вполне себе опытный пользователь ОС, если знает про условного квена. Есть даже дистрибы, где всё это максимально упрощено. Другой вариант - взять NAS с поддержкой контейнеров
Безусловно. Как и в любом другом деле (строительство, обслуживание авто и т.д.). Или делаешь сам (и отвечаешь сам), или делегируешь другим (и они несут ответственность). Хотя последнее и необязательно. Как в случае косяков с ремонтом, так и в случае удаления твоих данных где-то в облаке.
Публичный IP стоит копейки, а в ряде случаев (когда серый IP и dyndns или аналоги) и без этого можно обойтись. Брутфорс не обеспокоит, если нечего брутфорсить (WebAuth вместо паролей и т.д.).
Но ведь доступ к вашему кинетику можно было получить и без всяких квнов, т.е. и на энтварь пофиг. Да, пострадала бы часть функциональности, но не вся. А вот ситуация с пропаданием инета вполне себе вероятная. И в случае домашнего сервера это означает организацию резервного канала, что тоже надо учитывать в расходах.
кроме игр с виртуализацией или хостингом чего-то не критичного, потому что на этих мелочах ты можешь потерять несколько дней, недель
Вообще, прежде, чем ввязываться в селф-хостинг, необходимо сначала понять - а что же конкретно от него ожидаешь?
Всякие Я.диски и ГуглоФото часто люди используют именно как расширение памяти своих мобильных устройств / ноутбуков: все актуальное есть в виде копии на самом устройстве, а, по мере устаревания, оседает только в облаке
В таком разрезе даже неделя отсутствия доступа к облаку (личному или общему) может быть неприятна разве что нехваткой места на устройстве
Еще один возможный профиль self-hosted: максимальная автономность на случай игрищ РКН или других катаклизмов. Если сервер уже есть (а, как правильно отмечено в статье, чем больше объемы, тем быстрее окупается). чего б не держать там больше сервисов? *arr стек и джеллифин - вот уже фильмы и сериалы без платных подписок (раз Рутубу можно, то почему нам нельзя?). И интернет нужен только для скачивания файлов.
либрусек + каталогизатор + opml-сервер - и вот уже нет вопроса "а что же почитать перед сном".
ниже уже ответили. да, ctop. и это не совсем мониторинг (там на скрине видно, что и прометей крутится), а это просто в моменте вот, например, потребление памяти синапсом за месяц (без mas, но он тоже копейки жрет
mas:
(db на обоих скринах - постгря, redis, понятно, редис)
в текущей версии клиента (и было еще до нг точно) можно выбрать динамик. если есть гарнитура - то будет три варианта. Во время звонка зайдите в настройки
но да, классический элемент работал логичнее. но с джитси, а лайвкит все же получше, хотя и геморнее настраивается
Встречаются в фантастике и истинно колесные животные, автора вспомнить не могу.
Еще в начале прошлого века в "Озме из страны Оз" были описаны вымышленные колесуны, где колеса, на сколько я помню, были роговыми наростами, примерно как копыта у лошадей. Конечно, в детской сказке никто не заморачивался придумыванием того, откуда к колесам-ногтям должно было поступать питание для роста клеток
если один живешь - то да, безусловно. а если, положим, легли jellyfin и immich для всей семьи, то лучше иметь возможность глянуть удаленно, чего там жена любимый сериал не может глянуть
опять же - если не кроить и брать мамки с алиэкспресса, а стараться что-то надежное взять, то там и AMT, скорее всего будет. Собственно, я весной себе брал мамку на Q670. По цене как геймерские на Z790, но в плюсе AMT и больший уровень физической защиты (скажем, покрыта лаком для защиты от влажности), а в минусе - "некрасивый" зеленый текстолит и отсутствие всяких RGB-подсветок. Да, и UEFI косит под старые биосы. Для меня - сделка века)
таки управлять железом удаленно бывает полезно (пример - сбой питания, после которого отвалился загрузочный диск / сменился порядок загрузки). можно спокойно зайти в бивис и понять, что произошло.
прям совсем хардкорный ilo - это приятно, конечно, но не обязательно. Intel AMT вполне достаточно, но раскурить, на каких связках чипсетов + процов всё поддерживается в полной мере - затея для сильных духом. Лучше искать готовые примеры конфигураций у людей, у которых всё работает и брать такое же
`ГГГГ-ММ-ДД Описание`. Если это какое-то длительное событие (например, поездка по нескольким городам), то может быть разбито на подпапки по дням. Скажем: `ГГГГ-ММ-ДД Поездка Тверь-Бологое\01 - Тверь`
`ГГГГ-ММ-ДД Поездка Тверь-Бологое\02 - Бологое`
Внутри папки лежат обработанные изображения, в подпапке RAW - соответственно, RAW-ы и файлы метаданных, если вдруг захочу переобработать
Обработка:
DxO под вайном. Работает кривовато, но терпимо. Слил с фотика RAW-ы во временную директорию, раскидал по дням, дал названия, залил в DxO, обработал. Лишнее (неудачное и т.д) удалил
Если нужно, какие-то фотографии потом дорабатываю отдельно (скажем, если надо сшить панораму)
Просмотр и т.д.
После обработки и удаления ненужного папка перемещается в архив, на который натравлен immich (т.е. папка для иммича - внешнее хранилище, это важно). Там и просмотр откуда угодно, и поиск (в т.ч. LLM) и возможность делиться, и альбомы и т.д.
Имя альбомов соответствует именам папок, т.е. даже если захочу уйти от иммича, сама по себе структура фотографий никуда не девается, из потерь будет только база лиц и все
если что (вдруг кто еще наткнется с такой же проблемой) я нашел в логах caddy, что урлы были недоступны. начал щупать курлом то к лайвкиту, то к джвт и понял, что есть проблема с маршрутизацией запросов (идут не туда).
возможно, если весь стек сразу разворачивать с нуля официально рекомендуемыми скриптами, работало бы иначе, но у меня уже была инсталляция в продакшене (synapse + oauth2), и ради ухода от джитси пришлось мигрировать на synapse + mas + oauth2+ livekit + livekit jwt. Чтобы все взлетело, официальной документации оказалось недостаточно
Ну и в целом документации не хватает, конечно :(
С последним релизом element-call научился дружить с MAS (согласно чейндж-логам). Но зайти с oauth2-учеткой у меня так и не получается, хотя настройки вроде верные.
Или вот везде встречаются параметры про доступ гостям, но мне так и не удалось настроить гостевой вход (например, чтобы провести совещание не толкьо внутри компании, но и с кем-то снаружи). Некоторое время можно было спасаться федерациями - добавлять в чаты людей с matrix.org, но сейчас matrix.org в РФ заблокирован
В общем, при вроде бы большом коммьюнити, выхлопа от сообщества (гайды, доки, бест практисы) мало :(
не скрины смотрите, а логи livekit и livekit-jwt на момент возникновения ошибки
например, по документации должно работать одно имя для сервисов (типа lk.TLD), а маршрутизация делается для /jwt (а все остальное - в лайвкит) но парсинг логов показал, что так не работает в актуальной версии, поэтому настроил иначе: разнес оба сервиса. все, что идет TLD/livekit - маршрутизируется в лайвкит, а то, что TLR/lk-jwt - в jwt.
для org.matrix.msc4143.rtc_foci, соответственно, в качестве livekit указан TLD/lk-jwt ну а LIVEKIT_URL=wss://TLD:443/livekit
без логов понять, чего не хватало, было невозможно
в докере вообще все просто разворачивается, у разработчика есть готовый скрипт, который запрашивает информацию и генерирует заполненные конфиги (`element-docker-demo`)
так-то нынче модно аутентификацию пользователей заворачивать на mas, из экспериментальной фичи это уже зарелизилось недавно
и звонки/конференции заворачивать в лайвкит, вместо coturn+jitsi. Со старыми звонками работают только старые клиенты (Element Classic), разработчик же рекомендует в новых инсталляциях использовать Element X. В отличие от десктопного и веб-клиентов, мобильные между собой договориться не могут, так что логичнее разворачивать то, что новое
ну и чтобы клиенты нормально находили сервер, надо бы еще настроить делегирование (чтобы веб-сервер возвращал клиенту запросы /.well-known/matrix/client и /.well-known/matrix/server)
(опционально - /.well-known/element/element.json, /.well-known/matrix/support и /.well-known/openid-configuration)
P.S. еще хорошим тоном считается настраивать матрикс на TLD, а не SLD.
Таки ZFS (как и любая другая ФС) - это просто инструмент. Ножом для масла невозможно порезаться, но работать все предпочитают, почему-то, острыми ножами. Разумеется, с соблюдением необходимой техники безопасности. Вот CoW файловые системы - именно такой инструмент
Таки давайте разбираться
Если мы говорим о неведомых космических лучах, которые могут вызвать сбой в RAM (надеюсь, мы же под “домашним сервером” не понимаем по совместительству игровой комп, где все разогнано так, что стресс-тест не проходит?), то в ваших силах уменьшить площадь атаки, ограничив размер ARC (zfs_arc_max). Врядли в домашнем сервере из описанной задачи (фоточки, аналог гуглодиска, хранение паролей) у вас настолько много иопсов, что вам нужен огроменный кэш
Используйте избыточность (хоть copies=3 для датасета). Вероятность того, что два космических луча пронзят ячейки памяти в вашем ARC еще ниже
Кстати, а вы считали эту вероятность? Вопрос не праздный. У обычных (не энтерпрайзных) дисков вероятность получения неустранимой ошибки - 1*10^14. Это около 12.5 ТБ всего. Т.е. для дисков в 14 ТБ уже попахивает тем, что безошибочно данные прочитать не удастся. Вот чего надо опасаться (а не космической радиации). И нет, я не стебусь над космической радиацией, я лишь уточняю вероятность. Скажем, у меня пучок пулов (и еще больше датасетов) работает уже долгие годы. С еженедельными скрабами пулов. И пока лучи в мой компьютер не попали. А вот дисков я поменял уже вагон. Бэды, знаете ли.
Вы говорите про LVM, но это не файловая система. Если в RAM произойдет ошибка, ничто не помешает ОС считать ее на EXT4 / XFS или что вы там используете. Более того, ситуация с надежностью даже обратная. ZFS пишет чексуммы для любого блока, независимо от типа пула. Если при чтении ошибка возникнет, ZFS скажет, что данные повреждены. Да, они повреждены, но вы об этом будете знать. LVM с EXT4 просто считает ошибочные данные и отдаст их вам.
С записью ситуация похожая. ОС хочет записать данные на диск, тут космические лучи внесли сумятицу. EXT4 ничего не проверяет и просто запишет данные на диск (flush). Как будет в ZFS? Если ошибка произойдет до подсчета чексуммы, то ZFS, конечно, точно так же запишет битые данные. Однако если сумма уже подсчитана, а ошибка произошла при записи, то ZFS это обнаружит
Вы пишите про то, что бэкапы не помогут, т.к. ошибка попадет туда. Помогут, конечно же. Если вы не смогли прочитать свой любимый файл - обратитесь к бэкапу. В последней версии та же поврежденная версия? Выбирайте более старую резервную копию. Домашние данные обычно скорее просто потихоньку дополняются, т.е. данные, единожды попавшие в бэкап, особо не меняются. Так что такие резервные копии отлично дедуплицируются. Можно хранить хоть за 10 лет. Конечно, если под резервной копией понимать “раз в полгода подключаю внешний жесткий диск и копирую на него все файлы, перезаписывая более старые”, то да, такой бэкап не поможет
ну, мы ж на хабре сидим так-то
безусловно, для людей, далеких от компухтеров, собственный хостинг - это за гранью фантастики. хотя, опять же, у некоторых насов уже есть все необходимое, включая бесплатный доступ снаружи через их облако. достаточно тынкуть в админке "хочу иммич" и подождать несколько минут
наш ркн день и ночь работает над повышением компьютерной грамотности пенсионеров, тут ограничивающий фактор скорее несоответствие нынешних цен на железо и размеров пенсий
а для тех, кто разбирается чуть глубже, чтобы состряпать правильный запрос бесплатному квену, последний вполне себе найдет в сети бесплатные ресурсы с бест-практисами по развертыванию всего этого и выдаст их в вольном переводе.
Еще лет 10 назад иметь свой собственный хостинг на антресолях действительно было доступно минимум эникейщикам. Сейчас этот путь уже прошли многие, достаточно просто следовать инструкциям
Если лень ходить по ссылке:
> If this were to occur OpenZFS (or any other filesystem) will write the damaged data to disk and be unable to automatically detect the corruption.
и, там же
Несколько удивлен, что именно тут, а не на vc или t-j в комментах много людей, которые "ууу, это ж надо разбираться, чтобы настраивать. да еще поддерживать потом. проще за несколько облаков платить"...
Справедливо, но с оговорками. Минимальное понимание требуется, но в остальном ИИ-шки вполне решают. Т.е. развернуть самохостинг с контейнерами может вполне себе опытный пользователь ОС, если знает про условного квена. Есть даже дистрибы, где всё это максимально упрощено. Другой вариант - взять NAS с поддержкой контейнеров
Безусловно. Как и в любом другом деле (строительство, обслуживание авто и т.д.). Или делаешь сам (и отвечаешь сам), или делегируешь другим (и они несут ответственность). Хотя последнее и необязательно. Как в случае косяков с ремонтом, так и в случае удаления твоих данных где-то в облаке.
Публичный IP стоит копейки, а в ряде случаев (когда серый IP и dyndns или аналоги) и без этого можно обойтись. Брутфорс не обеспокоит, если нечего брутфорсить (WebAuth вместо паролей и т.д.).
Но ведь доступ к вашему кинетику можно было получить и без всяких квнов, т.е. и на энтварь пофиг. Да, пострадала бы часть функциональности, но не вся. А вот ситуация с пропаданием инета вполне себе вероятная. И в случае домашнего сервера это означает организацию резервного канала, что тоже надо учитывать в расходах.
Вообще, прежде, чем ввязываться в селф-хостинг, необходимо сначала понять - а что же конкретно от него ожидаешь?
Всякие Я.диски и ГуглоФото часто люди используют именно как расширение памяти своих мобильных устройств / ноутбуков: все актуальное есть в виде копии на самом устройстве, а, по мере устаревания, оседает только в облаке
В таком разрезе даже неделя отсутствия доступа к облаку (личному или общему) может быть неприятна разве что нехваткой места на устройстве
Еще один возможный профиль self-hosted: максимальная автономность на случай игрищ РКН или других катаклизмов. Если сервер уже есть (а, как правильно отмечено в статье, чем больше объемы, тем быстрее окупается). чего б не держать там больше сервисов? *arr стек и джеллифин - вот уже фильмы и сериалы без платных подписок (раз Рутубу можно, то почему нам нельзя?). И интернет нужен только для скачивания файлов.
либрусек + каталогизатор + opml-сервер - и вот уже нет вопроса "а что же почитать перед сном".
я на своем телеке смотрю свой же Jellyfin. У меня нет ни рекламы, ни более релевантной рекламы. ЧЯДНТ? :)
ниже уже ответили. да, ctop. и это не совсем мониторинг (там на скрине видно, что и прометей крутится), а это просто в моменте
вот, например, потребление памяти синапсом за месяц (без mas, но он тоже копейки жрет
mas:
(db на обоих скринах - постгря, redis, понятно, редис)
в текущей версии клиента (и было еще до нг точно) можно выбрать динамик. если есть гарнитура - то будет три варианта. Во время звонка зайдите в настройки
но да, классический элемент работал логичнее. но с джитси, а лайвкит все же получше, хотя и геморнее настраивается
есть удержание сообщений. e2e можно отключить. читайте себе на здоровье всю переписку хоть столетней давности
Не так уж много оно и жрет
Про родной клиент - есть и громкая связь, и динамик телефона (когда к уху прикладывать)
а вот с камерой действительно беда, issue давно открыт, но пока изменений нет
говорят, что вацап базируется на xmpp, и, из-за блокировки, страдают и другие xmpp-клиенты (ejabberd и т.д.), т.к. сигнатуры похожи
Еще в начале прошлого века в "Озме из страны Оз" были описаны вымышленные колесуны, где колеса, на сколько я помню, были роговыми наростами, примерно как копыта у лошадей. Конечно, в детской сказке никто не заморачивался придумыванием того, откуда к колесам-ногтям должно было поступать питание для роста клеток
если один живешь - то да, безусловно. а если, положим, легли jellyfin и immich для всей семьи, то лучше иметь возможность глянуть удаленно, чего там жена любимый сериал не может глянуть
опять же - если не кроить и брать мамки с алиэкспресса, а стараться что-то надежное взять, то там и AMT, скорее всего будет. Собственно, я весной себе брал мамку на Q670. По цене как геймерские на Z790, но в плюсе AMT и больший уровень физической защиты (скажем, покрыта лаком для защиты от влажности), а в минусе - "некрасивый" зеленый текстолит и отсутствие всяких RGB-подсветок. Да, и UEFI косит под старые биосы. Для меня - сделка века)
таки управлять железом удаленно бывает полезно (пример - сбой питания, после которого отвалился загрузочный диск / сменился порядок загрузки). можно спокойно зайти в бивис и понять, что произошло.
прям совсем хардкорный ilo - это приятно, конечно, но не обязательно. Intel AMT вполне достаточно, но раскурить, на каких связках чипсетов + процов всё поддерживается в полной мере - затея для сильных духом. Лучше искать готовые примеры конфигураций у людей, у которых всё работает и брать такое же
Мой вариант:
Организация хранения:
`ГГГГ-ММ-ДД Описание`. Если это какое-то длительное событие (например, поездка по нескольким городам), то может быть разбито на подпапки по дням. Скажем:
`ГГГГ-ММ-ДД Поездка Тверь-Бологое\01 - Тверь`
`ГГГГ-ММ-ДД Поездка Тверь-Бологое\02 - Бологое`
Внутри папки лежат обработанные изображения, в подпапке RAW - соответственно, RAW-ы и файлы метаданных, если вдруг захочу переобработать
Обработка:
DxO под вайном. Работает кривовато, но терпимо. Слил с фотика RAW-ы во временную директорию, раскидал по дням, дал названия, залил в DxO, обработал. Лишнее (неудачное и т.д) удалил
Если нужно, какие-то фотографии потом дорабатываю отдельно (скажем, если надо сшить панораму)
Просмотр и т.д.
После обработки и удаления ненужного папка перемещается в архив, на который натравлен immich (т.е. папка для иммича - внешнее хранилище, это важно). Там и просмотр откуда угодно, и поиск (в т.ч. LLM) и возможность делиться, и альбомы и т.д.
Имя альбомов соответствует именам папок, т.е. даже если захочу уйти от иммича, сама по себе структура фотографий никуда не девается, из потерь будет только база лиц и все
immich же
если что (вдруг кто еще наткнется с такой же проблемой) я нашел в логах caddy, что урлы были недоступны. начал щупать курлом то к лайвкиту, то к джвт и понял, что есть проблема с маршрутизацией запросов (идут не туда).
возможно, если весь стек сразу разворачивать с нуля официально рекомендуемыми скриптами, работало бы иначе, но у меня уже была инсталляция в продакшене (synapse + oauth2), и ради ухода от джитси пришлось мигрировать на synapse + mas + oauth2+ livekit + livekit jwt. Чтобы все взлетело, официальной документации оказалось недостаточно
Ну и в целом документации не хватает, конечно :(
С последним релизом element-call научился дружить с MAS (согласно чейндж-логам). Но зайти с oauth2-учеткой у меня так и не получается, хотя настройки вроде верные.
Или вот везде встречаются параметры про доступ гостям, но мне так и не удалось настроить гостевой вход (например, чтобы провести совещание не толкьо внутри компании, но и с кем-то снаружи). Некоторое время можно было спасаться федерациями - добавлять в чаты людей с matrix.org, но сейчас matrix.org в РФ заблокирован
В общем, при вроде бы большом коммьюнити, выхлопа от сообщества (гайды, доки, бест практисы) мало :(
не скрины смотрите, а логи livekit и livekit-jwt на момент возникновения ошибки
например, по документации должно работать одно имя для сервисов (типа lk.TLD), а маршрутизация делается для /jwt (а все остальное - в лайвкит)
но парсинг логов показал, что так не работает в актуальной версии, поэтому настроил иначе: разнес оба сервиса. все, что идет TLD/livekit - маршрутизируется в лайвкит, а то, что TLR/lk-jwt - в jwt.
для
org.matrix.msc4143.rtc_foci, соответственно, в качестве livekit указан TLD/lk-jwtну а
LIVEKIT_URL=wss://TLD:443/livekitбез логов понять, чего не хватало, было невозможно
в докере вообще все просто разворачивается, у разработчика есть готовый скрипт, который запрашивает информацию и генерирует заполненные конфиги (`element-docker-demo`)
так-то нынче модно аутентификацию пользователей заворачивать на mas, из экспериментальной фичи это уже зарелизилось недавно
и звонки/конференции заворачивать в лайвкит, вместо coturn+jitsi. Со старыми звонками работают только старые клиенты (Element Classic), разработчик же рекомендует в новых инсталляциях использовать Element X. В отличие от десктопного и веб-клиентов, мобильные между собой договориться не могут, так что логичнее разворачивать то, что новое
ну и чтобы клиенты нормально находили сервер, надо бы еще настроить делегирование (чтобы веб-сервер возвращал клиенту запросы
/.well-known/matrix/clientи/.well-known/matrix/server)(опционально -
/.well-known/element/element.json,/.well-known/matrix/supportи/.well-known/openid-configuration)P.S. еще хорошим тоном считается настраивать матрикс на TLD, а не SLD.