rust-xmpp/docs/LOGGING.md

Журнал сервера и диагностика авторизации — 0.7.4

После сборки/перезапуска строка starting/ready должна показывать 0.7.4. Это позволяет проверить, что запущен новый binary/container image. Без настройки журнал пишет info/warn/error в stderr (виден в Docker logs).

Для диагностики одной попытки входа добавьте в Lua-конфиг:

log = { debug = "*console" }
log_format = "json"

В JSON-конфиге это поля global.log = {"debug":"*console"} и global.log_format = "json". Обычный текст: log_format = "plain". debug = true включает debug по умолчанию, если log не задан. Настройки наследуются из global, локальный log VirtualHost имеет приоритет.

Файлы в стиле Prosody:

log = {
    info = "/var/log/prosody/rust-xmpp.log";
    error = "/var/log/prosody/rust-xmpp.err";
    debug = "*console";
}
log_format = "plain"

Каталоги должны существовать и быть доступны UID процесса. Файлы открываются append с правами 0600. Level-map включает указанный уровень и старшие уровни. Explicit sinks поддерживают диапазон и точный набор уровней:

log = {
    { to = "file"; filename = "/var/log/prosody/debug.log";
      levels = { min = "debug"; max = "warn" } };
    { to = "console"; levels = { "error" } };
}

levels = "warn" в explicit sink — только warn, как у native loggingmanager. log = "*console" и log = { "*console" } включают debug и старше. Дополнительное сокращение runtime log = "debug" также пишет debug в консоль. Вся строка JSON/plain записывается под общим mutex, ID не смешиваются.

Файлы ротируются внешним logrotate: после rename отправьте процессу SIGHUP. Журнал переоткроет destinations и запишет logs-reopened. При ошибке переоткрытия старые файловые дескрипторы сохраняются. SIGHUP здесь не означает горячую перезагрузку конфигурации или Lua-модулей. Автоматической ротации и retention нет. Native syslog sink, mixed Lua tables, timestamp templates и произвольные plugin sinks пока не реализованы.

Как собрать одну попытку

В JSON есть timestamp, level, module, connection, event, fields. connection — случайный ID одного transport, не SM resume token. Поля в fields — массив {key,value}, который можно преобразовать через jq from_entries. Проследите один ID от connection-open до connection-closed:

1. connection-open: host, transport, peer.
2. tls-established: фактическая версия TLS и cipher.
3. sasl-features: объявленные механизмы, CB-типы, account_hash и SSDP.
4. sasl-attempt: номер попытки, механизм, SASL1/SASL2.
5. account-lookup: нормализованный user, hash и состояние записи.
6. sasl-challenge, затем auth-success либо sasl-rejected.
7. resource-bound/session-resumed, затем connection-closed.

При закрытии есть phase, reason, duration_ms и io_kind. Если клиент отключился после challenge, сервер видит только phase=sasl-client-final и disconnect; его внутреннюю причину (например, локальное отклонение SSDP) сервер узнать не может. Для этого потребуется клиентский журнал. Для HTTP adapter peer помечается not-forwarded: внутренний duplex не получает адрес HTTP-запроса.

Событие/причина	Что проверять
account-lookup: missing-or-disabled	Правильный host, data_path/volume, наличие и enabled-состояние аккаунта
account-record-invalid	Lua account record повреждён или не поддержан
account-hash-or-record-invalid	stored/server key length и настроенный SHA-1/SHA-256 должны соответствовать
invalid-client-proof	Proof не проверилась: пароль, устаревшие credentials либо несовместимый расчёт клиента; это не доказательство конкретно неверного пароля
channel-binding-mismatch	Выбранный CB не соответствует данному TLS-сеансу/сертификату
channel-binding-downgrade-detected	Клиент отправил y при доступном серверном CB
mechanism-not-offered	Клиент выбрал механизм, которого нет в sasl-features
invalid-authzid	Authorization identity не совпадает с нормализованным владельцем
client-aborted-after-challenge	Клиент явно отменил обмен; wire-ответ aborted
inline-request-malformed	Ошибка Bind2/resume, поле detail уточняет класс
bind-rejected/resource-conflict	Авторизация прошла, проблема уже на этапе ресурса

Дополнительно пишутся listener-ready, resource-replaced, session-disconnected (removed/hibernating и unacked count), session-expired, maintenance-failed, базовые открытия/закрытия входящих S2S и shutdown-requested. Это начальное покрытие операций, не полная замена всех журналов модулей Prosody.

В журнал не передаются пароли, соль/ключи, SASL base64, nonce/proof, resume/push токены и XML/тела сообщений. Имена аккаунтов и peer-адреса присутствуют для диагностики, как в Prosody. Дополнительный фильтр редактирует sensitive field keys; escaping исключает вставку новых строк/control characters в запись.

Нужен фрагмент одной неуспешной попытки Conversations/monocles, включая version и перечисленные события. До получения этого фрагмента причина конкретного оставшегося отказа на вашей установке не установлена.

Изменения 0.7.1

Одинаковые console destinations (включая aliases) и одинаковые строки путей файлов объединяются с union уровней; overlapping rules не создают дубликаты. Разные destinations получают независимые копии записи согласно своим уровням.

sasl-attempt теперь записывается до inline validation. sasl-inline-options содержит только requested/available flags без payload. Необъявленный cached Bind2/SM логируется как inline-request-ignored с причиной bind2-disabled или sm-disabled и fallback=post-auth-stream-features. Это не ошибка пароля. Malformed enabled inline extensions сохраняют rejection и более точный detail.

PEP/PubSub в 0.7.2

INFO pubsub-iq-result содержит классифицированные action/node_kind/status/condition, precondition_not_met и счётчик deliveries. Для disco — pep_identity, persistent_items, publish_options. Идентификаторы устройства/элемента/запроса, полные имена узлов и payload не печатаются. WARN iq-dispatch-failed содержит безопасный io_kind. Значение deliveries не доказывает получение клиентом. Интерпретация ошибок и проверка после обновления — PEP-DIAGNOSTICS.md.

Содержимое результата PEP в 0.7.3

target_scope классифицирует цель запроса без её адреса. У successful items result items_count — число непосредственных item, first_content_kind — известный класс первого payload или none/other/nested-item, first_device_count — количество непосредственных device в распознанном списке первого item. Никаких значений device ID или bundle bytes. Это структура XML, не проверка валидности ключей, доверия или числовых ID. Для других операций этих счётчиков нет. implicit означает отсутствие to; сам по себе он не утверждает выбор аккаунта.

HTTP и PEP0.7.4

HTTP diagnostics: listener-ready, connection-open, tls-established, request-complete route/status, connection-closed phase/reason. Routes ограничены websocket/bosh/other; raw URLs, queries, Origin/headers/bodies не пишутся. Для подключения Converse: CONVERSE-WSS.md.

PEP IQ: device_protocol legacy/omemo2/other, valid_device_count и invalid_device_count. notification-generated: content_present и такие же счётчики локально созданного сообщения ДО routing, не подтверждение доставки. ID/JID/ключевые данные не добавляются. Подробности — PEP-DIAGNOSTICS.md.