Gluek's blog

Зеркала gluek.info в Yggdrasil и Reticulum

Thu, 29 Oct 2026 22:22:00 GMT

К зеркалам в i2p и tor добавились ещё два.

Yggdrasil:

http://[201:ffff:e518:7af1:c905:eb92:c0de:7777]/

Reticulum, узел NomadNet — текстовая версия блога в разметке Micron, с пережатыми картинками:

77777777db2b0274d56ae73fb7518a4a

Открывается в NomadNet, MeshChat и Columba на телефоне.

А чтобы новые посты приходили прямо в Reticulum, я сделал LXMF-бота 777777779e7beceb13399c0ab0c63613. Напишите ему «подписаться» из Sideband, Columba или MeshChat, а «последние» покажет свежие посты без подписки.

Адреса подобраны красивые: в Reticulum оба начинаются с 77777777, в Yggdrasil заканчивается на c0de:7777. Все зеркала собираются тем же CI, что и основной сайт, при каждом коммите.

lxmf_publish

Thu, 29 Oct 2026 22:22:00 GMT

Брат-близнец deltachat_publish, только в обратную сторону: тот публикует посты в блог, а этот доставляет их читателям по mesh-сети Reticulum. Работает в паре с зеркалом блога на узле NomadNet.

LXMF-адрес бота: 777777779e7beceb13399c0ab0c63613

Команды

Писать боту можно из Sideband, Columba, MeshChat или NomadNet (регистр не важен, / в начале тоже можно):

подписаться (sub, start) — присылать новые посты;
отписаться (unsub, stop) — перестать присылать;
последние (last) — свежие посты без подписки.

Стек

Язык: Python 3.13
Сеть: RNS + LXMF
База данных: SQLite (подписчики и уже разосланные посты)
Деплой: Docker + Docker Compose, обновление по тегам vX.Y.Z через update.sh

Как это устроено

Новые посты бот берёт из RSS-ленты. При первом запуске он только запоминает уже существующие посты, чтобы не засыпать подписчиков всем архивом.
Сообщение содержит ссылки на пост в зеркале NomadNet и на сайте.
Доставка сначала напрямую, а если подписчик не в сети — через propagation node: клиент заберёт сообщение при следующей синхронизации.
Не ретранслятор: Reticulum у бота запущен с enable_transport = No, чужой трафик через сервер не ходит.
Адрес подобран с префиксом 77777777, ключ лежит только на сервере.

Исходный код

Репозиторий открыт на GitHub: mrgluek/lxmf_publish, зеркало на моём сервере: git.gluek.info/gluek/lxmf_publish. Лицензия MIT.

upgrades.syncthing.gluek.info

Thu, 22 Oct 2026 22:05:00 GMT

Зеркало сервера обновлений Syncthing. В России заблокирован release.syncthingcdn.net (проверка на cheburcheck), откуда Syncthing скачивает новые версии, поэтому автообновление перестало работать.

Как пользоваться

В веб-интерфейсе Syncthing открыть Действия → Настройки → Дополнительно → Options и указать в поле Releases URL:

https://upgrades.syncthing.gluek.info/meta.json

После этого Syncthing будет проверять и скачивать обновления через зеркало.

Это безопасно?

Да. Каждый архив релиза содержит файл release.sig, и Syncthing проверяет его ключом, встроенным в сам бинарник (lib/upgrade). Если зеркало отдаст изменённый файл, подпись не сойдётся и обновление просто не установится.

Как устроено

Syncthing сначала скачивает meta.json со списком релизов, а в нём лежат прямые ссылки на архивы в release.syncthingcdn.net. Значит, мало проксировать сам meta.json, нужно ещё переписать в нём ссылки.

Скрипт по cron раз в час скачивает оригинальный meta.json и заменяет адрес CDN на адрес зеркала:

#!/bin/sh
set -eu
dir=/path/to/folder/syncthing
mkdir -p "$dir"
tmp=$(mktemp "$dir/.meta.XXXXXX")
trap "rm -f $tmp" EXIT
curl -fsS -m 60 https://upgrades.syncthing.net/meta.json \
  | sed "s#https://release.syncthingcdn.net/#https://upgrades.syncthing.gluek.info/#g" > "$tmp"
grep -q "\"tag_name\"" "$tmp"
chmod 644 "$tmp"
mv "$tmp" "$dir/meta.json"

Caddy отдаёт этот файл как статику, а все остальные запросы проксирует на CDN:

upgrades.syncthing.gluek.info {
	handle /meta.json {
		root * /path/to/folder/syncthing
		file_server
	}
	handle {
		reverse_proxy https://release.syncthingcdn.net {
			header_up Host release.syncthingcdn.net
		}
	}
}

Переписывать ссылки на лету можно было бы плагином replace-response, но его нет в стандартной сборке Caddy, и пересобирать сервер ради одного зеркала не хотелось. Скрипт по cron проще.

Срочно надо обновить ВСЁ

Wed, 21 Oct 2026 19:19:55 GMT

17 октября 2026 года проблему обнаружил независимый ИБ-исследователь, известный под ником Wayne, который изучал публичные данные сертификатов. В своем уведомлении об инциденте специалист сообщил, что все восемь проблемных ключей были созданы в апреле 2025 года для эллиптической кривой P-384, где приватный ключ должен случайно выбираться из пространства примерно в 2^384 возможных значений.

Однако в случае eMudhra этими секретными значениями оказались числа 4, 56, 66, 115, 155, 156, 230 и 237. То есть все ключи фактически умещались в восемь бит, и атакующему достаточно было перебрать всего 256 возможных значений.

https://emudhra.we-have-a-problem.com/

Команда PHP готовит исправления сразу для двух критических уязвимостей, обе с оценкой 9,2 из 10 по CVSS 4.0, а релиз назначен на сегодня, 21 октября, в 14:00 UTC (16:00 в Амстердаме, 17:00 в Москве):

https://www.php.net/index.php#2026-10-20-1

Bedrud vs Jitsi: сравнение self-hosted сервисов видеозвонков

Tue, 20 Oct 2026 19:55:00 GMT

На моём сервере теперь работают два сервиса видеозвонков: Jitsi Meet на meet.gluek.info и Bedrud на call.gluek.info. Оба устроены одинаково, по схеме SFU (Selective Forwarding Unit, «избирательный пересыльщик»): каждый участник отправляет своё видео на сервер один раз, а сервер, ничего не перекодируя, раздаёт его остальным, причём каждому в том качестве, которое тому нужно. Разница в том, что вокруг этого медиасервера.

Из чего состоят

	Jitsi Meet (docker-jitsi-meet)	Bedrud + LiveKit
Контейнеры	4: web (nginx), Prosody (XMPP), Jicofo, JVB	2: Bedrud и LiveKit
Медиасервер	JVB, Java	LiveKit, Go
Сигнализация	XMPP через Prosody, Jicofo управляет конференциями	HTTP API Bedrud и WebSocket LiveKit
Размер образов	≈ 3,1 ГБ (JVB 1,2 ГБ, Jicofo 1 ГБ, web 570 МБ, Prosody 312 МБ)	≈ 350 МБ (LiveKit 140 МБ, Bedrud 206 МБ)
Память в простое	≈ 460 МБ (JVB 300, Jicofo 100, Prosody 33, web 11)	≈ 50–90 МБ (Bedrud 10–50, LiveKit 40)
Порты наружу	443 через прокси + UDP 10000	443 через прокси + UDP 7882 и TCP 7881
База данных	отдельной нет (Prosody хранит данные в файлах)	SQLite

Память я смотрел через docker stats на одном и том же сервере в простое. У JVB по умолчанию ещё и большой лимит: я ограничил контейнер 1,5 ГБ, и Java охотно занимает то, что ей дают.

