Архив рубрики: Системное администрирование

Debian 13, Ollama + OpenwebUI и Fluux Agent: заводим персональный AI в Jabber

Первый раз щупаю эту тему.

В целом, не так давно на слуху появился jabber-клиент Fluux Messenger – примечателен тем, что от Process One, разработчиков одного из самых популярных jabber-серверов. Как минимум, находится среди их репозиториев.

А еще там появился Fluux Agent. Роадмап многообещающий: на сейчас он уже может выступать интерфейсом к Ollama или работать с “облачными” сервисами; может работать 1 на 1 или через конференцию; выступать в качестве бота или компонента сервера. А в будущем планируется возможность сделать общение между такими ботами – федеративную AI-сеть.

Идеей заинтересовался; возможностью попробовать запустить локального AI-агента и посмотреть, на что оно вообще годно – тоже. Подсобрал по разным уголкам дома железо и решил развернуть все на нем. В ход пошла старая основа от NAS’а – Athlon 740 и 32 ГБ оперативки с той же материнкой, на которой все было установлено. А в качестве GPU-основы для вычислений – пара видеокарт от майнинг-ригов. Самыми мощными у меня в хозяйстве были Nvidia 1080TI с 11 ГБ памяти, пару из них и задействовал.

Читать далее Debian 13, Ollama + OpenwebUI и Fluux Agent: заводим персональный AI в Jabber

Nextcloud и отправка почты

Наконец-то спустя долгое время наткнулся на решение проблемы отправки почты через простенький локальный почтовик. Что-то “сломали” или переделали несколько версий назад, с тех пор попытка отправки тестового письма в веб-интерфейсе выдавала ошибку. Полез в логи – при настройке None/StartTLS NC таки ломится на почтовик со StartTLS, после чего обламывается.

Закидываем в config/config.php такое:

  'mail_smtpstreamoptions' =>
  array (
    'ssl' =>
    array (
      'allow_self_signed' => true,
      'verify_peer' => false,
      'verify_peer_name' => false,
    ),
  ),

ejabberd и инвайты

Тема Easy Onboarding вполне активно развивается и в последних версиях ejabberd (26.01/26.02) появилось создание учетных записей по приглашениям: добавлен mod_invites, а в штатной поставке сделана landing-страница, с помощью которой новички могут выбрать себе клиент и перейти к регистрации.

Общий смысл в том, что более опытный – имеющий учетную запись – пользователь берет на себя придумывание Jabber ID и разрешает регистрироваться другу на том сервере, которым пользуется сам. Пароль обычно в опробованных клиентах генерируется. Т.е., вся регистрация у новичка сводится к паре кликов “далее”.

