Ubuntu 24.04 server operations

Baseline: a record of the target, time, and state collected so that the system can be compared before and after a change.

Installation is not a file copy; it is a change that decides which disk to erase and on what boot, network, and identity basis the server will start. Do not proceed just because Install is on the screen; first confirm whether the target is a lab VM or a physical server holding existing data, and whether a rollback is possible.

A baseline is not a note saying “installation is finished.” It is a bundle of evidence recording the OS release, kernel, clock, CPU, memory, disk, interfaces, and addresses at the same point in time, so that later faults or changes can be compared against it. What you observed comes before any conclusion that things are normal.

In the training example the disk checked just before installation was 100GiB while the work order specified 80GiB. Do not proceed merely because the VM name matches. An added virtual disk or a wrong console connection can also be the cause. Compare the serial and the device attachment, and stop the installation until the target is confirmed.

A baseline is built from the output of several commands. The OS release describes the distribution, the kernel is the core of the currently running operating system, and mount shows the filesystems in use. Even if one value is normal, check the others separately. Tie them together under the same timestamp and target name so that the next operator can compare them.

Why does this happen?

Only by recording the OS, devices, and addresses at a single point in time can you later tell which layer changed. Do not extend the success of a single command into a verdict that the entire server is healthy.

When is it a problem?

If the disk capacity differs from the work order, you may be looking at a different VM or an additional disk. Before proceeding on the installation screen, first compare the target identity.

Common beginner misconceptions

If you choose the wrong target disk on a physical server or an existing VM, the data may be unrecoverable. If the asset ID, disk serial, capacity, or attachment location differs from the work approval, stop immediately and escalate to a senior colleague.

How to verify it yourself

Collect the results of the read-only commands below in one record, and compare the target and capacity in the work order with the actual disks, mounts, and routes. Record command failures as well.

Working directory: the current location used as the reference when relative paths are resolved.

The prompt is the marker that tells you where the operating system's output ends and your input begins. Do not copy $ or # as part of a command. In particular, a # prompt usually means root privileges, so the same command has a different scope of impact.

An absolute path starts at /, while a relative path is interpreted against the current working directory. Do not assume you are in the intended location just because cd succeeded; confirm the current location and hidden entries with pwd and ls -la.

In the training example the learner queried ./data believing they were in /srv/lab, but the actual pwd was /home/learner. The same relative path points to different files when the starting location differs. Check the target with pwd and ls first, and check again after cd. In particular, do not run delete or overwrite commands before comparing the absolute path and the owner.

The shell splits the input string into a command name and arguments, then runs the command. Quotes are needed when passing a value containing spaces or special characters as a single argument. A pipe connects the output of the first command to the input of the next; it does not mean the original file is modified. By contrast, the redirection > can overwrite the target file, so distinguish it from read-only commands.

Why does this happen?

The shell splits the input string into a command name and arguments, then runs the command. Quotes are needed to pass a value that contains spaces or special characters as a single argument. A pipe connects the output of one command to the input of the next; it does not modify the original file. Redirection with >, by contrast, can overwrite the target file, so distinguish it from read-only commands.

When is it a problem?

In a training case, someone queried ./data believing they were in /srv/lab, but the actual pwd was /home/learner. The same relative path points to different files when the starting location differs. First confirm the target with pwd and ls, and confirm again after cd. In particular, never run delete or overwrite commands before checking the absolute path and the owner.

Common beginner misconceptions

Do not run a command you found on the internet with `sudo` right away. First confirm the command's owner, options, and scope of change with `type`, `--help`, `man`, and the package source.

How to verify it yourself

Confirm your current location, move safely, and then interpret the help output and the exit status.

Permission: the rule that sets what the owner, the group, and others are allowed to read, write, and execute.

Linux does not decide access from the user name shown on screen alone. It evaluates the process UID and GID together with the target file's owner and group, the rwx bits, and any additional policy. chmod 777 is not an all-purpose command that fixes problems; it is a dangerous change that widens the scope so that anyone can read, write, and execute.

A service account has a different purpose from a personal account that a human logs into. Letting it reach only the directories it needs and restricting shell login and unnecessary home directories reduces credential misuse and the blast radius of an incident.

In the training example the learner had read permission on the file but no traverse permission on the parent directory, so access was denied. Changing the mode of a single file may not fix it. Check each directory on the path and the actual UID and group of the process. Giving 777 to everything does not explain the cause and opens up unrelated write access.