Важная оговорка: LiveKit у меня уже был для звонков в Matrix, поэтому реальная цена Bedrud для меня — это один контейнер на 50 МБ. Если ставить его с нуля, Bedrud умеет запускать встроенный LiveKit сам, и это всё равно один процесс.

Установка и настройка

Jitsi ставится по официальной инструкции docker-jitsi-meet: скачать релиз, скопировать env.example в .env, сгенерировать пароли скриптом gen-passwords.sh, указать PUBLIC_URL, открыть UDP-порт для JVB. У меня в .env в итоге 15 непустых строк, остальное — значения по умолчанию. Подробная документация, огромное сообщество, ответы на любые вопросы гуглятся.

Проблем с установкой Jitsi у меня не было. Большой плюс — готовые клиенты: в мобильном приложении Jitsi Meet достаточно поменять адрес сервера на свой, и всё работает. К Jitsi привыкли и мои собеседники, и в целом он работает неплохо.

Bedrud — один бинарник или один контейнер с config.yaml на три десятка строк. Но проект молодой (версия 0.13), документация местами расходится с реальностью: образа нет на ghcr, обязательный параметр tokenDuration выглядит необязательным, и без него вход просто не работает. Всё это я разобрал на странице проекта, а по найденным багам написал issue. Самый неприятный для повседневной работы: гости не могут повторно зайти по ссылке в комнату, где звонок уже закончился (подробности ниже). Зато интерфейс администратора, лимиты и пользователи есть из коробки, а в Jitsi для этого пришлось бы настраивать авторизацию в Prosody.

Что умеют

	Jitsi Meet	Bedrud
Создать звонок без аккаунта	да, по умолчанию	нет, гости только заходят по ссылке
Аккаунты, админка, лимиты	через Prosody/JWT, без веб-админки	встроены: пользователи, passkey, OAuth, лимиты
Сквозное шифрование	есть (Insertable Streams)	есть флаг E2E в комнате
Комната ожидания	лобби	Gate
Запись	через Jibri (ещё контейнер с Chrome)	в разработке
Мобильные приложения	Jitsi Meet в Google Play и App Store	обещаны, но не опубликованы: в Google Play страницы нет, в релизах только десктоп (на Mac — неподписанный бинарник в `.dmg`)
Зрелость	с 2013 года, огромное сообщество	0.x, небольшой проект: последний коммит 26 сентября, приглашение в Discord на сайте недействительно

Нагрузка на 5, 10 и 20 человек

Как мерил

Участников изображали headless-браузеры Chromium через Playwright в Docker на моём MacBook. Каждый бот заходит в комнату через обычный веб-интерфейс, как живой человек, поэтому сравниваются не только серверы, но и то, как их веб-клиенты просят видео.

Сценарий как на обычной встрече, где камеры у всех одновременно не включены:

1 «презентующий»: камера показывает медленно меняющийся слайд 720p (вместо демонстрации экрана);
2 «говорящих»: камера 720p с подвижной тестовой картинкой и звук;
остальные слушают: камера и микрофон выключены.

Боты заходят по одному, после этого 3 минуты идёт звонок, и в это время на сервере каждые 3–5 секунд пишутся docker stats контейнеров и счётчики сетевого интерфейса. В таблице средние значения за эти 3 минуты. CPU указан в процентах одного ядра: на сервере их 5. Трафик — это прирост относительно фона до начала теста. В Jitsi я учитываю все четыре контейнера, в Bedrud — Bedrud и LiveKit.

Результаты

	Jitsi, 5	Jitsi, 10	Jitsi, 20	Bedrud, 5	Bedrud, 10	Bedrud, 20
CPU сервера, % ядра, среднее	18	26	45	17	26	44
CPU сервера, % ядра, пик	47	42	64	20	30	83
Память, МБ	491	550	586	134	175	248
Отдаёт, Мбит/с	1,3	3,4	7,3	14,9	33,0	60,5
Принимает, Мбит/с	1,0	0,6	0,5	6,4	6,5	7,0

Почти вся нагрузка Jitsi приходится на JVB (18 → 45% ядра, 350 → 440 МБ), а Jicofo, Prosody и web на звонок почти не реагируют. У Bedrud так же: работает LiveKit (17 → 43% ядра, 80 → 140 МБ), а сам Bedrud тратит 0,1–0,2% CPU.

Что из этого следует

Процессор одинаковый. На одной и той же встрече JVB и LiveKit берут почти одинаковую долю ядра: около 45% на 20 человек. На пятиядерном сервере это не проблема ни для одного из них.
Память у Bedrud в 2,5–3,5 раза меньше: 134–248 МБ против 490–590 МБ. Разница почти целиком в JVM: JVB с Jicofo занимают 450–540 МБ ещё до того, как начинают что-то пересылать.
Трафик отличается в 8 раз, но это разница не серверов, а клиентов. Веб-клиент Jitsi в режиме плиток просит у отправителей только нижний слой качества: три камеры вместе присылают на сервер меньше 1 Мбит/с, то есть по 200–300 кбит/с на камеру. Клиент Bedrud (LiveKit) запрашивает видео под размер плитки, а плитки при трёх камерах большие, и каждый отправитель шлёт около 2 Мбит/с. Картинка в Bedrud заметно лучше, но и каналу сервера это обходится дороже: 60 Мбит/с на 20 человек против 7 у Jitsi. Если пересчитать на мегабит пересылаемого видео, LiveKit тратит процессора в разы меньше.
Оговорка про 20 человек в Bedrud: все 20 ботов жили на одном Mac за DSL на 65 Мбит/с, а сервер отдавал им 60 Мбит/с. Канал был почти забит, а Docker на Mac занимал 4,5 ядра на декодировании видео. Возможно, без этого ограничения трафик Bedrud был бы ещё выше.
Своп на сервере во время теста не рос (около 2,8 ГБ, как и до теста), так что ни один из серверов не вытеснил другие сервисы.

Чего этот тест не показывает

Это один прогон на каждую точку, с синтетическим видео и с одной машины-клиента. Он хорошо сравнивает два сервера между собой на одной и той же встрече, но не говорит, сколько людей выдержит сервер. Для этого нужно гонять ботов с нескольких машин и с хорошим каналом.

