Sysop Control Panel

The launchpad for live operations. /admin/control/. Admin-only.

Sections

Services — the Service Control Center

/admin/control/ is a real-time dashboard over every systemd unit
ANetBBS runs, not just start/stop buttons. Five unit cards:

• Web + Federation (anetbbs-web)
• Terminal Protocols (anetbbs, unified telnet/SSH/rlogin)
• MRC Chat Bridge (anetbbs-mrc-bridge)
• Finger (RFC 1288) (anetbbs-finger)
• BinkP Inbound (anetbbs-binkp)

Each card shows:

• Listener port health dots — green/yellow/red per TCP (or UDP)
  port the unit owns, rolled up into an overall pill of all_up
  (green), partial (yellow, some but not all ports answering), or
  all_down (red). This is a real socket probe against each port, not
  just "is the systemd unit active."
• Live per-service CPU% / RAM / thread-count sparkline — a small
  Chart.js graph sampled continuously by a background thread, so you
  can see a service's resource trend without SSHing in and running
  top.
• Start / Stop / Restart buttons (Restart always shown; Stop shows
  only while running, Start only while stopped). The backend also
  accepts a reload action (systemd reload, for a config re-read
  without dropping connections) for units that support it. All three
  actions need sudoers permission for the account these run as — see
  deploy/sudoers.anetbbs (update.sh installs this automatically on
  every run; on a fresh install that hasn't been updated yet, it needs
  the __SERVICE_USER__ placeholder substituted with sed, not just
  copied — see Sysop Guide).
• Logs button opens a journal-viewer modal — pick how many lines
  to pull (100 / 500 / 2,000 / 5,000), refresh on demand, or download
  the log as a .txt file. Reads via journalctl, no privilege
  elevation beyond systemd-journal/adm group membership.

Above the five cards, two aggregate charts roll up CPU% and memory
(MB) across all five services on one timeline, so you can spot which
service is driving a load spike at a glance.

Live online-user counts are also broken out by protocol (web,
telnet, SSH, rlogin) rather than just a single combined total.

NodeSpy

Live terminal session list with view-screen and kick buttons. See
NodeSpy.

Online users

Web + terminal users combined, last 5 minutes. Refreshes every
5 seconds.

Sysop tools

Quick links to:

• Echomail Admin
• Doors Admin
• RSS Admin
• Files Admin
• Theme manager
• Backup
• Notification Settings — turn off any of the five
  admin-review notification kinds you don't want (they're all on by
  default)
• Scheduled Events — cron-style maintenance jobs (nodelist
  generation, DB vacuum, log rotation, InterBBS sync, and more)

Hub Management

Only present when this install is the network hub
(REGISTRY_MODE_ENABLED=true) — links into /admin/echomail/hub/:

• BinkP node management and QWK node management (add/edit/delete,
  subscribe to areas — including a Subscribe to All button per
  QWK node — reset a QWK node's high-water mark)
• The hold queue — items withheld from distribution
• Two separate node-request review queues: the QWK-only one for
  applications submitted via a BBS's own terminal wizard, and a newer
  one covering the public "apply to join this network" form
  (/join/, both BinkP and QWK) — see ANotherNetwork
• Generation & Distribution, four tabs — generate/publish the
  nodelist on demand (plus its weekly schedule), preview a QWK packet
  per node without marking it sent, TIC/file-distribution status, and
  the Join Form tab for enabling/configuring the public application
  page above

New applications on either queue send you a notification
— no need to keep checking these pages for new work.

See ANotherNetwork for what this network actually is, and
QWK / TIC Processor for the mechanics each panel is managing.

Running more than one hub identity

Almost every install has exactly one hub identity — its own
zone:net, QWK hub ID, downstream node pool, nodelist, and join form —
and never needs to think about this section at all. It exists for a
sysop whose single install is designated the hub for more than one
real network at once (own zone:net, own QWK hub ID, separate
downstream node pools) rather than running a second physical install
per network.

• Hub Identities (/admin/echomail/hub/identities/) is the CRUD
  for these — name, URL slug, QWK Hub ID, BinkP zone/net/hub-node,
  nodelist metadata. Exactly one identity is flagged default; every
  existing single-hub install's one identity is that default, created
  automatically, so upgrading changes nothing until you deliberately
  add a second one.
• Once a second identity exists, BinkP/QWK node forms grow a Hub
  Identity picker, node/request lists grow an Identity column,
  and the join form gets a second URL: /join/<slug>/ alongside the
  default /join/. Each identity's nodelist is served separately too
  (/admin/echomail/hub/nodelist/<slug>).
• BinkP auth resolves a downstream node's identity automatically once
  matched by address/password — it never rejects a connection over
  identity resolution (fails open to the default identity, logged, if
  something's misconfigured), and stamps outbound mail with that
  identity's own AKA so two identities' peers never get cross-stamped
  mail.
• The terminal (tUI) only ever manages the default identity —
  QWK Node Requests and the node-application wizard have no identity
  picker by design (same reasoning as BinkP/QWK peer node CRUD above:
  many fields, edit on web). Use the web admin for every identity
  beyond the first.

See also

• NodeSpy
• Sysop Guide
• Notifications