Server settings and services

This screen is about the machine itself: which port you reach it on, which keys open a root session, what it runs, what shape it was given, and how to stop it gracefully. Nothing here is about a customer or a website — that lives on the account pages.

Servers → the server → Server settings.

Everything you do here is done by the server. The panel carries the intent and shows what came back; it keeps no copy of the truth of its own. Every change therefore also appears in the server's task log, with the name of whoever asked for it.

Moving the SSH port without locking yourself out

Moving an SSH port is the one change that can cost you access to a machine. So it works differently here from what you may be used to: the new port opens beside the old one, not instead of it.

1. Press Change the SSH port and fill in the new port (a number above 1023, e.g. 2222). Ports another service on this machine already holds are refused, naming that service.
2. Choose how long the confirmation window lasts. Ten minutes by default.
3. Press Open the port. From that moment the server listens on both ports, and the firewall lets both through.
4. Now open a new connection on the new port, from where you actually are:

ssh -p 2222 root@stck1.corecp.dev

1. Does it work? Press Keep the new port. The old one closes, in the daemon and in the firewall.
2. Does it not work? Then do nothing. When the window runs out without a confirmation, the server puts itself back on the old port — nobody has to be watching and nothing has to be running. You can also press Put the old port back straight away; that is the same act, only sooner.

Confirming from the old port proves nothing about the new one. That sentence is on the screen itself for the same reason.

On the command line it is the same sequence:

corectl sshd port                       # what listens, and does anything answer there?
corectl sshd port set --port 2222       # both open, a ten-minute window
corectl sshd port confirm               # keep the new one
corectl sshd port rollback              # or go back now

corectl sshd port also says what decides the port. On Ubuntu 24.04 and later systemd starts the SSH server through ssh.socket and Port in sshd_config is never read; CoreCP writes both, and the screen names whichever of the two is in charge on this machine.

The keys that open a root session

Plesk and WHM let you manage a customer's keys and stop there — the server's own keys are a file somebody edits by hand. Here they are in the panel.

The first time CoreCP renders this it adopts what is already there. Every valid key in /root/.ssh/authorized_keys appears in the list, named after its own comment. Nobody loses access by switching this on. Lines CoreCP cannot read are kept exactly as they were found and are not managed.

To add a key:

1. Add a key.
2. Paste the public key — the line from id_ed25519.pub, starting with ssh-ed25519 or ssh-rsa. Never the private key. RSA must be at least 2048 bits.
3. Give it a name if you like, and restrict it to a range of addresses if you like.

On the command line the key never travels on the command line itself — on a shared machine anybody can read the process list:

corectl node sshkey add --file ~/.ssh/id_ed25519.pub --label laptop
corectl node sshkey list
corectl node sshkey remove --label laptop

The last key does not leave by accident. When this server accepts no password for root — which is the default after our own hardening — removing the last key is not a revocation but a machine nobody can enter. You get a refusal that says so; somebody who really means it uses --force.

Starting, stopping and restarting services

The list shows what this machine runs: the agent, the SSH daemon, the firewall, the log watcher, and everything its roles imply (web server, database, mail, DNS, FTP). Per service you see whether it is running, whether it comes back at boot, and since when.

• A running service offers Restart.
• A stopped one offers Start instead.
• Three services cannot be stopped from here: the agent (that would cut the connection your instruction arrived on), the SSH daemon (that would leave no way back) and nftables (whose stop flushes the whole firewall rather than reloading it). Restarting them is fine, and is usually what was meant anyway.

What comes back is what the server measured afterwards, not what you asked for: a service that starts and falls over two seconds later looks fallen over here too.

corectl node service list
corectl node service restart nginx
corectl node service enable fail2ban

Underneath this machine: the guest agent and the trim schedule

Almost every CoreCP server is a virtual machine, and there are two things a host expects of its guest that only the guest itself can do. They sit under Underneath this machine, with what the server has managed to work out about itself above them.

The guest agent (qemu-guest-agent) is the line over which the host asks for a graceful shutdown, freezes the filesystems for a moment before it takes a snapshot, and learns which addresses the machine actually has. Without it a snapshot of this server is a photograph of a running database — restorable, but with a fair chance of work that was halfway done — and "shut down" on the host means the power cord.

• Automatic (the default) installs it as soon as the server notices it is a QEMU/KVM guest. On real hardware nothing happens at all.
• Always on ignores that detection. Useful for a nested guest, or a hypervisor that calls itself something else.
• Off stops the service. The package stays where it is — removing software because somebody moved a toggle is a bigger promise than a toggle should make, and putting it back would need a network and a mirror.

Giving blocks back (fstrim) is how a thin-provisioned disk ever shrinks again. Only the guest knows which blocks are free; a server that never says so grows to its full provisioned size and stays there, whatever df reports. Choose Weekly (Ubuntu's own default), Daily on a machine with a lot of churn, or Never on real disks, where a trim is disk work for nothing.

Both choices take effect the moment you change them — there is no save button and you do not have to wait for a maintenance round.

What the panel reports rather than arranges

Two things here are information only, and that is deliberate:

• Discard on the disk. The switch that makes a trim actually do something is on the host, on this VM's disk (in Proxmox: Hard Disk → Discard). It cannot be set from inside the guest. If it is off you get a warning here with the place to turn it on — and until then a trim politely frees nothing. A screen that said "on" while the host discarded every request would be worse than no screen.
• The guest agent's channel. It appears once the QEMU Guest Agent box is ticked for this VM on the host. If it is not, CoreCP installs the agent anyway — the order is not ours to choose — and says that the host still has a part to play.

corectl platform
corectl platform set --guest-agent auto
corectl platform set --fstrim daily

A server's profile

A profile is the shape a machine was given: which roles, which tools, which web server, which PHP ceilings. It is a starting point rather than a lock — the server may drift from it, and those differences are listed underneath.

Switching takes two steps: What would change? first, then Apply the profile. That first step is not politeness. A profile that is narrower than what the server carries — one without the mail role, say — is refused while there are still mailboxes, zones or databases on it, and the refusal names them.

Rebooting and shutting down

At the bottom, in the red block, with the most friction in the whole panel: you type the server's name out. That is not decoration — it is exactly what the server itself demands as a confirmation, so the panel cannot fill it in for you.

• Reboot shuts down gracefully and comes back. Everybody logged in is warned first, and there is a minute in between.
• Shut down shuts down gracefully and stays off. Only your host's console can turn it back on.
• Call it off withdraws a scheduled action inside that minute.

corectl node power reboot --confirm stck1.corecp.dev
corectl node power cancel

A reboot or a shutdown never comes from automation: there is no setting that does this by itself, and that is deliberate.

Who may do this

Everything on this page is server administration. A reseller does not see it and an end user certainly does not — they get a refusal even if they guess the address. An API key cannot reach it at all: a key that could move the SSH port, or write a key into root's authorized_keys, is a key that grants root from a script over every customer on that machine.