Read and execute permissions mean something different on a directory than on a file. Read allows listing entry names, and execute allows traversing the path. Even after a user is added to a group, an existing login session may not reflect the new group. Check the current session's groups with id, and test in a new session that only the required actions are allowed.

Why does this happen?

Read and execute permissions on a directory mean something different from those on a file. Read allows listing the entry names, and execute allows traversing the path. Even after adding a user to a group, an existing login session may not reflect the new group. Check the current session's groups with id, and test in a new session that only the required actions are allowed.

When is it a problem?

In a training case, the user had read permission on the file but lacked traverse permission on a parent directory, so access was denied. Changing the mode of that one file may not fix it. Check each directory along the path and the UID and group of the actual process. Granting 777 on everything does not explain the cause and also opens up unrelated write access.

Common beginner misconceptions

Do not grant 777 on the entire path just to make a permission error go away. Check the actual user and group, and the traverse permission on the parent directories.

How to verify it yourself

Create a lab service account and a group directory, and verify both the allowed and denied access.

Service (unit of service process management): the execution unit whose start, stop, restart, and dependencies systemd manages.

A package being installed is not the same as a service running. enable creates the start relationship for the next boot, while start starts the process in the current session. Checking only one of the two can lead to a failure after a reboot or while handling current requests.

A change task does not end with “the command succeeded.” Keep a single bundle containing the version and state before the change, the packages and configuration applied, the current state, a representative function, the logs, the state after a reboot or restart, and the rollback location.

In the training example the package installed but the service failed to start because of a configuration error. Installation success and startup success are different checks. Find the first error with systemctl status and the journal, then use the configuration check function. Even with a correct configuration, if the listen address is bound only to localhost you must separately confirm whether external requests are possible.

enable sets up the start link for the next boot, while start requests execution now. The active state is the process state an administrator sees; it does not guarantee what an API response means. restart can affect in-flight requests, so prepare a change window and a recovery method. Reload support also varies by service, so check the unit and the program documentation before using it.

Why does this happen?

enable creates the start link for the next boot, while start requests that the service run now. The active state is the process state an administrator sees; it does not guarantee that API responses are meaningful. A restart can affect in-flight requests, so prepare a change window and a recovery method. Reload support also varies by service, so check the unit and the program documentation before using it.

When is it a problem?

In a training case, the package was installed but the service failed to start due to a configuration error. A successful installation and a successful start are separate checks. Find the first error in systemctl status and the journal, then run the configuration check. Even if the configuration is correct, a listen address bound only to localhost means you must separately verify whether external requests can reach it.

Common beginner misconceptions

An active status does not guarantee that the API responds correctly. Check the listen address and port, and a representative function, separately.

How to verify it yourself

Install the lab service and verify the enable, start, log, and reboot boundaries.

Mount point: the location where a filesystem is attached to a specific path in the current directory tree.

“The server is unreachable” is not a single cause. Interface link, IP address, route, DNS, remote port, and application state are different layers. If name resolution has failed and you change the firewall first, you lose evidence and may create a new failure.

With storage as well, a disk being visible, having a partition and a filesystem, being mounted, and being usable by the application are all different things. A name like /dev/sdb can change with the order of attachment, so use a stable identity such as a UUID for permanent mounts.

In a training case where the cause was confirmed, a report of low disk space on /data led to a comparison of the work order, the previous baseline, and the mount configuration, which showed that the remote volume had become unmounted. The lab below starts at the initial diagnosis stage, before that conclusion is known. The same directory name can sit on a different storage device. Use findmnt to identify the source of the target path, then align the scope of df and du. Deleting files before confirming the cause risks deleting data on a different filesystem.

Network diagnosis, too, does not treat name, address, route, and port as one lump. A successful name resolution is not a successful connection, and a successful ping does not guarantee a response from the application port. Run each query with one hypothesis to rule out. If results contradict each other, first confirm that the target and the moment are the same, and only then consider configuration changes.

Why does this happen?

A path name does not guarantee the storage device behind it, and a DNS response does not guarantee a port connection. Starting from the observation closest to the failed function, compare the layers before and after it.

When is it a problem?

Writing to /data when its separate volume is missing can fill the root filesystem. Before deleting files, confirm which mount the path actually belongs to.

Common beginner misconceptions

Running `netplan apply` directly from a remote SSH session can cut off your connection. For remote network changes, first secure console access and a rollback plan, and prefer a procedure with time-limited recovery such as `netplan try`. Filesystem creation commands can destroy existing data on the target disk, so this unit's automated labs do not run them.

How to verify it yourself

Collect read-only evidence first to narrow the scope of a network or storage failure, then recover safely.