Frequently Asked Questions
Yes.
server123.io runs on a standard low-cost VPS. It is a vanilla Server123 installation, but runs some additional code to handle registration, configuration, updates, and heartbeats for other Server123 sites.
You're looking at a fairly normal free WordPress theme ( AccessPress Ray), but with a custom child theme which uses Bootstrap, a CSS Grid layout, JavaScript, and hand-written HTML.
No. If your organisation controls example.com, then Server123 must be configured for (and will appear at) example.com. If you do not control the top level of example.com then you cannot use Server123 on that domain.
Ultimately, the server runs Ubuntu, and you can install anything you want. This is not going to break any warranties, because there is no warranty. However, our view is that you should consider the server to be a Black Box, which runs a limited number of pre-configured applications. Any changes you make, apart from normal security updates, run the risk of breaking existing functionality, or interfering with Server123 updates.
No. The server runs at runlevel 3 (systemd's multi-user.target), and doesn't have X11 or Wayland installed. This means that it can't support a desktop. This is normal practice for a server. You can install everything required for a remote desktop yourself, of course, but this isn't the intended use of the server.
The 'system users' are the Linux system users; they are not the front-end users (who are recorded in the Keycloak database). You can add as many system users as you want, but we don't recommend it. You should treat Server123 as a locked system. In normal circumstances, the server should only ever change as a result of a Server123 update, or an Ubuntu security update.
There are parts of the system which assume that there are only three system users: 'root', 'sysadmin', and 'wpuser' (/etc/ssh/sshd_config, for example, which handles ssh configuration for only these users). If you add more users then you should expect something to fail.
The 3 users are essentially arranged in a hierarchy of permissions. root, of course, can do anything. sysadmin is unprivileged, but does own specific parts of the system, and can run a lot of maintenance scripts (the ones in /usr/local/sbin). There are circumstances in which you may need to log in as sysadmin. Finally, wpuser is also unprivileged, but can run only a small number of maintenance scripts. Essentially, anyone who might need to do system maintenance of some sort should log in as sysadmin, and anyone who only needs access to the WordPress, DokuWiki, and MediaWiki installations should log in as wpuser.
The server has a normal (unprivileged) user named 'wpuser'. The WordPress, DokuWiki, and MediaWiki installations are in this user's home directory. The point of this arrangement is that whoever is responsible for your website and wikis can log in as wpuser, and carry out any required modifications to these installations, without needing root permissions.
wpuser therefore exists for security reasons. This user doesn't need any access to the /var/www directory, and doesn't need to configure Apache, but can carry out any required modifications to the PHP installations by logging in, or using a file transfer program, as user wpuser.
Both WordPress and DokuWiki are capable of updating themselves. However, the PHP apps are normally locked down. In the locked state, wpuser owns all the files, and Apache (which runs php) does not have the necessary permissions to write to (most of) the files in the installations. In this state, WordPress and DokuWiki can't update themselves. If you need to carry out an auto-update, you will first have to unlock the distributions. In 0625, wpuser must ssh to the server, run an unlock script, and re-lock the distribution when the update has completed (an update is planned to add this operation to the web console). The Administration guide contains instructions for the lock and unlock operations.
sysadmin and wpuser are not in the sudo group (this is the equivalent of the wheel group if you're more familiar with Red Hat systems).
This is simply a policy decision. A user who is in the sudo group has unrestricted access to any part of the system, using only their own password. Without sudo access, a user must know the root password in order to have unrestricted system access. This is, of course, the purpose of the root password; by definition, the only trusted user should be the root user.
There are situations in which an untrusted user must carry out administration tasks which would normally require root permissions. User wpuser, for example, might need to lock down the WordPress or wiki installations, which requires the ability to change file ownerships and permissions. The scripts required to carry out these actions are listed in /etc/sudoers.d/sysadmin, which allows a given user to run that specific script with sudo.
You can find the installed Ubuntu version by running 'lsb_release'. At the time of writing, this reports:
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 24.04.2 LTS Release: 24.04 Codename: noble
No. In 0625, the same auth mechanism must be used for all Subversion repos, and the same auth mechanism must be used for all Git repos.
In 0625, the Anonymous authentication mechanism applies for both read and write. This is potentially a problem if you need public read access, and private write access; this is not currently possible.
Both these restrictions will be addressed in an upcoming release.
Yes; see the Installation Guide for instructions for writing the ISO to a USB stick. However, Server123 is normally installed remotely, and the install from USB has limited testing.
You should note, in particular, that both the ISO image and Server123 itself boot from BIOS/MBR. This is because some VPS providers do not support UEFI boot. One popular local provider, for example, uses a Hyper-V Gen1 hypervisor, which is MBR-only.
If you intend to install locally, you should also note that some modern PCs make it difficult to boot from BIOS/MBR. You may have to set up your PC's BIOS for a one-time BIOS boot, for example, which is of little use. You should check your PC's abilities before attempting an install from USB.
Yes, but see the FAQ entry for "Can I install from a USB stick?".
Note that you can carry out a network install rather than booting from the supplied ISO, but your computer will still need the ability to boot from BIOS/MBR. This is because the Server123 image, when it has been written to your local disk, also boots from BIOS/MBR.
If you already have a key pair, then you simply need to upload the public key. Assume, for example, that user 'john' is on Linux, and needs to login as root, and has a .ssh directory containing a key pair:
$ ls -l /home/john/.ssh -rw------- 1 john john 1843 Dec 17 2024 id_rsa -rw-rw-r-- 1 john john 416 Dec 17 2024 id_rsa.pub
In this case, id_rsa is the secret key, and id_rsa.pub is the public key. To upload the public key, select 'File upload' from the console's Administration menu, and then select 'ssh public key, root', with 'Create or replace file'. Now browse to id_rsa.pub, and click 'Upload'. John can now ssh directly to root@example.com without needing a password.
If you don't already have a key pair, the server will generate one for you. Select 'File download' from the console's Administration menu, and then select 'ssh keys'.
You'll now have to select a key type. If you're on Windows, and you're using PuTTY, WinSCP, or similar, select 'PuTTY'. If you're on a Unix-like system, select 'OpenSSH'. In either case, you can enter a password to encrypt your new private key, if necessary. This isn't required, and can complicate usage of the key; you can omit the password until you have a better understanding of your requirements.
When you click 'Submit', the server will generate a new key pair for you, which you can download (the download will probably happen automatically). The download will be a zip file. Unzip this file, and store the private key locally (the private key is the one which doesn't have the '.pub' suffix). On Linux, you store the private key in ~/.ssh. For Windows, check the documentation for your remote login or transfer program.
You now have to copy the public key back to the server. Select 'File upload' from the console's Administration menu, and then select a key upload for the required user (root, sysadmin, or wpuser).
Now confirm that ssh is still set up correctly. Select 'ssh configuration' from the console's Administration menu. ssh should be enabled for the required user, and 'Password enable' should be set to 'N'.
You can't do this from the web console, for obvious reasons. You'll need to ssh to the server (as either sysadmin or wpuser), and run this command:
$ sudo setsite.sh down
All site accesses will then be redirected to the sitedown page. To reverse the process, run sudo setsite.sh up instead. These commands reload the web server, so will log out all front-end users.
If you enable disk encryption, the data and swap partitions on your disk will be encrypted with a passphrase, and temporary files will be stored in RAM, rather than the /tmp directory. The data partition is where your sensitive data (emails, documents, and so on) is stored. Note that the rest of the disk - everything under /root, /home, /var and so on - is not encrypted, since it is not used for storing sensitive user data. This allows the server to boot up even if a passphrase cannot be supplied during the boot process.
To decide whether or not encryption is useful to you, it is first necessary to understand what the purpose of LUKS encryption is. LUKS encrypts an entire block device (or, in this case, a partition). When the system is powered up and running, the kernel decrypts (on the fly) any data read from the block device, and encrypts (on the fly) any data written to the block device. The encryption is therefore irrelevant when the system is running, because any user who is logged on to the system (including, in principle, an attacker) will see the decrypted data. This is in contrast to file-level encryption, which encrypts specific files. In this case, the encrypted file can only be read by a special-purpose program which has access to the decryption key.
LUKS (or any other at-rest encryption system, such as BitLocker) is therefore primarily useful to protect against physical loss of mobile devices (such as laptops and removable drives). Cloud servers are not 'mobile', but are off-site, and so have essentially the same characteristics. The factors you should consider include:
- Most importantly, do you trust your cloud provider? Unencrypted storage is trivial to read, and encryption will provide some degree of security. When your system is powered on (in other words, nearly always) a rogue employee would have to break into a running system to retrieve any sensitive data. While this is possible, it is much harder than simply reading an unencrypted disk image
- An off-site server will be powered off at some stage, even if this only happens during power outages, or when the server fails or is replaced. If you need to keep your data secure at this point, you should encrypt it
- If your server is a VPS, the 'disk' is likely to be a backing file on a host system in the datacentre. If you do not encrypt, the backing file will always contain your unencrypted data. The section of the host's physical device that contains your backing file will eventually end up being assigned to another customer's VPS. The disk should always be zeroed if it is assigned to someone else, but you should consider encryption as an extra security measure
- Even if your server is on your own premises, you could consider encryption to simplify the process of disposing of the disk when it eventually fails.
If you do enable encryption, you will have to manually enter the LUKS passphrase every time the system reboots. If you have automated security updates enabled, you should therefore consider disabling 'Auto reboot' during Stage 1 Configuration, and instead manually reboot when you have access to the server.
No. None of the apps are containerised, and no Docker components are installed. Portability is not a concern, and the installed applications communicate, or don't communicate, by design. This ensures the greatest performance and the least resource usage.
vi, vim, and nano are pre-installed. Historically, emacs-nox was also installed, but its footprint increased from 100MB in Ubuntu 22 to 337MB in Ubuntu 24. mg is now installed as an emacs-like replacement, and has a footprint of 237 KB. As the man page opines, "mg is compatible with emacs because there shouldn't be any reason to learn more editor types than emacs or vi".
You can, of course, install another editor if necessary.
Download the image as shown below. This image has a virtual size of 20GB, but is compressed, and uses thin provisioning, and so uses less than 3GB of disk space:
$ wget -O vserver.qcow2 https://www.server123.io/downloads/vserver-latest.qcow2 $ qemu-img info vserver.qcow2 | grep "virtual size" virtual size: 20 GiB (21474836480 bytes)
When creating a VM from a qcow2 image, the disk size is set by the image, and not by the VM itself. The base qcow2 image has a virtual size of 20GB (4GB for the data partition, and 16GB for everything else). If you install this image directly, you will get a 20GB VM. If you need a larger VM, you must resize the image before installation. If you have a 120GB SSD, for example, you can resize the image as follows:
$ qemu-img resize vserver.qcow2 +100G
In this case, the data partition will be expanded to 104GB during Stage 1 Configuration, while the root partition will remain at 16GB.
You can now create a VM in the normal way, and import the disk image. However, note that this image is built for BIOS/MBR boot. When creating the VM, you should ensure that:
- The operating system should be auto-detected as Ubuntu 24.04. If it is not, you should manually select Ubuntu 24.04
- The hypervisor firmware should default to BIOS (rather than some variation of UEFI), but you should check this before attempting installation. When using virt-manager, you should select 'Customise configuration before install'. The overview page on the new screen has a 'Hypervisor Details' section, with a 'Firmware' pull-down. This should be set to 'BIOS'.
There are circumstances in which you may want to log directly into your VM console (using whatever mechanism is provided with your VPS), rather than using ssh. This is most likely to happen prior to configuration, and it is therefore assumed below that configuration has not completed. Prior to configuration, you will not have access to the web console, and:
- All the relevant passwords are 4ptqR56Q
- ssh is listening on port 7901, and is set for public key login, but you haven't yet uploaded your public key
- You cannot use the web console to enable password login for ssh
- The keyboard and locale are set to US/PC105 and C.UTF-8, respectively
You should log in at the VPS/VM console as user sysadmin, with the password above. setxkbmap is not installed (and, even if it was, VPS providers are likely to hard-wire the keyboard to US anyway). You will therefore have to try to find some keyboard mappings yourself. If you have an English/UK keyboard, for example, you can type these keys to get the required character:
£ ➙ # @ ➙ " ~ ➙ | # ➙ \ " ➙ @
You can alternatively manually configure ssh, which automatically gives the correct keyboard mappings. To do this, you will have to edit /etc/ssh/sshd_config. Find the Match user sysadmin section, and set PasswordAuthentication yes. You must now restart ssh (systemctl restart ssh). On completion, you can log in directly with:
$ ssh -p7901 sysadmin@my-ip-address
Server123 communicates with server123.io in two cases. In the first, a licensing check is carried out (only) during Stage 1 configuration. The second case occurs during the heartbeat process, to test email reception.
Historically, email reception was tested by asking Google's SMTP server to send an email back to the originating domain. However, Google has effectively stopped free use of their server, and the procedure used now is to contact server123.io instead. Enough information is sent to construct the heartbeat email (your domain, IP address, vServer version, and the system load stats). server123.io then emails this information back to the administrator at your Server123 instance. This is the heartbeat email that you receive twice a day.
This information is not recorded at server123.io. If you do not want to receive heartbeat emails, see the 'How do heartbeats work?' FAQ entry.
The heartbeat procedure is complex, since it is intended to check a large part of the system functionality. This includes the testing of incoming emails, which must be sent from a remote provider. It proceeds as follows:
- A cron job runs twice a day, at approximately 7AM and 7PM, making a curl request to run the local 'hbeat' program. This effectively reads a local 'web page'
- 'hbeat' collects some system stats and connects to server123.io, which then sends the stats back to the admin at your server, as an email
- The incoming email is received at your server, and is forwarded on to the admin's real mail address. This is the heartbeat email that you receive.
The process therefore tests your server's ability to serve a webpage, and to receive and send emails. If you want to disable this functionality, you should disable the originating cron job (to do this, log in as sysadmin, run crontab -e, and delete the heartbeat lines).
The 'load average' is a simple indication of system loading. It is essentially a count of the number of processes which are either running, or waiting to run, averaged over some time period (the number shown on the console front page, and on the heartbeat emails, is the one-minute load average). The load average should be divided by the number of processors available to give a measure of system utilisation (this is why the number of processors is also shown in the tables). The load average is not a particularly useful metric; the PSI (Pressure Stall Indicator) gives a better indication of loading.
In principle, an idle system should have a load of 0. However, the load figure includes the number of processes in an 'Uninterruptible sleep' state (this is shown as state 'D' in the output of ps and related commands). A process in state D is not actually consuming any system resources, but is waiting for something, and will eventually wake up.
At the time of writing (with Ubuntu 24.04.2 and kernel 6.8.0-62) a single kernel worker thread is generally shown in state D, which gives an apparent loading of 100% (before division by the number of CPUs). This thread can be ignored, and the underlying issue is likely to be fixed at some stage. pSnapper is a useful tool for tracking down issues of this sort; you can find more information here.