Зайдя по случаю проверить срок истечения VPS’ки, на которой у меня крутятся мои проекты, обнаружил, что у них появился некий акционный тариф: 2 ядра, 4 ГБ памяти и чуть больше (50 ГБ) диска. Подал заявку – “перевод возможен”. Как выяснилось, на лету это не делается и надо было ребутнуть сервер. Договорились с саппортом за время – хотелось видеть, что все поднимется.
Дождался, напоследок сделал снимок:
rain@vps1nl:~$ uptime
09:14:01 up 1443 days, 21:29, 18 users, load average: 0.31, 0.34, 0.38
Да, смена эпохи: сервер молотил нон-стоп с того самого времени, как мне пришлось вынести все проекты на VPS. Пережил несколько обновлений системы – кажется, с Debian 9 до Debian 11, но так и оставался на старом ядре. Не сильно хорошо, конечно, но как-то не доходили руки. Ну вот и повод нашелся.
Система успешно поднялась уже на новом ядре (в принципе, до того я тестировал копию системы на домашней машинке) – кроме IPv6 и забытого правила в iptables. Правило добавил, а с IPv6, как выяснилось, был оставлен конфиг сетевого интерфейса под первоначальное именование. В итоге для “eth0” конфигурация фейлилась (потому что настройки уже были применены) и адрес не назначался. Уж не знаю, как я упустил этот момент.
Так или иначе, больше ядер, больше памяти, и – +10 ГБ в виде отдельного диска. Пока так и не подключил его никуда, места хватает.
Система перестала активно свопиться и постоянно гонять данные в ZRAM, нагрузка ощутимо снизилась:
Перестали постоянно жаться данные пула MySQL и процесса ejabberd’а:
С ejabberd’ом – начинаю понимать любителей Prosody: пока работал сканер серверов – потребление чуть выросло, но после работы оперативку вышло хорошо сжать и он вернулся к изначальному объему. А сейчас жать не надо – и он висит на 170 метров.
Дал чуть больше памяти под memcached, а также решил развернуть Spectrum2 (давно уже висит в Todo, но памяти особо не было под эксперименты) и наконец-то обновить Nextcloud.
Обновление последнего откладывалось хотя бы потому, что в требованиях у данного изделия размер памяти от 128 МБ и выше (а рекомендуемый объем – от 512 МБ). Хотя все остальные проекты вполне обходятся 64 МБ. Так что “просто так нажать кнопочку и обновиться” могло привести к грустным результатам.
На сейчас кнопочка просто отказалась работать даже с 256 МБ памяти – updater писал, что он “на шаге 5-м” и предлагаемые обновления страницы “чуть позже” – ни к чему не приводили.
Как выяснилось, моя 24-я версия – уже неподдерживаемая. Совсем-совсем. Даже с обновлением до минорной версии скрипт не справился. Со свежими же версиями в минимальных требованиях был уже PHP8.2! При том, что в 11-м Debian’e только 7.4, а 12-й, где был этот 8.2, вышел не так уж давно. Даже 8.0 объявлен устаревшим – “PHP8.0 is deprecated and will be removed in Nextcloud 28.”
Ну что ж. Последняя версия, которую можно использовать с 7.4 – это Nextcloud 25. На Debian 12 перейду, наверное, когда к нему появится новый ejabberd в репозиториях. Благо, NC 25 пока в поддерживаемых и обновиться дальше не составит труда.
А сейчас пришлось найти “ручной” вариант обновления. Тут все прошло довольно гладко: скопировал data, config/config.php и несколько приложений из apps, зашел в админку, а дальше оно поделало остальные шаги. Те же шаги, что не смогло сделать – предложило сделать командами в консоли, что я и сделал. Пара приложений из скопированных оказалась отключенными, но я с ними не разбирался. Уменьшил до минимального разрешенный объем памяти и на этом обновления закончились.
Дошли руки и до Spectrum’а. Установка по инструкции на сайте не вызвала проблем – пакеты даже для Debian 12 делаются под Debian 11. В свою очередь, в репозитории на момент установки не было последней версии транспорта. Но в последней вроде ничего критичного не появилось, так что пока не важно.
Не сказать, что все моменты хорошо документированы, но с основным разобрался. В /etc/spectrum2/transports создаем конфиги под каждый нужный транспорт, который будет обслуживаться Spectrum’ом. Каждый транспорт может работать от своего пользователя, но их придется создать вручную – а также проверить в дальнейшем права на нужные файлы и каталоги (/var/log/spectrum2/ и /var/lib/spectrum2/ и /var/lib/spectrum2_manager/database.sql). В конфиге описываем фронтэнд, нужный протокол, путь к плагину и так далее. Также ставим правильные идентификаторы транспорта согласно ссылке в примере – как я успел заметить, многие ленятся это делать и есть множество серверов, где, например, telegram-транспорт значится как xmpp-транспорт.
Конфиг же под spectrum2_manager в штатной поставке отсутствовал вообще. Пришлось скачать его из git’а, найдя упоминание об этом в сети. Фактически, там описание пути к другим конфигам (в transports), пароля и адреса веб-интерфейса и путь к базе. Веб-интерфейс не особо полезен – чуть поигрался и бросил. А вот плагином для Munin’а я воспользовался – но его тоже пришлось скачать из git’а.
В целом – все запустилось и начало работать. Прописал для xmpp-транспорта аккаунт со своего нового домена – тот успешно подключился. Однако надо будет попробовать еще “Swiften backend” – пишут, что он потребляет меньше памяти, чем libpurple.
Telegram тоже успешно подключился. Разрешение на модификацию ростера решил не давать – тот пытался насыпать туда около 80 контактов, которые болтались у меня где-то в архиве. В итоге одиночные контакты добавлял при получении от них сообщения. А чаты доступны через “Браузер сервисов”.
Попутно в конфиге транспорта из отсутствовавших там опций прописал web_directory и web_url – это для того, чтобы отправляемые пользователями картинки, аудиозаписи и прочие медиафайлы складировались локально и отдавались веб-сервером, после чего jabber-клиент уже сможет их получить.
Проблемы в итоге было только 2:
- все сообщения маркировались как прочитанные во всех чатах даже тогда, когда я был оффлайн.
- транспорт кинулся скачивать все доступные медиа от всех контактов. В итоге /var/lib/spectrum2/ быстро разросся до 3,5 ГБ. Насыпало в том числе и в объявленный в web_directory каталог.
Оба момента не особо юзабельны. Первое неудобно для пользователей (и это то, чего не хватает в jabber’e), ибо не позволяет следить за непрочитанными сообщениями. Особенно если клиентов больше одного. Второе напрягало уже меня лично, ибо место на VPS’ке начало активно заканчиваться – а что будет, если разрешить пользоваться транспортом всем подряд?
И вот тут проявились все недостатки отсутствия документации. Информацию приходилось выгребать по крупинкам из github’а, из исходников и разных issue. Плюс не так давно была смена используемых библиотек и найденные решения не всегда подходили к актуальной.
Так или иначе, на пока решил обе проблемы так: в /var/lib/spectrum2/telegram.jabberworld.info/accounts.xml для моего номера добавлены 2 опции:
<setting name='read-receipts' type='bool'>0</setting>отключает отправку уведомлений о прочтении вообще.<setting name='media-size-threshold' type='int'>1</setting>лимитирует ЧТО-ТО. Я пока не знаю, общий ли это объем или максимальный размер архива. И в каких он единицах. В примерах ставили 8192. А в исходниках дефолт в 32. На первое – напрашивается общий размер архива в МБ. На второе – размер на каждый отдельный файл. Поставил “1”. Архив ощутимо почистился, проблема спала. Однако из того, что осталось – есть видео больше 1 МБ – т.е., не похоже, что это лимит на 1 файл. Ну и общий размер архива тоже, очевидно, превышает этот объем.
В общем, пока разбираюсь. Написал вчера в конференции разработчиков транспорта – xmpp:spectrum@conference.spectrum.im?join, но полезной информации пока не получил. Кроме того, хотелось бы добавить эти опции глобально, а не только для моего номера – вот уже после этого можно было бы разрешить регистрироваться и другим пользователям.
Итак, update.
media-size-threshold я выкинул вообще, он не при делах. Возможно, им в каких-то случаях действительно можно будет отыгрывать автозагрузку медиа, но мне это не надо.
Глобально задать read-receipts можно в файле /etc/spectrum2/transports/telegram.jabberworld.info.cfg секцией вида
[purple]
read-receipts=0
При этом, если задать опцию, перезапустить транспорт и сделать (несколько раз) grep -v last-message-chat /var/lib/spectrum2/telegram.jabberworld.info/accounts.xml – то можно увидеть, как файл переписывается и глобальная опция появляется там. В целом, в accounts.xml мешанина состояний: куча last-message-chat (т.е., я так понимаю, маркер последнего то ли прочитанного сообщения, то ли последнего полученного сообщения) и вместе с ними – общие настройки аккаунта, как то: включен/выключен транспорт, оставаться ли подключенным (кстати, эти 2 опции доступны через ad-hoc) и, в том числе, уведомление о прочтении (а вот это уже добавить можно только вручную).
Самое интересное выяснилось позже. Если вернуть опцию в 1 (дефолтное значение – т.е., ее можно просто убрать), то транспорт начинает через какое-то время порциями скачивать медиафайлы со всех чатов. Непонятно, почему, но в целом – он как бы “читает” все доступные сообщения, в том числе сообщения с медиа, для чего и получает их контент. При этом, фактически, медиафайл нигде не фигурирует – я даже не подключен в джаббере в чат, для которого скачивается файл.
В целом, с этой опцией на сейчас транспорт ведет себя более-менее пристойно. Без скачивания медиа в том числе не растет потребление памяти. Пока единственный косяк – мне не передаются видеофайлы. Update: таки передаются. Значит, косяк был только с какими-то отдельными разновидностями видеосообщений (может, gif или что-то такое).
Файлы пока решил вручную не удалять – в первом случае, когда было скачано несколько ГБ данных, после добавления опции в accounts.xml они через время сами вычистились (частично, правда).
Насчет секции [purple] в конфиге транспорта – поверхностно она описана в документации. Я так понимаю, ключевой момент – это “Some libpurple protocol plugins allow setting configuration variables. Spectrum 2 passes every variable set in purple section to libpurple library.”. Т.е., набор опций в данном случае зависит от плагина. И read-receipts передается tdlib-purple (protocol=telegram-tdlib в конфиге -> предоставляется пакетом libpurple-telegram-tdlib -> В описании пакета: Homepage: https://github.com/ars3niy/tdlib-purple). В свою очередь опции в нем можно глянуть по ссылке. Вменяемого списка опций отдельно я не нашел.
Так или иначе, передаваемые параметры зависят от плагина на бэкенде и их надо выискивать в каждом конкретном случае отдельно. Несколько примеров есть по ссылке на документацию выше. Еще примеры:
- https://iamsan.ru/unix-like/ejabberd – тут в примере в конфиге есть секция features. Но больше такое нигде не встречал.
- https://discourse.igniterealtime.org/t/help-setting-up-openfire-with-spectrum-gojara/78645/5 (архивы в аттаче)
Из найденного методом тыка: опция admin_jid (есть в мануале по последней ссылке) – это возможность отправить сообщение spectrum2_manager. Я поначалу долго пытался найти новые команды в ad-hoc или что-то в браузере сервисов. На деле – просто пишем команду транспорту в ростере. Например, used_memory.
Еще из исследований: да, бэкенд на swiften потребляет чуть-чуть меньше памяти – буквально на мегабайт или около того. Но я не так долго его гонял, поэтому сложно сказать, нет ли там каких-то проблем в дальнейшем. В целом, Swift не особо развивается – последний коммит аж в 2020. Но то же самое можно сказать и про libpurple, в принципе. В итоге я все же выбрал Swiften, потому что тот хотя бы поддерживает уведомления о доставке сообщений.