ejabberd / XMPP integration

pyobs modules that use the XMPP comm layer (pyobs.comm.xmpp.XmppComm) connect through an ejabberd server, usually co-located on the same host as pyobs-web-admin itself. This app can optionally talk to that ejabberd instance directly – first read-only (connection status), and, building on that, with write actions (account management) too.

This closes two visibility gaps this app doesn’t otherwise cover:

• Process running ≠ XMPP connected. A module’s process can be alive (the existing status check passes) while its XMPP session is stuck reconnecting after a network blip – invisible without this integration.

• Config vs. reality. A module’s comm.user might not even be a registered XMPP account at all (typo, stale config, account never created) – a distinct failure mode from “not connected right now.”

Both pieces are gated behind EJABBERD_ENABLED and are entirely absent from the UI – not just hidden – when it’s off.

• Read-only status integration
  • Enabling it
  • Where it surfaces
  • Data layer
  • ejabberd-side configuration
  • Security model
  • One shared server, hub-aware
• XMPP user management
  • Where it surfaces
  • Confirmation UX
  • Shared comm.user handling
  • Transport: ejabberdctl, not mod_http_api
  • Deployment: a sudoers rule for ejabberdctl
  • Security note