Chapter 26 • Guide 27 of 31
System settings
System settings are administrator-only.
Overview
Review server identity and capability cards, open the relevant settings section, and see whether key services are ready. The overview also offers the protected server-reboot workflow. Reboot requires the current password, MFA when enabled, and typing REBOOT ; it interrupts all hosted services and the current panel session.
Server settings
Set the operating-system hostname and configure the dedicated secure domain used to open Core Panel. Core Panel configures Nginx and a Let's Encrypt certificate for the panel domain after its DNS points to the server.
Date and time
Choose the server timezone and either automatic network-time synchronization or a manual local date and time. Time changes affect logs, cron execution, certificate validation, authentication, and email timestamps.
Notifications
After native email, a secure panel domain, and at least one mailbox are ready, choose the system sender and up to ten alert recipients. Available alerts include failed operations, failed mail backups, SSL setup failures, website storage reaching 80 percent, and available updates.
Use Send test email before relying on alerts. The same sender supports forgot-password email.
Panel updates
Check the configured release channel, review the installed and available versions, and start a checksum-verified in-place update. Core Panel retains timestamped releases for manual rollback. Do not interrupt an active upgrade.
Services
Inspect services detected by systemd and restart supported services through the privileged agent. A service restart can briefly interrupt websites, databases, DNS, email, or the panel itself.
PHP versions
Review installed and available PHP-FPM branches and extensions. Install another allowlisted version when supported by the current operating system and architecture. Existing site selections remain unchanged.
Developer utilities
Inspect, install, or uninstall Core Panel's curated catalog of PDF/OCR, document, media, archive, shell/API, network, database-client, build, debugging, backup, and file-transfer tools. Core Panel accepts only its fixed allowlist and uses the platform's supported package source or verified cross-platform installer.
NGINX logs
Review up to the latest 500 lines from the main Nginx error log or managed webmail error log. This view is read-only.
Ports
Check external connectivity and protected localhost listeners for standard website, DNS, database, and mail services. Mail checks distinguish outbound reachability from the local listeners required to receive messages.
Root terminal
Open an unrestricted root shell through the privileged agent. A session starts only after an explicit action, closes when you leave the section or disconnect, and expires after 30 minutes of inactivity.
The root terminal can modify or delete any server data. Use site terminals for normal website work and reserve the root terminal for verified server-administration commands.
Core Panel management CLI
Core Panel installs the core-panel management command at /usr/local/bin/core-panel. Administrators can use it from the Root terminal or a root SSH session to inspect panel status and managed-resource inventories without opening the dashboard.
Access and data source
Run inventory commands as root. The CLI automatically reads the same protected configuration used by the Core Panel API from /etc/hostpanel/control-plane.env. When PostgreSQL is configured, commands query the live PostgreSQL store; the JSON state file remains a development fallback when no database URL is configured.
The internal hostpanel service account can access the protected configuration for service operation. Ordinary Linux users, website accounts, and SFTP/SSH site terminals cannot read panel-wide inventory by default. Do not add normal users to the hostpanel group to grant CLI access.
Security: The protected environment file contains database credentials and other secrets. Never display, copy, upload, or publish its contents. Use sudo core-panel <command> instead of exposing a database URL on the command line.
Available commands
Use the canonical plural command names below. Inventory commands are read-only; they do not create, modify, suspend, or delete resources.
| Command | Purpose |
|---|---|
| core-panel help | Show CLI usage, commands, and supported flags. |
| core-panel version | Show the installed Core Panel version, operating system, architecture, and Go runtime. |
| core-panel status | Show panel version and counts for sites, users, databases, mailboxes, and cron jobs. |
| core-panel sites | List managed website domains, runtimes, versions, status, SSL state, and creation time. |
| core-panel users | List administrators and operators with role, email, MFA state, account status, and creation time. |
| core-panel databases | List managed MariaDB databases with username, status, and creation time. |
| core-panel mailboxes | List mailbox addresses, quota limits, status, and creation time. |
| core-panel hash-password | Generate a PBKDF2-SHA256 password hash for approved automation; this command does not change a panel account. |
Run common inventory checks
sudo core-panel status
sudo core-panel sites
sudo core-panel users
sudo core-panel databases
sudo core-panel mailboxes
The singular aliases site, user, database, db, mailbox, and mail are accepted, but documentation and automation should use the canonical plural names.
JSON output for automation
Add --json after an inventory command to return structured JSON instead of the terminal table. Treat exported inventory as sensitive operational data.
sudo core-panel status --json
sudo core-panel sites --json
sudo core-panel users --json
Generate a password hash
Pass the password through standard input so it is not included as a core-panel command argument. Clear the temporary shell variable immediately after hashing.
read -rsp 'Password: ' CP_PASSWORD; echo
printf '%s' "$CP_PASSWORD" | core-panel hash-password
unset CP_PASSWORD
Important: The generated hash is output only. It is not applied to an administrator, operator, website account, mailbox, database, or SFTP user.
Behavior and safeguards
- Running core-panel with no command displays the help page.
- status, sites, users, databases, and mailboxes use the live installed data source when run with sufficient permission.
- The --data-file and --database-url flags are advanced overrides for development, recovery, or controlled automation. Prefer automatic configuration discovery on installed servers.
- Do not put a PostgreSQL connection URL containing a password directly in shell history, screenshots, logs, support messages, or documentation examples.
- Resource-changing operations remain in the authenticated dashboard and its audited workflows; the current management CLI inventory commands are read-only.
DNS management
Configure the public authoritative nameserver hostnames used by managed zones, optional secondary-server addresses, and the upstream resolvers used by the host. Production DNS should use independent nameserver infrastructure where possible. Registrar glue and parent-zone delegation remain external responsibilities.
Disk quotas
Review every website's shared storage allowance and open its Access & limits page to change it. Unlimited websites are clearly distinguished from limited websites.
Manage SSL
Review certificate coverage for all websites, see which sites enforce HTTPS, and open a website's SSL/TLS settings.
Panel recovery
Open System Settings > Panel recovery to configure encrypted, panel-wide disaster recovery to an independent S3-compatible destination. Enter an HTTPS endpoint, region, bucket, optional object prefix, access key, secret access key, backup interval, restore-drill interval, and catalog retention. Enable automatic backups and drills, save the settings, and use Back up now when an immediate recovery point is required.
A panel-wide bundle contains database state, control-plane and agent configuration, recovery secrets, Nginx and mail configuration, certificates, hosted website files, complete mail storage, managed DNS state, and integrity metadata. The bundle is compressed and encrypted with authenticated AES-256-GCM before it is sent off host. S3 credentials are encrypted at rest and are supplied only to the authenticated local agent while a recovery job runs.
Every new bundle starts as unvalidated. It becomes a valid recovery backup only after a clean restore drill downloads it from the off-host target, verifies the ciphertext and manifest hashes, decrypts it into an empty workspace, rejects unsafe archive paths, and completes an isolated database restore or development-state validation. Use Run drill for an individual bundle and review its validation time, checksum, format version, panel version, object key, and any drill error.
Key escrow: Store PANEL_RECOVERY_KEY from /etc/hostpanel/agent.env in a separate, protected secrets escrow. Losing both the server and this key makes the encrypted off-host bundles unrecoverable.
Production readiness
Open System Settings > Production readiness to review the security controls that block production classification. The page reports an overall Ready or Blocked state and lists each control as Verified, Partial, or Missing.
The required controls are tenant isolation, per-node agent mTLS enrollment, enforced resource controls, automatic off-host recovery, and an independent security review. Read each control's summary and remediation detail before exposing the panel to untrusted customers or workloads.
This gate cannot be dismissed or overridden. A TLS certificate, an acknowledged risk, or a software storage quota does not satisfy missing isolation, CPU, memory, host-disk, mTLS, or independent-review evidence. A newly created recovery bundle also remains unvalidated until its own clean restore drill succeeds.
Current expectation: Until every control is verified, treat Core Panel as suitable only for isolated development or trusted-administrator evaluation. Do not treat the panel as production-ready merely because off-host recovery passes.
Audit log
Review recent authenticated changes. Durable events are chained to the previous event with SHA-256 so later modification is detectable. Use the audit log to identify the actor, operation, resource, time, and result of sensitive changes.
Continue this workflow