Заодно тест выловил ещё один баг Bedrud: «постоянная» комната выключается после окончания звонка, и гости по старой ссылке в неё больше не попадут, пока хозяин её не пересоздаст (issue #212). Сначала я принял за баг и зависание ботов на «connecting», но его вызвал я сам, когда между прогонами включал комнату прямо в базе, а в LiveKit её к тому моменту уже не было.

Блокировки: какой проще заблокировать

Оба сервиса для браузера выглядят почти одинаково: страница и сигнализация идут по HTTPS на 443-й порт, а звук и видео — по WebRTC, то есть DTLS и SRTP поверх UDP. Сам WebRTC по трафику опознаётся легко: у STUN-пакетов фиксированный «magic cookie», у DTLS характерное рукопожатие. Поэтому если цензор решит резать WebRTC целиком, пострадают оба, и любой другой сервис звонков в браузере тоже. Содержимое при этом зашифровано, а адрес сервера (meet.gluek.info или call.gluek.info) виден только в SNI при подключении к сайту.

Различаются они тем, что будет, если заблокировать конкретный порт или UDP вообще:

Jitsi шлёт медиа через один порт UDP 10000. Это порт JVB по умолчанию, и правило «резать UDP 10000» пишется в одну строку. Поэтому после публикации поста я подключил Jitsi к TURN-серверу coturn, который уже стоял на сервере для другого сервиса. Если UDP не проходит, клиент идёт через TURN по TCP 3478, а если закрыт и он, то через TURN по TLS на 443-м порту (turn.gluek.info).
LiveKit принимает медиа на UDP 7882, а если UDP не проходит, клиент сам переключается на TCP 7881 (ICE-TCP). Качество по TCP хуже, но звонок состоится. Порты тоже стандартные для LiveKit, так что опознать его по ним так же легко.
Сигнализация у Jitsi идёт через XMPP по WebSocket, у Bedrud — через WebSocket LiveKit. Обе спрятаны внутри TLS на 443-м порту и снаружи от обычного HTTPS не отличаются.
IP-адрес у обоих один и тот же — адрес моего VPS. Если заблокируют его, перестанет работать всё сразу, включая сайт.

Итого: теперь у обоих есть путь, который переживает блокировку всего, кроме 443-го порта. TURN по TLS на 443-м порту снаружи выглядит как обычное HTTPS-соединение с turn.gluek.info, и отличить его можно разве что по характеру трафика. Порт 443 на сервере занят Caddy, поэтому я поставил сборку Caddy с модулем layer4: она смотрит на SNI в начале TLS-соединения и отдаёт соединения с turn.gluek.info в coturn, а всё остальное — сайтам. Тот же TURN я отдал и LiveKit: если не проходят ни UDP 7882, ни TCP 7881, клиенты Bedrud и Element Call тоже уходят на turn.gluek.info:443. Путь через TLS я проверил тестовыми соединениями, а настоящий звонок из сети, где открыт только 443-й порт, ещё не пробовал.

Итог

Если LiveKit на сервере уже есть, Bedrud почти бесплатен: два контейнера, в 2,5–3,5 раза меньше памяти, чем у Jitsi, при том же процессоре и с более качественной картинкой. Но проект сырой: за один вечер я нашёл четыре бага (ссылка на комнату, например, живёт ровно один звонок), а мобильных клиентов, которые обещает сайт, пока нет.

Я оставляю оба. Никогда не знаешь, какой из них в нужный момент сработает лучше: однажды Jitsi не запустился на холодную и подвёл меня, а второй сервис на том же сервере стоит почти ничего.

Зеркала gluek.info в i2p и tor

Tue, 20 Oct 2026 00:17:00 GMT

Данный сайт также доступен по следующим адресам:

http://glueky6orepqda262pgrwfrcvwbzpyzrcn5svgyfqin5t4vfb54q.b32.i2p http://gluektoro4irgilbx5n3lefhofqeeu3acys7a2hprk2u3o65nvzhmjyd.onion

Если будут силы, потом напишу в Проекты про подбор имени и настройку, но там вроде ничего сложного.

call.gluek.info

Tue, 20 Oct 2026 00:00:00 GMT

Видеозвонки в браузере на Bedrud: комната по ссылке, гости без регистрации. Сайт обещает ещё клиенты для Android, iOS и десктопа, но на деле их почти нет: страница в Google Play не открывается, Homebrew-тапа не существует, а в релизах на GitHub есть только десктопный клиент, причём для Mac это .dmg с голым неподписанным исполняемым файлом вместо приложения. Исходники Android- и iOS-клиентов в репозитории лежат, но готовых сборок нет. Главная особенность моей установки в том, что Bedrud не поднимает свой медиасервер, а использует LiveKit на rtc.gluek.info, который уже стоял для звонков в Matrix.

Зачем, если есть Jitsi

На meet.gluek.info у меня с июня работает Jitsi Meet, и он никуда не делся. Но это четыре контейнера (веб, XMPP-сервер Prosody, Jicofo и видеомост JVB на Java), которые в простое занимают около 460 МБ памяти, а образы весят больше 3 ГБ. На сервере, где уже работают несколько десятков контейнеров и память на счету, это заметно.

Когда для Element Call пришлось поднять LiveKit, оказалось, что на сервере теперь есть второй, куда более лёгкий медиасервер. LiveKit — это SFU на Go, тот же класс, что и JVB, только без XMPP вокруг. Оставалось найти к нему веб-интерфейс «комната по ссылке», и Bedrud подошёл: он и так построен на LiveKit и умеет работать с внешним сервером.

Сравнение по ресурсам и настройке — в отдельном посте Bedrud vs Jitsi.

Как это устроено

браузер ──https──▶ Caddy ──▶ bedrud:8090      (интерфейс, API, комнаты, пользователи)
   │
   └──wss/udp──▶ rtc.gluek.info ──▶ livekit:7880   (медиа: UDP 7882 / TCP 7881,
                                                     запасной путь: TURN/TLS turn.gluek.info:443)
                                    ▲    │
             создание комнат, токены ┘    └─ вебхуки ──▶ bedrud и lk-jwt (Matrix)

Bedrud отвечает за всё, кроме медиа: пользователи, комнаты, чат, права. Браузеру он выдаёт токен LiveKit и адрес wss://rtc.gluek.info, а дальше звук и видео идут напрямую в LiveKit
LiveKit один на всех: его же использует lk-jwt-service для звонков в Element X. Новых портов открывать не пришлось, всё медиа идёт через тот же UDP 7882. Если у клиента закрыты и UDP, и TCP 7881, медиа идёт через TURN-сервер coturn по TLS на 443-м порту (подробнее — в разделе про блокировки в посте)
В простое Bedrud занимает около 10 МБ памяти, после звонков около 50 МБ. LiveKit — 40–80 МБ, и эту память я уже тратил ради Matrix

Установка

Bedrud ставится одним бинарником или скриптом curl | bash, но у меня всё в Docker за общим Caddy, поэтому я собрал установку руками.

Образ

В документации указан образ ghcr.io/themadorg/bedrud, но на момент установки скачать его без авторизации нельзя (unauthorized). Docker-образы лежат в релизах на GitHub архивами, их нужно загрузить самому:

B=https://github.com/themadorg/bedrud/releases/download/v0.13.0
curl -fsSLO $B/SHA256SUMS
curl -fsSLO $B/bedrud-docker-alpine-amd64.tar.gz
grep alpine-amd64 SHA256SUMS && sha256sum bedrud-docker-alpine-amd64.tar.gz
docker load -i bedrud-docker-alpine-amd64.tar.gz   # ghcr.io/themadorg/bedrud:0.13.0-alpine

Обновление — то же самое с новой версией и сменой тега в compose.

Конфиг

Главное — livekit.external: true: тогда Bedrud не запускает встроенный LiveKit и не проксирует его через себя.

server:
  port: "8090"
  domain: "call.gluek.info"
  behindProxy: true
  trustedProxies: ["172.18.0.0/16"]   # Docker-сеть, где живёт Caddy
database:
  type: "sqlite"
  path: "/var/lib/bedrud/bedrud.db"
livekit:
  external: true
  host: "wss://rtc.gluek.info"        # куда подключаются браузеры
  internalHost: "http://livekit:7880" # API LiveKit внутри Docker-сети
  apiKey: "lk-gluek"                  # тот же ключ, что у lk-jwt (см. ниже)
  apiSecret: "…"
auth:
  jwtSecret: "…"                      # openssl rand -hex 32
  sessionSecret: "…"
  frontendURL: "https://call.gluek.info"
  tokenDuration: 24                   # обязательно, см. подводные камни
cors:
  allowedOrigins: "https://call.gluek.info"

Compose — один сервис в общей сети с Caddy и LiveKit, без опубликованных портов:

services:
  bedrud:
    image: ghcr.io/themadorg/bedrud:0.13.0-alpine
    container_name: bedrud
    command: ["run", "--config", "/etc/bedrud/config.yaml"]
    mem_limit: 256m
    restart: unless-stopped
    volumes:
      - ./config.yaml:/etc/bedrud/config.yaml:ro
      - ./data:/var/lib/bedrud
    networks: [caddy]
networks:
  caddy:
    external: true   # общая сеть с Caddy и LiveKit

LiveKit: общий ключ и второй вебхук

Bedrud узнаёт от LiveKit, что участник вышел или комната закрылась, через вебхуки. В конфиге LiveKit достаточно добавить второй адрес:

webhook:
  api_key: lk-gluek
  urls:
    - http://lk-jwt:8080/sfu_webhook            # Matrix
    - http://bedrud:8090/api/livekit/webhook    # Bedrud

Тонкость в том, что у LiveKit один webhook.api_key на все адреса: каждый вебхук подписывается этим ключом. А Bedrud проверяет подпись своим apiKey. Поэтому завести Bedrud отдельную пару ключей не получится: ему нужен тот же ключ, что и lk-jwt. На своём сервере это не страшно, но Bedrud при этом может управлять и комнатами Element Call.

Комнату в LiveKit Bedrud создаёт сам через API, поэтому room.auto_create: false, который стоит в LiveKit ради Element Call (чтобы комнаты на моём SFU не могли создавать пользователи Matrix с других серверов), ему не мешает.

Caddy

call.gluek.info {
	reverse_proxy bedrud:8090
}

После этого нужно зарегистрироваться (первый аккаунт я сделал через passkey) и выдать себе права админа:

docker exec bedrud bedrud --config /etc/bedrud/config.yaml user promote --email you@example.com

Подводные камни

`tokenDuration` без значения по умолчанию

Если не указать auth.tokenDuration, он равен нулю, и каждый токен входа истекает в момент выдачи (exp == iat). Вход проходит, но на любое действие интерфейс отвечает «Invalid token», через несколько секунд выкидывает на страницу входа, а при закрытой регистрации ещё и пишет, что регистрация выключена. Подпись токена при этом верная, так что искать проблему в секретах или прокси бесполезно. В примере конфига в документации tokenDuration: 24 есть, но выглядит как необязательный. Написал об этом issue #210.

Вебхуки, которые «не проходят подпись»

В логе Bedrud на каждый вход в комнату и публикацию трека пишется LiveKit webhook: invalid signature. На самом деле подпись в порядке: Bedrud разбирает JSON от LiveKit обычным encoding/json, а тот не понимает enum-поля, которые LiveKit присылает строками. В результате событие о выходе участника теряется, и он числится в комнате, пока её не закроют. От внешнего LiveKit это не зависит, встроенный присылает то же самое. Issue #209.

Ссылка на комнату живёт один звонок

Когда из комнаты выходит последний участник, LiveKit примерно через 20 секунд удаляет её у себя и присылает событие room_finished, а Bedrud по нему помечает комнату неактивной. Гость, открывший ту же ссылку позже, увидит «room is no longer active». Хозяин комнаты при входе получит предложение пересоздать её с тем же адресом. Но пересозданная комната становится приватной, и гостей в неё опять не пустит, пока в настройках не включить Public.

Галочка «постоянная комната» от этого не спасает: планировщик Bedrud постоянные комнаты не трогает, а вот обработчик room_finished выключает их так же, как и остальные. Описал это в issue #212.

Поначалу я решил, что дело в auto_create: false у LiveKit, и даже включил его. Но оказалось, что зависание на «connecting» я вызвал сам во время нагрузочного теста, когда вручную включил комнату в базе, а в LiveKit её уже не было. В обычной работе Bedrud создаёт комнату в LiveKit сам, так что auto_create можно оставить выключенным.

Единственный реальный случай, когда это мешает, — перезапуск LiveKit (например, при обновлении) посреди звонка. LiveKit держит комнаты в памяти и забывает их, не отправив room_finished. Участники не могут переподключиться, пока планировщик Bedrud примерно через минуту не погасит комнату, после чего её придётся пересоздать. Так что LiveKit лучше обновлять, когда никто не звонит.

«TLS off» в админке

На странице Overview горит красный бейдж «TLS off». Он показывает, терминирует ли HTTPS сам процесс Bedrud, а у меня этим занимается Caddy. Можно игнорировать.

Сертификат и Let's Encrypt

Блок в Caddy я добавил раньше, чем DNS-запись, а в ту же ночь у Let's Encrypt ещё и был инцидент с валидацией. Сертификат в итоге выдал ZeroSSL: Caddy переключается на него сам, если в глобальных опциях указан email. Без него Caddy ходит только в Let's Encrypt (а при ошибках — в его staging). Вывод на будущее: сначала DNS, потом Caddy, и email в глобальном блоке лучше держать всегда.

Настройки

Регистрация открыта для всех, но с ограничениями. Гости без аккаунта могут только заходить в комнаты по ссылке, создавать комнаты им нельзя: это зашито в коде, настройки нет. Почту Bedrud не подтверждает, потому что SMTP пока не настроен.

Лимиты задаются через CLI и хранятся в базе, а не в config.yaml:

B="docker exec bedrud bedrud --config /etc/bedrud/config.yaml"
$B settings set maxRoomsPerUser 3              # активных комнат на пользователя (админа не касается)
$B settings set maxParticipantsLimit 20        # участников в комнате
$B settings set maxUploadBytesPerUser 52428800 # 50 МБ файлов в чате на пользователя
$B settings set globalDiskThresholdBytes 2147483648  # 2 ГБ на все загрузки

Последний лимит нужен потому, что файлы из чата удаляются только вместе с комнатой, когда её завершают или удаляют. Если все просто вышли, комната становится неактивной, но файлы остаются навсегда. Настройка chatMessageTTLHours в админке есть, но в версии 0.13.0 ни на что не влияет. Предложил это доделать в issue #211.

При создании комнаты можно включить сквозное шифрование (E2E) и комнату ожидания (Gate), где гостей впускает хозяин.

Итог

Bedrud — молодой проект (версия 0.13, на момент установки 9 звёзд на GitHub), так что Jitsi я не выключаю. Но как второй вариант для звонков он почти ничего не стоит: при уже работающем LiveKit это один контейнер на 50 МБ и пара строк в конфигах.

matrix.gluek.info

Mon, 19 Oct 2026 00:00:00 GMT

Личный сервер Matrix на базе Tuwunel, легковесного homeserver на Rust. Мой адрес в Matrix теперь @gluek:gluek.info, написать мне можно по ссылке matrix.to/#/@gluek:gluek.info.

Зачем свой сервер, если есть matrix.org

Аккаунт @gluek:matrix.org я завёл довольно давно, чтобы читать несколько публичных групп, но активно им так и не пользовался.

Главный довод за свой сервер: в Matrix нельзя перенести аккаунт с одного сервера на другой. Часть адреса после двоеточия навсегда привязывает его к серверу, и если однажды условия на matrix.org перестанут устраивать, остаётся только завести новый аккаунт и заново собирать контакты и комнаты. А раз переносить почти нечего, лучше сделать это сейчас.

Повод задуматься дал и сам matrix.org: для бесплатных аккаунтов там появились лимиты: не больше 10 МБ на вложение и 500 МБ трафика вложений за 28 дней, а в примечании честно сказано, что лимиты будут пересматриваться. Мне этого пока хватает, но это тот же сценарий, что и с 1Password: зависимость от чужой ценовой политики.

При этом привязка к домену, а не к серверу, работает в мою пользу: сервер можно сколько угодно переносить между машинами и даже реализациями, а адрес @gluek:gluek.info останется тем же, пока у меня есть домен.

Отдельно стоит сказать про приватность: свой сервер на одного человека её почти не прибавляет. Остальные серверы федерации видят, в каких комнатах я состою и когда пишу, и на сервере с одним пользователем вся его активность — это я. На matrix.org я хотя бы терялся в толпе. Так что дело здесь в контроле над адресом и данными, а не в анонимности.

Почему Tuwunel

Эталонный сервер Synapse на Python требует PostgreSQL и заметно больше памяти, а для одного аккаунта это перебор. Dendrite фактически в режиме поддержки. Остаются потомки conduwuit на Rust: Tuwunel и continuwuity. Оба ставятся одним контейнером со встроенной RocksDB и поддерживают sliding sync для Element X.

Выбрал Tuwunel: его основной спонсор — правительство Швейцарии, разработку ведут штатные сотрудники, и для сервера, который должен прожить долго, это выглядит надёжнее. continuwuity развивает сообщество, и проект тоже живой. По возможностям они сейчас близки.

Стек

Tuwunel через Docker Compose на том же VPS, что и остальные сервисы. В простое занимает около 80 МБ памяти
Caddy в роли reverse proxy (с автоматическим HTTPS от Let's Encrypt)
Делегирование: server_name — это gluek.info, а сам сервер живёт на matrix.gluek.info. Порт 8448 и SRV-записи не нужны, федерация идёт через 443
Регистрация закрыта: аккаунт создан по одноразовому токену, после чего регистрация выключена. Новые аккаунты я могу завести вручную через админ-комнату
Бэкапы каждую ночь: контейнер на секунду останавливается, база RocksDB копируется целиком, и с неё снимаются копии вместе с остальным сервером. Подписывающий ключ сервера лежит внутри базы, так что эта копия и есть весь сервер
Обновления вручную по уведомлению в админ-комнате: скрипт сначала делает бэкап, потом подтягивает новый образ и ждёт, пока сервер пройдёт health-check
Клиенты: Element Desktop на Mac (есть в Homebrew: brew install --cask element) и Element X на Android. Возможно, ещё попробую FluffyChat

Сервер личный, но если мы знакомы и вам нужен аккаунт в Matrix, пишите: заведу. Если нет, можно поднять свой сервер, ориентируясь на этот разбор, или выбрать один из публичных серверов.

Делегирование через `.well-known`

Чтобы адрес был @gluek:gluek.info, а не @gluek:matrix.gluek.info, сервер и клиенты должны найти настоящий хост через два файла на основном домене: /.well-known/matrix/server и /.well-known/matrix/client. Tuwunel умеет отдавать их сам, если указать в конфиге:

[global]
server_name = "gluek.info"

[global.well_known]
client = "https://matrix.gluek.info"
server = "matrix.gluek.info:443"

А в Caddy достаточно прокинуть эти пути с основного сайта:

gluek.info {
	handle /.well-known/matrix/* {
		reverse_proxy tuwunel:8008
	}
	# ... остальной сайт
}

matrix.gluek.info {
	request_body {
		max_size 100MB
	}
	reverse_proxy tuwunel:8008
}

Подводный камень: двойной CORS-заголовок

По многим инструкциям для .well-known/matrix/client нужно руками добавить Access-Control-Allow-Origin: *, иначе веб-клиенты не смогут прочитать файл. Но если файлы отдаёт сам Tuwunel, он уже ставит этот заголовок, и с ручным добавлением в ответе оказываются два одинаковых заголовка. Браузеры такой ответ отвергают как некорректный CORS, хотя curl и федерационный тестер ничего подозрительного не показывают. Проверить так:

curl -sI https://example.com/.well-known/matrix/client | grep -ci access-control-allow-origin

Должно быть 1.

Проверить федерацию целиком можно через Matrix Federation Tester.

Звонки: два несовместимых протокола

Самое неочевидное во всей истории. В Matrix сейчас две разные системы звонков, и друг с другом они не соединяются.

Старые звонки 1:1 (события m.call.*) — обычный WebRTC: устройства соединяются напрямую, а если мешает NAT, идут через TURN-сервер. Их умеют Element Desktop/Web, классический Element Android и FluffyChat. Групповые звонки так не сделать (каждый соединяется с каждым), поэтому в Element они годами работали через встроенный Jitsi-виджет.
MatrixRTC / Element Call — новая схема: все участники шлют медиа на SFU-сервер LiveKit, а он раздаёт потоки остальным. Звонок 1:1 и групповой устроены одинаково, сквозное шифрование работает и в группах. Цена — ещё один сервер рядом с homeserver.

Element X умеет только новую схему. Поэтому если позвонить из FluffyChat человеку в Element X, он звонка просто не увидит, и наоборот. Обе стороны должны пользоваться клиентами с одной и той же схемой. И отдельно: на сервере без LiveKit в Element X звонки не работают вовсе, никакой TURN тут не поможет.

У себя я поднял обе:

TURN для старых звонков: coturn, который уже стоял на сервере для другого сервиса. Tuwunel выдаёт клиентам временные учётные данные к нему через общий секрет (turn_uris и turn_secret_file в конфиге). Кроме обычного порта 3478 (UDP и TCP) клиенты получают ещё turns:turn.gluek.info:443 — TURN по TLS на 443-м порту, на случай сетей, где открыт только HTTPS (как он сделан, ниже)
LiveKit для Element Call: сам LiveKit и маленький lk-jwt-service, который выдаёт токены участникам Matrix, на поддомене rtc.gluek.info. Клиенты узнают о нём из того же .well-known/matrix/client (в Tuwunel это одна строка livekit_url). Медиа идёт через один UDP-порт, так что отдельный диапазон портов не нужен. Звонок в Element X между @gluek:gluek.info и моим старым аккаунтом на matrix.org работает в обе стороны, со звуком и видео. Тот же turn.gluek.info:443 LiveKit раздаёт клиентам как запасной путь (rtc.turn_servers с тем же общим секретом), если не проходят ни UDP 7882, ни TCP 7881

Подводный камень: TURN как дыра во внутреннюю сеть

TURN по своей природе пересылает трафик туда, куда попросит клиент. Если не запретить частные адреса, то любой, у кого есть учётные данные (а с Matrix их получает каждый залогиненный клиент), может через coturn достучаться до внутренних сервисов: баз данных в Docker-сетях, localhost и всего, что не торчит наружу. Закрывается это списком --denied-peer-ip для всех частных диапазонов (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8 и т.д.), а заодно --no-tcp-relay.

Но в Docker это ломает сам TURN: в bridge-режиме ретранслятор живёт на внутреннем 172.x-адресе, и звонок, где обе стороны идут через один и тот же TURN, упирается в только что запрещённый диапазон. Помог перевод coturn в network_mode: host с явным публичным адресом (--listening-ip и --relay-ip). Тогда, правда, порты перестают пробрасываться в обход файрвола, и релейный диапазон нужно открыть в UFW.

Проверить можно утилитой turnutils_uclient из того же образа coturn: запрос к внутреннему адресу должен получать 403, а обычная ретрансляция — проходить без потерь.

TURN по TLS на 443-м порту рядом с Caddy

В сетях с жёсткой фильтрацией открыт бывает только 443-й порт. TURN умеет работать и там: по TLS, так что снаружи соединение выглядит как обычный HTTPS. Но 443-й порт у меня занят Caddy, через который работают все сайты.

Решил это модулем caddy-l4, который добавляет в Caddy обработку на уровне TCP. Он смотрит на имя сервера (SNI) в начале TLS-соединения: соединения с turn.gluek.info Caddy расшифровывает сам и отдаёт обычным TURN в coturn на порт 3478, а всё остальное идёт дальше, к сайтам. Свой TLS и свои сертификаты coturn при этом не нужны, сертификат для turn.gluek.info получает и продлевает Caddy:

{
	servers :443 {
		listener_wrappers {
			layer4 {
				@turn tls sni turn.gluek.info
				route @turn {
					tls
					proxy turn.gluek.info:3478   # coturn в host-сети, поэтому по внешнему имени, а не по имени контейнера
				}
			}
			tls
		}
	}
}

# нужен только для того, чтобы Caddy получал и продлевал сертификат;
# TLS-соединения с этим именем до HTTP-сервера не доходят
turn.gluek.info {
	respond 404
}

Модуль не входит в официальный образ, поэтому Caddy теперь своя сборка:

FROM caddy:2.11.6-builder AS builder
RUN xcaddy build v2.11.6 --with github.com/mholt/caddy-l4

FROM caddy:2.11.6
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

Цена — Caddy больше не обновляется сам вместе с тегом latest: для новой версии нужно пересобрать образ.

Раз временные логины к TURN теперь раздаёт и Jitsi, а его может открыть кто угодно, на coturn я поставил квоты: не больше ~15 Мбит/с на сессию в каждую сторону (--max-bps), не больше 16 сессий на одного пользователя (--user-quota) и 100 сессий всего (--total-quota).

botkeep.cloud

Thu, 15 Oct 2026 14:12:33 GMT

Интересный проект, который позволяет вам размещать небольших ботов (и в целом ещё несколько сервисов типа Uptime Kuma или хостинга вашего статичного сайта) бесплатно, если успеете зарегистрироваться в течение этого часа.

vault.gluek.info

Tue, 22 Sep 2026 00:00:00 GMT

Личный менеджер паролей на базе Vaultwarden. Это легковесная серверная реализация API Bitwarden на Rust, с которой работают все официальные клиенты Bitwarden: браузерные расширения, десктоп, мобильные приложения и CLI.

Почему ушёл с 1Password

До 1Password я долгое время пользовался KeePass/KeePassX, а на 1Password перешёл, когда понадобились командные хранилища. Но за последнее время накопилось сразу несколько поводов уйти.

Цена. Несмотря на обещание сохранить цену для ранних пользователей, 1Password объявил о повышении цены семейного плана с 27 марта 2026 года: с $59.88 до $71.88 в год. Потом, правда, отыграли назад, и для меня как для «Families Launch Special Plan» цена не изменилась. Но осадочек остался, тем более что по деньгам это сравнимо с арендой целого VPS.

Отказ от локальных сейфов. Поддержку 1Password 7 убрали, а вместе с ней и работу с локальными сейфами, включая синхронизацию «по воздуху» по Wi-Fi и через Dropbox. Теперь синхронизация есть только через их облако и только по подписке.

Российская карта. Когда-то я оплачивал подписку российской картой, и в какой-то момент поддержка начала волноваться: уточняли, нет ли у меня в аккаунте участников из России, Беларуси, Луганска, Донецка или Крыма. Сейчас я живу в Лондоне, но часть российских сервисов доступна только через VPN, а это повышает риск случайной блокировки аккаунта. Физическое местоположение они, надеюсь, не отслеживают… наверное.

В итоге менеджер паролей, самое чувствительное, что у меня есть, оказался в зависимости от чужой ценовой политики и чужих комплаенс-процедур. Как и в случае с git.gluek.info, проще держать это у себя.

Инстанс приватный: открытая регистрация выключена, аккаунты создаются только по приглашениям. Если мы знакомы и вам нужен аккаунт, пишите. Если нет, Vaultwarden несложно поставить самостоятельно или найти публичный сервер, например vaultwarden.com. Но учтите, что это сторонний сервис, который запустился совсем недавно и с самим проектом Vaultwarden не связан, так что доверять ему пароли стоит с осторожностью. Хотя пароли и уходят на сервер только в зашифрованном виде, метаданные (когда, с каких устройств и IP-адресов вы обращаетесь к хранилищу) тоже весьма приватная вещь.

Стек

Vaultwarden через Docker Compose с базой SQLite: пользователей будет немного, отдельный Postgres здесь не нужен
Caddy в роли reverse proxy (с автоматическим HTTPS от Let's Encrypt)
SMTP через почту на gluek.info: без него пригласить пользователя не получится, отдельной инвайт-ссылки у Vaultwarden нет
Админка /admin включена и закрыта стойким паролем, захэшированным через Argon2
Бэкапы каждые сутки через rsync, а с них дополнительно копии на внешний диск (подход 3-2-1)
Push-уведомления для мобильных приложений через официальный relay Bitwarden (регион EU): бесплатные ключи выдают на bitwarden.com/host, а через relay проходят только сигналы «пора синхронизироваться», без содержимого хранилища
Клиенты все те же, что были у 1Password: в основном приложение под Mac и расширение для браузера, приложение под Android и веб-версия на крайний случай

Из приятных бонусов: в Bitwarden встроена функция Send для быстрой отправки текста или файла по ссылке. Для этого у меня, правда, уже есть отдельный сервис Cryptex на drop.gluek.info, про него расскажу отдельно.

Подводный камень: синхронизация в реальном времени

После запуска всё вроде бы работало, но изменения, сделанные на телефоне, не появлялись на Mac, пока не нажмёшь синхронизацию вручную. Оказалось, что в Caddyfile остался блок из старых инструкций, где /notifications/hub проксируется на отдельный порт 3012. Начиная с Vaultwarden 1.29 WebSocket работает на основном порту, а 3012 больше не существует, поэтому Caddy молча отвечал 502 Bad Gateway, и клиенты теряли обновления в реальном времени.

Проверить это можно одной командой. Без токена рабочий сервер должен ответить 401 от Vaultwarden (Server: Rocket), а не 502 от Caddy. Sec-WebSocket-Key здесь не секрет, а обязательный для WebSocket-рукопожатия случайный nonce, взятый как пример прямо из RFC 6455:

curl -i --http1.1 -H "Connection: Upgrade" -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  https://vault.example.com/notifications/hub

Лечится удалением отдельного блока: весь хост проксируется на Vaultwarden одним reverse_proxy.

Для Android есть ещё одна тонкость: мобильные приложения получают изменения не по WebSocket, а через push, поэтому без настроенного relay они синхронизируются только при открытии. После включения push на телефоне нужно выйти из аккаунта и войти заново, чтобы устройство зарегистрировалось.

Перенос из 1Password

У Bitwarden есть встроенный импорт формата .1pux (это экспорт 1Password 8), но с двумя нюансами:

Все сейфы сливаются в один. У меня было около десяти сейфов, личных и общих, и импорт вывалил бы их в одну кучу. Мне нужно было разложить каждый сейф в свою организацию/коллекцию.
Вложения внутри записей теряются. Отдельные документы (категория Document) импортируются сами, а вот файлы, прикреплённые к логинам, заметкам и прочим записям, в импорт не попадают.

Для обеих проблем пришлось написать по небольшому скрипту на Python без внешних зависимостей, а позже понадобился и третий, для passkeys.

Всего переехало больше 2000 записей. TOTP-коды перенеслись без проблем, SSH-ключи я храню отдельно, а вот passkeys в .1pux не попадают вообще: их пришлось переносить отдельно, об этом ниже.

1. Нарезка экспорта по сейфам

.1pux — это обычный zip-архив с файлом export.data (JSON со всеми записями) и папкой files/ с вложениями. Скрипт собирает из одного общего экспорта отдельный .1pux на каждый сейф и кладёт туда только нужные ему вложения:

#!/usr/bin/env python3
"""
Разбивает экспорт 1Password (.1pux) на отдельные файлы по сейфам,
чтобы импортировать каждый в свою организацию/коллекцию Bitwarden.

Запуск:
  python3 split_1pux.py 1PasswordExport-XXXX.1pux
"""
import copy
import json
import sys
import zipfile

SRC = sys.argv[1]

with zipfile.ZipFile(SRC) as z:
    full_data = json.loads(z.read("export.data"))
    attrs = z.read("export.attributes")
    all_names = z.namelist()

    vault_names = [v["attrs"]["name"] for v in full_data["accounts"][0]["vaults"]]

    for target_vault_name in vault_names:
        data = copy.deepcopy(full_data)
        for account in data["accounts"]:
            account["vaults"] = [v for v in account["vaults"] if v["attrs"]["name"] == target_vault_name]

        # собрать id вложений, которые нужны именно этому сейфу
        item_blob = json.dumps(data)
        kept_files = set()
        for name in all_names:
            if name.startswith("files/") and name != "files/":
                file_id = name.split("/")[1].split("__")[0].split(".")[0]
                if file_id in item_blob:
                    kept_files.add(name)

        safe_name = target_vault_name.replace(" ", "_").replace("&", "and")
        out_name = f"export_{safe_name}.1pux"
        with zipfile.ZipFile(out_name, "w", zipfile.ZIP_DEFLATED) as out:
            out.writestr("export.data", json.dumps(data))
            out.writestr("export.attributes", attrs)
            for name in kept_files:
                out.writestr(name, z.read(name))

        items = sum(len(v.get("items", [])) for a in data["accounts"] for v in a["vaults"])
        print(f"{target_vault_name} -> {out_name} ({items} items, {len(kept_files)} files)")

Дальше каждый получившийся файл импортируется через веб-интерфейс: Tools → Import data → 1Password (1pux), с выбором нужной организации и коллекции.

2. Докачка вложений

Второй скрипт проходит по записям с вложенными файлами, находит соответствующую запись в Vaultwarden по названию и прикрепляет файлы через Bitwarden CLI (bw). По умолчанию работает в режиме dry-run, а записи, которые не удалось однозначно сопоставить (дубли названий, пропавшие файлы), выводит списком для ручной доработки.

#!/usr/bin/env python3
"""
Прикрепляет вложения из .1pux к уже импортированным записям Vaultwarden
через Bitwarden CLI (bw). Берёт только записи, у которых файлы вложены
внутрь (не Document-категория 006 — те импортируются сами).

Перед запуском:
  bw config server https://vault.example.com
  bw login
  export BW_SESSION=$(bw unlock --raw)
  bw sync

Запуск:
  python3 attach_1pux.py export_Personal.1pux            # dry-run, ничего не меняет
  python3 attach_1pux.py export_Personal.1pux --apply    # реально загрузить
  python3 attach_1pux.py export_Work.1pux --org <organizationId> --apply
"""
import argparse
import json
import os
import shutil
import subprocess
import tempfile
import zipfile

p = argparse.ArgumentParser()
p.add_argument("pux", help="файл .1pux (один сейф)")
p.add_argument("--org", help="organizationId для общих сейфов; без него — личный сейф")
p.add_argument("--apply", action="store_true", help="реально загружать (по умолчанию dry-run)")
a = p.parse_args()


def bw(*args):
    r = subprocess.run(["bw", *args], capture_output=True, text=True)
    if r.returncode:
        raise RuntimeError(r.stderr.strip() or r.stdout.strip())
    return r.stdout


def find_docs(obj, out):
    """Рекурсивно собирает все объекты с documentId (описания файлов)."""
    if isinstance(obj, dict):
        if "documentId" in obj:
            out.append(obj)
        for v in obj.values():
            find_docs(v, out)
    elif isinstance(obj, list):
        for v in obj:
            find_docs(v, out)
    return out


z = zipfile.ZipFile(a.pux)

# documentId -> путь файла внутри архива (files/<id>__<name> или files/<id>.<ext>)
archive_files = {}
for n in z.namelist():
    if n.startswith("files/") and n != "files/":
        doc_id = n.split("/", 1)[1].split("__")[0].split(".")[0]
        archive_files[doc_id] = n

data = json.loads(z.read("export.data"))
items = []
for acc in data["accounts"]:
    for v in acc["vaults"]:
        for i in v.get("items", []):
            if i.get("categoryUuid") == "006":
                continue
            docs = find_docs(i.get("details", {}), [])
            if docs:
                items.append((i, docs))

print(f"Записей с вложениями внутри: {len(items)}")

# Все записи из Vaultwarden одним запросом, фильтр по личному сейфу / организации
vault_items = [
    x for x in json.loads(bw("list", "items"))
    if (x.get("organizationId") or None) == a.org
]
by_name = {}
for x in vault_items:
    by_name.setdefault(x["name"], []).append(x)

tmp = tempfile.mkdtemp(prefix="1pux_att_")
manual = []
uploaded = skipped = 0

try:
    for item, docs in items:
        title = item["overview"].get("title", "")
        matches = by_name.get(title, [])
        if len(matches) != 1:
            manual.append(f"{title}  (совпадений в Vaultwarden: {len(matches)})")
            continue
        cipher = matches[0]
        existing = {att.get("fileName") for att in cipher.get("attachments") or []}

        for d in docs:
            doc_id = d["documentId"]
            src = archive_files.get(doc_id)
            if not src:
                manual.append(f"{title}  (файл {doc_id} не найден в архиве)")
                continue
            fname = d.get("fileName") or os.path.basename(src)
            if fname in existing:
                skipped += 1
                continue

            print(f"{'UPLOAD' if a.apply else 'DRY'}  {title}  <-  {fname}")
            if a.apply:
                dest_dir = os.path.join(tmp, doc_id)
                os.makedirs(dest_dir, exist_ok=True)
                dest = os.path.join(dest_dir, fname)
                with open(dest, "wb") as f:
                    f.write(z.read(src))
                bw("create", "attachment", "--file", dest, "--itemid", cipher["id"])
                os.remove(dest)
            uploaded += 1
finally:
    shutil.rmtree(tmp, ignore_errors=True)  # расшифрованные файлы не оставляем на диске

print(f"\n{'Загружено' if a.apply else 'К загрузке'}: {uploaded}, уже были: {skipped}")
if manual:
    print("\nПрикрепить вручную:")
    for m in manual:
        print("  -", m)

3. Passkeys через CXP и чистка дублей

Passkeys удалось перенести через Credential Exchange Protocol (CXP), новый стандарт FIDO для переноса данных между менеджерами паролей напрямую, без промежуточного файла. Вместе с паролями и TOTP он переносит и сами ключи passkeys. На Android 14+ это делается прямо в приложении Bitwarden: Settings → Vault → Import items → Import from another app, и дальше выбрать 1Password. Подробнее в документации Bitwarden.

Но CXP импортировал всё в личное хранилище, и поверх уже перенесённых записей получилась гора дублей. Встроенной дедупликации в Bitwarden нет, поэтому пришлось написать третий скрипт. Первая версия вызывала bw на каждую запись, и на двух тысячах дублей это шло очень медленно, примерно одна запись в секунду: каждый запуск CLI заново расшифровывает всё хранилище. Поэтому скрипт работает через bw serve, локальный REST API, где хранилище расшифровывается один раз, и это уже 4–5 записей в секунду. Он находит записи, созданные после CXP-импорта, и сравнивает их со старыми по названию, логину, паролю и TOTP. Точные дубли отправляются в корзину, а passkeys переносятся в старые записи, чтобы те остались в своих организациях рядом с вложениями. Новая запись удаляется, только если скрипт перечитал старую и убедился, что passkey в ней сохранился.

В итоге удачно перенеслось больше 30 passkeys. Вручную, по одному сайту, это заняло бы пару часов.

#!/usr/bin/env python3
"""
Чистит дубли после импорта через CXP (Credential Exchange) в Vaultwarden/Bitwarden.

Новыми считаются записи личного хранилища, созданные после --since.
Для каждой новой записи ищется старая с теми же типом, названием,
логином, паролем и TOTP (в личном хранилище или в любой организации):
  - нет passkey  -> новая запись отправляется в корзину (не навсегда);
  - есть passkey -> с --move-passkeys passkey копируется в старую запись,
                    результат перепроверяется, и только тогда новая
                    запись уходит в корзину; иначе — в список «вручную».

Работает через локальный REST API Bitwarden CLI (bw serve): хранилище
расшифровывается один раз, а не на каждый вызов bw, поэтому в разы быстрее.

Перед запуском, в отдельном терминале:
  export BW_SESSION=$(bw unlock --raw)
  bw serve            # слушает только localhost:8087

Запуск:
  python3 dedup_cxp.py --since 2026-09-22T22:00                    # dry-run
  python3 dedup_cxp.py --since 2026-09-22T22:00 --move-passkeys    # dry-run с passkeys
  python3 dedup_cxp.py --since 2026-09-22T22:00 --move-passkeys --apply
"""
import argparse
import json
import sys
import time
import urllib.error
import urllib.request
from datetime import datetime

p = argparse.ArgumentParser()
p.add_argument("--since", required=True, help="начало CXP-импорта, локальное время ISO (2026-09-22T22:00)")
p.add_argument("--move-passkeys", action="store_true", help="переносить passkeys в старые записи")
p.add_argument("--apply", action="store_true", help="реально изменять (по умолчанию dry-run)")
p.add_argument("--api", default="http://localhost:8087", help="адрес bw serve")
a = p.parse_args()


def api(method, path, body=None, retries=5):
    data = json.dumps(body).encode() if body is not None else None
    for attempt in range(retries):
        req = urllib.request.Request(a.api + path, data=data, method=method,
                                     headers={"Content-Type": "application/json"})
        try:
            with urllib.request.urlopen(req, timeout=120) as r:
                res = json.loads(r.read() or b"{}")
        except urllib.error.HTTPError as e:
            # bw serve сообщает об ошибках кодом 400 и JSON с message
            try:
                res = json.loads(e.read() or b"{}")
            except ValueError:
                res = {"message": f"HTTP {e.code}"}
        except (urllib.error.URLError, TimeoutError, ConnectionError) as e:
            res = {"message": f"FetchError: {e}"}
        if res.get("success"):
            return res.get("data")
        msg = str(res.get("message") or res)
        # сетевые сбои (ECONNRESET, таймауты) повторяем с паузой, остальное — сразу ошибка
        if "FetchError" not in msg or attempt == retries - 1:
            raise RuntimeError(msg)
        time.sleep(2 ** attempt)


def parse_ts(s):
    t = datetime.fromisoformat(s.replace("Z", "+00:00"))
    return t if t.tzinfo else t.astimezone()  # без зоны — считаем локальным временем


def key(x):
    login = x.get("login") or {}
    if x.get("type") == 1:
        return (1, x.get("name"), login.get("username"), login.get("password"), login.get("totp"))
    return (x.get("type"), x.get("name"), x.get("notes"))


def passkeys(x):
    return (x.get("login") or {}).get("fido2Credentials") or []


def trash(x):
    """В корзину, не навсегда. Ошибку не пробрасываем — запись уйдёт в «вручную»."""
    if not a.apply:
        return True
    try:
        api("DELETE", f"/object/item/{x['id']}")
        return True
    except RuntimeError as e:
        manual.append(f"{x['name']}  (ошибка: {e})")
        return False


try:
    status = api("GET", "/status")["template"]["status"]
except RuntimeError as e:
    sys.exit(f"bw serve недоступен на {a.api}: {e}")
if status != "unlocked":
    sys.exit(f"Хранилище в статусе «{status}» — запусти bw serve с BW_SESSION от bw unlock")

api("POST", "/sync")  # свежие данные: после прерванного запуска часть записей уже в корзине
items = api("GET", "/list/object/items")["data"]
if items and "creationDate" not in items[0]:
    sys.exit("bw не отдаёт creationDate — обнови Bitwarden CLI")

since = parse_ts(a.since)
new, old = [], {}
for x in items:
    if not x.get("organizationId") and parse_ts(x["creationDate"]) >= since:
        new.append(x)
    else:
        old.setdefault(key(x), []).append(x)

print(f"Новых записей после {since:%Y-%m-%d %H:%M}: {len(new)}, старых: {sum(map(len, old.values()))}\n")

trashed = moved = 0
unique, manual = [], []

for x in new:
    matches = old.get(key(x), [])
    pk = passkeys(x)
    if not matches:
        unique.append(x["name"])
        continue

    if pk:
        ids = {c.get("credentialId") for c in pk}
        if any(ids <= {c.get("credentialId") for c in passkeys(m)} for m in matches):
            # passkey уже перенесён прошлым запуском, осталось убрать новую запись
            print(f"{'TRASH' if a.apply else 'DRY'}  {x['name']}  (passkey уже в старой записи)")
            trashed += trash(x)
            continue
        if not a.move_passkeys:
            manual.append(f"{x['name']}  (есть passkey, запусти с --move-passkeys)")
            continue
        targets = [m for m in matches if not passkeys(m)]
        if len(targets) != 1:
            manual.append(f"{x['name']}  (passkey; подходящих старых записей: {len(targets)})")
            continue
        target = targets[0]
        print(f"{'MOVE' if a.apply else 'DRY'}   passkey  {x['name']}")
        if a.apply:
            try:
                full = api("GET", f"/object/item/{target['id']}")
                full["login"]["fido2Credentials"] = pk
                api("PUT", f"/object/item/{target['id']}", full)
                check = api("GET", f"/object/item/{target['id']}")
            except RuntimeError as e:
                manual.append(f"{x['name']}  (ошибка: {e})")
                continue
            if not ids <= {c.get("credentialId") for c in passkeys(check)}:
                manual.append(f"{x['name']}  (CLI не сохранил passkey в старую запись, новая оставлена)")
                continue
            if not trash(x):
                continue
        moved += 1
        continue

    print(f"{'TRASH' if a.apply else 'DRY'}  {x['name']}")
    trashed += trash(x)

print(f"\n{'В корзине' if a.apply else 'К удалению'}: {trashed}, passkeys перенесено: {moved}")
if unique:
    print(f"\nБез пары среди старых (оставлены, стоит глянуть глазами): {len(unique)}")
    for n in unique:
        print("  -", n)
if manual:
    print("\nРазобрать вручную:")
    for m in manual:
        print("  -", m)

P.S. ⚠️ Файлы .1pux не зашифрованы и там все пароли лежат открытым текстом. После переноса их стоит удалить (и из корзины тоже), а не оставлять в «Загрузках».

Gluek's blog

Зеркала gluek.info в Yggdrasil и Reticulum

lxmf_publish

Команды

Стек

Как это устроено

Исходный код

upgrades.syncthing.gluek.info

Как пользоваться

Это безопасно?

Как устроено

Срочно надо обновить ВСЁ

Bedrud vs Jitsi: сравнение self-hosted сервисов видеозвонков

Из чего состоят

Установка и настройка

Что умеют

Нагрузка на 5, 10 и 20 человек

Как мерил

Результаты

Что из этого следует

Чего этот тест не показывает

Блокировки: какой проще заблокировать

Итог

Зеркала gluek.info в i2p и tor

call.gluek.info

Зачем, если есть Jitsi

Как это устроено

Установка

Образ

Конфиг

LiveKit: общий ключ и второй вебхук

Caddy

Подводные камни

tokenDuration без значения по умолчанию

Вебхуки, которые «не проходят подпись»

Ссылка на комнату живёт один звонок

«TLS off» в админке

Сертификат и Let's Encrypt

Настройки

Итог

matrix.gluek.info

Зачем свой сервер, если есть matrix.org

Почему Tuwunel

Стек

Делегирование через .well-known

Подводный камень: двойной CORS-заголовок

Звонки: два несовместимых протокола

Подводный камень: TURN как дыра во внутреннюю сеть

TURN по TLS на 443-м порту рядом с Caddy

botkeep.cloud

vault.gluek.info

Почему ушёл с 1Password

Стек

Подводный камень: синхронизация в реальном времени

Перенос из 1Password

1. Нарезка экспорта по сейфам

2. Докачка вложений

3. Passkeys через CXP и чистка дублей

`tokenDuration` без значения по умолчанию

Делегирование через `.well-known`