Admin Interface

Vexillum includes a built-in admin web interface for reflector operators.

The admin interface provides a central place to manage the Vexillum runtime, mode instances, users, roles, access policies, audit logs, and account security.

Purpose

The admin interface is intended for operational management.

It helps operators avoid turning every administrative task into a direct database edit, config-file surgery, or a half-remembered command from someone’s forum post in 2013.

Access

By default, the admin interface should be treated as a private service.

A typical configuration binds the admin listener to localhost:

[admin]
listen = "127.0.0.1:8080"

Operators can then access it through one of the following:

• Local browser on the host
• SSH tunnel
• VPN
• Reverse proxy with TLS and access controls
• Private management network

Avoid exposing the admin interface directly to the public internet unless you have intentionally designed the deployment around that risk.

Dashboard

The dashboard provides a high-level view of the Vexillum runtime.

Depending on enabled features and current implementation, this may include:

• Runtime status
• Enabled modes
• Instance state
• Listener state
• Recent activity
• Administrative warnings
• Links to mode-specific management pages

The dashboard is usually the first place to check after starting or restarting Vexillum.

Your Account

Your Account section is used for your account security-related management.

This section includes:

• Username
• Session Expiry information
• Password change form
• Permissions overview

Bootstrap credentials should be rotated after initial setup. Leaving bootstrap credentials unchanged is how “temporary setup” becomes “permanent incident report.”

Bootstrap password rotation

After initial deployment, operators should rotate any bootstrap or setup password and create named administrator accounts.

Recommended flow:

1. Start Vexillum for the first time.
2. Log in using the bootstrap credentials. (u: admin, p: <bootstrap password>)
3. Rotate or disable the bootstrap password.
4. Store recovery information securely.

Access Control

User Accounts

The user accounts section manages accounts that can access the admin interface.

Operators should create named accounts for real users instead of sharing a single administrator login.

Named users make audit logs useful. Shared accounts make audit logs decorative, which is very on-brand for bad infrastructure decisions.

User management may include:

• Creating users
• Disabling users
• Updating user information
• Managing account security
• Assigning roles

Roles

Roles define groups of permissions.

Role-based access control helps operators separate responsibilities across users. This is useful for club systems, shared infrastructure, and larger networks where more than one person helps manage the reflector.

Example role types might include:

Role	Intended use
Administrator	Full operational control
Operator	Day-to-day reflector management
Viewer	Read-only access to admin status
Auditor	Access to logs and history

Actual roles and permissions should match the implementation and local operating policy.

Role Policy Editor

The Role Policy Editor defines what a role is allowed to do.

Policies should be kept as small as practical. Give users the access they need, not a ceremonial golden hammer for smashing the whole deployment.

A good policy model helps answer:

• Who can manage users?
• Who can change roles?
• Who can modify mode instances?
• Who can view audit logs?
• Who can change account security settings?
• Who can rotate bootstrap credentials?

Instances

Vexillum is built around mode instances.

A mode instance represents a configured service for a supported protocol. Operators can use instances to organize listener behavior and runtime state for each enabled mode.

Instance management includes:

• Viewing configured instances
• Checking whether an instance is enabled
• Reviewing listener information
• Inspecting mode-specific settings
• Starting from known defaults
• Separating services by protocol or purpose

For example, an operator might run three M17 instances, one YSF instance, and six VAFM instances from the same Vexillum deployment.

Audit log

The audit log records administrative activity.

Audit logs are useful for troubleshooting, accountability, and post-change review.

Operators should review the audit log when:

• A mode instance changes unexpectedly
• A user account changes
• Roles or policies are modified
• Bootstrap credentials are rotated
• Administrative access is being reviewed
• A deployment behaves differently after a change

Audit logs are especially important on shared systems where multiple people have administrative access.

Operational recommendations

For safer administration:

• Keep the admin interface private.
• Use TLS when accessing it through a reverse proxy.
• Create named accounts for each operator.
• Use roles instead of giving everyone full admin access.
• Review audit logs after major changes.
• Rotate bootstrap credentials after setup.
• Remove accounts that no longer need access.
• Back up storage before upgrades.

Troubleshooting access

If the admin interface is not reachable:

1. Confirm Vexillum is running.
2. Check the configured admin listener.
3. Confirm the port is listening.
4. Check firewall rules.
5. Check reverse proxy configuration, if used.
6. Review logs for startup or binding errors.

Useful commands:

ss -ltnp | grep 8080

journalctl -u vexillum -n 100

If the listener is bound to 127.0.0.1, it will not be reachable from another machine unless accessed through SSH tunneling, VPN, or a reverse proxy.

Current status

The admin interface is part of the active Vexillum implementation and may continue to change as features mature. Operators should review release notes and configuration examples when upgrading.