У себя поделал красивости в стиле субдоменов “Join ${DOMAIN}” (например, https://join.jabber.name), куда идут ссылки приглашений – а также туда смотрит и штатная веб-форма регистрации, которую на сейчас не использую.

Пока остается один нерешенный момент: у меня в mod_register использовался параметр redirect_url, чтобы любая попытка регистрации из клиента вела на веб-форму. С инвайтами вылез косяк – редирект блокирует завершение регистрации. Тикет уже заведен – надеюсь, в следующей версии ejabberd поправят.

Debian 13, lighttpd и симлинки

Просто заметка. После обновления Debian с 12 до 13 на одном из хостов отвалилась работа lighttpd – индексы отдает, а картинок нет. Картинки в подкаталогах, сделанных симлинками. server.follow-symlink = "enable" должно быть и дефолтно включено, и руками добавлял. Не помогает. Сервер просто перестал ходить по симлинкам, отдавая 404. Откат версии веб-сервера (при том же конфиге) решил проблему. Где-то по пути поломалось:

lighttpd:
  Установлен: 1.4.69-1
  Кандидат: 1.4.79-2

Причесываем систему на HP 6930p

Обновил как-то систему на своем старом HP 6930p до Debian 13, начались странности – не стартует графика. В lsmod 2 модуля для графики – radeon и amdgpu. Ок, заблеклистил amdgpu. Не особо помогает. Сейчас решил чуть больше покопать, плюс поделать оптимизации.

Читать далее Причесываем систему на HP 6930p

System is booting up. Unprivileged users are not permitted to log in yet

Решение вопроса с невозможностью логина по sshd при незавершенной загрузке системы в случае, даже если сеть и sshd запущены:

https://unix.stackexchange.com/questions/487742/system-is-booting-up-unprivileged-users-are-not-permitted-to-log-in-yet

Добавляем в

/etc/pam.d/sshd

auth [default=ignore success=1] pam_succeed_if.so quiet user ingroup adm

перед “auth requisite pam_nologin.so”

Home Assistant, уведомления и логика автоматизаций

Еще один баг, на этот раз со стороны Home Assistant. В последнее время решил хоть для чего-то начать использовать купленный на Али пару лет назад планшет Cubot TAB 20. Накатил туда Android-приложение Home Assistant, поставил его вместо ланчера (удобно, кстати, сделали – такой себе kiosk-mode из коробки), стоит теперь постоянно включенный. Для нескольких существующих автоматизаций решил сделать уведомления – пусть планшет подает звук, если кто-то звонит в ворота или если закончилась стирка. И поначалу вроде даже работало, но…

Сегодня заметил, что логика “звонка в ворота” сломана. Стоит сказать, что у меня на звонок стоит уведомление в джаббер, а дальше идет минутная пауза – т.е., не важно, как часто гость жмет кнопку, сообщения я буду получать лишь раз в минуту. Сейчас между сообщением в jabber и паузой добавилось еще уведомление на планшет. И – пауза перестала работать. При этом у меня на планшете нет никаких уведомлений, зато сообщения в джаббер могут идти как угодно часто. При попытке запуска уведомления на планшет вручную (в редакторе автоматизации) ничего не происходит. В другом случае (в уведомлении про стирку) получил сообщение, что устройство не подключено к локальному пуш-сервису (или как-то так). Так или иначе, проблема с одним “блоком” в автоматизации приводила к ее “вылету” и до паузы дело просто не доходило – появлялась возможность повторного запуска процесса целиком.

HA у меня не самый новый – 2024-го года, может в более свежем что-то и пофиксили, но проверить пока не могу.

esphome 2025.10.0 ломает связь с HA

Не было печали – апдейтов накачали.

Поставил свежий esphome – при прошивке девайсов (в моем случае на базе esp8266) при подключении к Home Assistant получаем

[D][api:160]: Accept 192.168.1.111
[D][api.connection:1383]: Home Assistant (192.168.1.111) connected
[W][api.connection:1880]: Home Assistant (192.168.1.111): Reading failed CONNECTION_CLOSED errno=11

Даже если удалить / добавить девайс со стороны HA – не помогает. Сам девайс видится (передобавить его можно), но при этом список объектов не передается. При этом в веб-интерфейсе устройства все в порядке.

Решается откатом на прошлую версию и прошивкой девайса с этой версии:

pip install esphome==2025.9.3

Со стороны HA ничего менять и передобавлять не надо.

Продолжаем наблюдение.

lm-sensors и Asrock A520M-ITX/ac

В последние несколько дней навожу порядки на “большом” домашнем сервере:

  • Обновил domU с сервером статистики. На самом деле – раскатал новую систему и мигрировал данные, так как пришлось бы последовательно апгрейдить Debian 9 -> Debian 13. Реально, но в чистовой установке будет меньше мусора, да и Nagios за это время сменил мажорную версию и простого апдейта не получилось бы.
  • После чего подобавлял кое-где munin-node и мониторинг хостов в Nagios’е: наконец-то убрал заглушку “return-ok” в мониторинге хоста и теперь карта красиво подсвечивает неработающие “ветки”, а также получаю меньше писем, если отвалился корневой узел.

Глаз зацепился в том числе и за подсвеченный красным раздел sensors в munin’е. Честно говоря, никогда не обращал внимания на ALERT’ы в выводе sensors, что-то показывает – и ладно.

Во-первых, поисключал явно нерабочее. Помогла эта ссылка. Дальше – больше: в ряде сенсоров (прежде всего – напряжения) были не прописаны минимальные и максимальные значения (либо было что-то неадекватное) – например, даже при корректном значении измерителя линии 3.3В в минимальных и максимальных значениях стоял ноль и датчик выдавал ALERT. В итоге чуть расширил свой кастомный конфиг для lm-sensors/etc/sensors.d/local.conf. В целом, синтаксис оказался достаточно простым: описываем секцию, обозначая чип или маской, или точным именем, дальше описываем то, что хотим сделать с опциями отдельных сенсоров, которые можно посмотреть по sensors -u.

/etc/sensors.d/local.conf

# https://superuser.com/questions/1828051/how-to-exclude-sensors-from-output
chip "nct6792-*"
        ignore  temp1
        ignore  temp4
        ignore  temp5
        ignore  temp6
        ignore  temp8
        ignore  temp9
        ignore  temp10
        ignore  in1
        ignore  in4
        ignore  in5
        ignore  in14

        set temp3_max 75
        set temp3_max_hyst 70


# +/- 5% для линий, которые на 3,3В
        set in2_min 3.3 * 0.95
        set in2_max 3.3 * 1.05
        set in3_min 3.3 * 0.95
        set in3_max 3.3 * 1.05
        set in7_min 3.3 * 0.95
        set in7_max 3.3 * 1.05
        set in8_min 3.3 * 0.95
        set in8_max 3.3 * 1.05

# Что-то непонятное. Задал диапазон или 0-1В, или 1-2В.
        set in9_min 1
        set in9_max 2
        set in12_min 1
        set in12_max 2
        set in13_min 1
        set in13_max 2
        set in10_min 0
        set in10_max 1
        set in11_min 0
        set in11_max 1
        set in6_min 0
        set in6_max 1


# Пара SSD. Адрес может смениться, если менять слоты
chip "nvme-pci-0b00"
        ignore  temp3
        set temp1_min 0

chip "nvme-pci-0c00"
        set temp1_min 0
        set temp2_max 100
        set temp2_min 0
        set temp3_max 100
        set temp3_min 0

[свернуть]

В тех сенсорах, в которых что-то показывалось, но непонятно, к чему оно относится (если они вообще подключены на плате) – просто задал широкий диапазон значений, чтобы не ругалось.

Еще одна полезная команда – sensors -s от рута, чтобы применить изменения в конфиге.