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.