You have srv-tramontana up and a cursor blinking after operator@srv-tramontana:~$. No icons, no windows, no menus. For someone coming from Windows or macOS, that screen can be intimidating: it looks as though the computer expects you to know something nobody has told you.

This lesson defuses that feeling. You are going to understand exactly what you are looking at: what happened when you logged in, what each character of the prompt means, what the difference is between a console, a terminal and a TTY, and why the shell is the most important program of your working day. Then you will carry out the initial reconnaissance of srv-tramontana: checking which version it runs, how much memory it has and how much disk is left, which is literally the first thing an administrator does when handed a new machine.

A note on the approach: the commands you will see here are for looking, not for mastering. The aim is that you know what you are seeing and move around comfortably. Serious command line work starts in Module 2.

1. What happens when you log in
2. The prompt, character by character
3. Console, terminal, TTY and terminal emulator
4. What the shell is and why Bash
5. Graphical environment versus text only
6. The anatomy of a command
7. Initial reconnaissance of srv-tramontana
8. Survival keyboard shortcuts
9. Normal user, root and first contact with sudo
10. Shutting down, rebooting and logging out properly

When this appears after booting:

it is not a decorative screen. There is a chain of programs at work:

1. systemd, process number 1, has started all the system services and launched a program called getty on each virtual terminal.
2. getty is what displays that message and waits for a username. Its job is to prepare the terminal and collect who wants to log in.
3. When you type operator, getty hands control to login, which asks for the password, hashes it and compares it with the hash stored in /etc/shadow.
4. If it matches, login establishes your identity (user, groups, environment variables), places you in your home directory /home/operator and runs your shell, which on Ubuntu is Bash.
5. Bash reads its configuration files (/etc/profile, ~/.bashrc) and displays the prompt.

That is the moment when the system becomes available to you. And there is an important detail that is clearer with lesson 01-01 still fresh: from here on, everything you do will be a child process of your shell.

Before the prompt you will see the message of the day (MOTD), which on Ubuntu Server contains useful information:

It is worth reading rather than ignoring, because it gives you a free dashboard: system load, disk usage, memory usage, IP address, pending updates and — very important from the security point of view — when and from where the last login took place. If that Last login line shows a date or an IP you do not recognise, you have a serious reason to investigate.

The prompt is the line the shell displays to say it is ready. On Ubuntu it looks like this:

Breakdown:

The first three elements are a permanent answer to the three questions that cause the most trouble when they are ignored: who am I, which machine am I on and where am I.

The distinction between $ and # is not cosmetic: it is a danger signal. If # appears in your prompt, you have absolute power over the machine and no command is going to ask you for confirmation.

That last case illustrates why the hostname in the prompt is so valuable: when you have several terminals open against different machines, it is the only thing stopping you from running in production what you thought you were running in testing. It is a classic and expensive mistake.

The prompt is configurable through the PS1 variable, and in Module 3 you will learn to customise it (many people add colours, the Git branch or the time).

Four words that sound like synonyms and are not. The confusion comes from the fact that all of them originate in hardware that no longer exists.

The distinction between the last two rows is the hardest one and the one that clears up the most:

• The terminal is the container: the window or screen where you type and read.
• The shell is the content: the program that reads what you type, interprets it and runs programs.

You can change terminal while keeping the same shell (Bash), or change shell (to Zsh, for instance) while keeping the same terminal. They are independent pieces that combine.

Even though srv-tramontana has no desktop, Linux offers you six independent virtual terminals on the physical console. You switch between them with:

• Ctrl+Alt+F1 to Ctrl+Alt+F6 (on Ubuntu Server, F1 is usually the first).
• In a VirtualBox VM the combination is Host+F1..F6 (the host key is right Ctrl by default), because VirtualBox intercepts Ctrl+Alt.

Each one is a complete, independent session: you can have operator working on tty1 and another user on tty2 at the same time.

Try it now. Switch to another terminal, log in and run:

Output:

That is the device file representing your current terminal. Consistent with "everything is a file": your terminal is a file in /dev, and you will develop that idea in the next lesson.

If you connect over SSH and run the same thing:

pts stands for pseudo-terminal slave: a terminal that corresponds not to physical hardware but to a connection, typically SSH or a graphical emulator window. It is the system's way of telling you "this is not the machine's console, it is a remote session".

A genuinely useful practical tip: virtual terminals are your lifeline. If a program locks up your current terminal and Ctrl+C does not respond, switch to another tty, log in and fix it from there without rebooting the machine. The process management you will need for that is lesson 03-06.

The shell (literally a shell, because it wraps around the kernel) is the program that:

1. Displays the prompt and waits.
2. Reads the line you type.
3. Interprets it: separates the command from its arguments, expands wildcards and variables, resolves pipes and redirections.
4. Asks the kernel to run the corresponding program.
5. Waits for it to finish and displays the prompt again.

It is at once an interactive interface and a complete programming language, with variables, conditionals, loops and functions. That duality is what makes Linux so powerful: anything you do by hand in the terminal can be turned into a script without changing tool. It is the basis of Module 4.

You can see which one you are using:

echo prints whatever you give it, and $SHELL is an environment variable holding the path of your login shell. Environment variables are the subject of lesson 03-01.

And the shells installed on the system:

Why Bash in this course, with concrete reasons:

• It is the default shell on Ubuntu, Debian, RHEL, Fedora and almost any distribution you will meet.
• It is what 95 % of the documentation, tutorials and answers you will find assume.
• It is POSIX compatible, so what you learn also works on macOS, on Alpine inside a container and on any Unix.
• On somebody else's server, in a minimal image or in an emergency, Bash or something compatible is always there. Zsh and fish are not.

Nothing stops you using Zsh on your laptop for comfort. But learn Bash first: it is the common language.

srv-tramontana has no desktop. It is worth understanding what it is that it does not have, and why that is deliberate.

On Linux, the graphical interface is not part of the system: it is a set of programs that you either install or do not.

About X11 and Wayland, the minimum you should know:

• X11 (Xorg) dates from 1984 and has been the standard for decades. Its architecture is client-server and network transparent: you can run an application on srv-tramontana and see its window on your laptop (ssh -X). Powerful, but with an outdated design and known security problems: any application can read what the others are typing.
• Wayland is the modern replacement. Simpler, more secure and better performing. It is the default on Ubuntu Desktop 24.04. Its isolation between applications breaks some old tools, though fewer and fewer.

The last point is the one that convinces the sceptics. Installing a desktop on a production server is considered bad practice in the industry, not out of purism, but because every one of those reasons is paid for in money, in incidents or in hours.

Every command follows the same structure:

• Command: the program to run (ls, date, free).
• Options (or flags, or switches): they modify the behaviour. They start with a dash.
• Arguments: what the command acts on (a file, a directory, some text).

The square brackets mean they are optional: many commands work on their own.

An example broken down completely:

Piece-by-piece analysis:

• ls : the command, it lists the contents of a directory.
• -lh : two short options grouped together. -l (long) shows the detailed format with permissions, owner, size and date; -h (human-readable) expresses sizes in K, M or G instead of raw bytes.
• /var/log : the argument, the directory we want to list.

And about the output, without going into detail (permissions are lesson 02-07): the first letter of each line indicates the type of file. The d on apt means directory; the - on the others, a regular file. You will see the remaining letters in the next lesson.

• Linux is case sensitive, always. ls, LS and Ls are not the same thing, and File.txt and file.txt are two different files. This surprises people coming from Windows and is a constant source of errors at first.
• Spaces separate elements. If a file name contains spaces, it must be quoted: cat "my file.txt".
• -- marks the end of the options, which is useful when an argument starts with a dash.

This is what an administrator does when handed a new machine, and what you should always do before installing anything: know what you have in front of you.

It returns the effective user. It looks trivial, but when you have spent half an hour hopping between sudo, SSH sessions and machines, it is the first question to answer whenever you are in doubt.

The machine's name. Its extended version gives more context:

There is valuable information in three lines here: Chassis: vm and Virtualization: oracle confirm you are on a VirtualBox virtual machine (useful when you administer machines you did not build yourself), Operating System gives the exact version and Architecture the processor architecture.

uname stands for Unix name and -a is all. Field by field:

For the distribution version, which is different from the kernel version:

Hold on to the difference: the kernel is 6.8; the distribution is 24.04. They are two independent numbering schemes and confusing them leads you to look up the wrong documentation.

Reading it:

• 09:18:42 : the system's current time.
• up 2 days, 4:31 : it has been up for 2 days and four and a half hours.
• 1 user : there is one open session.
• load average: 0.08, 0.12, 0.09 : the average load over the last 1, 5 and 15 minutes.

The average load deserves an explanation because it is constantly misinterpreted: it is not a percentage. It is the average number of processes using the CPU or waiting to use it. The reference is the number of cores:

• On a 2-core machine, a load of 2.00 means full use; below that there is headroom and above it there are processes waiting.
• A load of 0.08 on 2 cores, as in the example, is a practically idle system.
• The three values together show the trend: if the first is much larger than the third, the load is rising right now.

This is covered in depth in lesson 05-07.

-h is again human-readable. Column by column:

Here is the most widespread misunderstanding about Linux, and it is worth settling now: the free column does not tell you how much memory you have left. Linux aggressively uses free RAM as a disk cache, because leaving memory unused is wasting it. That cache is released instantly if a program needs it.

The correct column is available. A server with free at 100 MB and available at 3 GB is perfectly healthy. There is even a website dedicated to explaining this (linuxatemyram.com), so common is the confusion.

The Swap line with 0B used is a good sign: there has been no need to fall back on the disk.

df is disk free. What is relevant:

• /dev/sda2 mounted on /: the root partition, 23 GB of which 6.4 GB are used (30 %). This is the line to keep an eye on.
• /dev/sda1 mounted on /boot/efi: the UEFI boot partition you created when installing.
• The tmpfs lines are file systems that live in RAM, not on disk: they are wiped on reboot. They are normal, and seeing them there illustrates once again the principle that everything is presented as files.
• The Use% column is the one to watch on a server. Above 80 % you should act; at 100 %, as we saw in the previous lesson, the system stops working properly.

And to find out the date and time, which matters more than it seems because it affects every log:

Notice the UTC: by default, servers are usually configured in universal time, not local time. It is deliberate: it avoids ambiguities with daylight saving changes when you compare logs from several machines.

With this data you can already answer Marta if she asks you what state the server is in:

Conclusion of the reconnaissance: there is plenty of headroom to install Tramontana Bookings. And now you have a reference picture: when the server runs slowly three months from now, you will be able to compare with these numbers instead of guessing.

These five shortcuts separate someone who suffers in the terminal from someone who moves around comfortably. Practise them until they come without thinking.

Type hostna and press Tab:

Bash completes as far as there is no ambiguity:

If there are several possibilities, press Tab twice to see them:

It works the same way with file paths:

Its value is not convenience: it is verification. If you type a path and Tab does not complete it, that path does not exist. You find out before running the command, not after. An experienced administrator uses Tab constantly for this reason.

They are often confused and they do different things:

• Ctrl+C sends the SIGINT signal to the running program, asking it to finish. It is what you use when a command has hung or is dragging on forever.
• Ctrl+D sends the end of file character (EOF). It kills nothing: it says "there is no more input". If you press it at the prompt with nothing typed, the shell takes it that you have finished and closes the session.

Try the first one. Run a command that does not finish by itself:

The ^C in the output is the visual mark that you pressed Ctrl+C. ping stops and shows a summary. (ping checks network connectivity; that is lesson 03-08.)

There are many more shortcuts — Ctrl+A, Ctrl+E, Ctrl+R, Ctrl+W — which you will see in lesson 03-01 when studying the shell environment. These five are more than enough for now.

On Linux there is a strict separation between two kinds of account.

root (also called the superuser) is the account with UID 0, and its power is total and literal. The kernel applies no permission checks to it. It can delete any file, kill any process and destroy the system with one badly typed command. There is no recycle bin, no confirmation and no "undo".

That is why Ubuntu takes a deliberate approach: the root account exists but is disabled for login. It has no valid password. Instead, sudo is used.

sudo stands for substitute user do: running a command as another user, root by default. Its logic:

1. You type sudo in front of the command.
2. sudo checks in /etc/sudoers whether you are authorised. Your operator user is, by belonging to the sudo group.
3. It asks for your own password (not root's, which does not even exist), to confirm that it is you at the keyboard.
4. It runs the command with administrator privileges and records the operation in /var/log/auth.log.
5. It remembers the authentication for about 15 minutes so it does not ask you on every command.

Check it with a clear example:

The same command returns a different user, because sudo ran it on root's behalf.

Another example where the difference is visible. The file /etc/shadow holds the password hashes and only root can read it:

That Permission denied is not a fault: it is the system working exactly as it should.

1. Traceability. Every use is logged with user, time and command. If three people administer the server, it is known who did what. With a shared root account, it is not.
2. A minimal surface. Only the specific command runs with privileges, not your whole session. The rest of the time you work as a normal user and you are protected from your own mistakes.
3. No root password to leak. It does not exist, so it cannot be stolen or shared.

• Think before you type sudo. The moment to hesitate is before pressing Enter.
• Read the whole command before running it, especially if you copied it from the internet. Never paste a sudo you do not understand.
• Do not use sudo su - out of habit to get a permanent root session. You lose all three advantages at once.
• Be suspicious of sudo rm -rf. It is the combination that has destroyed the most systems in history.

sudo is far more configurable than it looks — a user can be authorised for certain commands only, a password can be required or not, restrictions can be set per machine — and all of that is lesson 05-02.

Cutting the power on a running system has real consequences:

• Cached data not yet written. Linux keeps data pending disk writes in RAM in order to batch operations and gain performance. A power cut loses it.
• Inconsistent file systems. ext4 keeps a journal that allows recovery, but recovery can take time and is not always complete.
• Services not closed cleanly. A database that does not close properly may require recovery at start-up, or corrupt data.
• Temporary files and orphaned locks. On boot, some services refuse to start because they find a lock file from the previous session.

An orderly shutdown, by contrast, notifies each service so it can finish, flushes pending data to disk (sync), unmounts the file systems and only then powers off.

• shutdown : the orderly shutdown command.
• -h : halt, stop and power off the machine.
• now : immediately.

Scheduled, which is what you do on a server with connected users:

It shuts down in 10 minutes and sends that message to every user with an open session. It is elementary courtesy in a shared environment, and something Marta will appreciate.

If you change your mind:

It cancels the scheduled shutdown.

To reboot:

Equivalent to sudo shutdown -r now. It is what you will do after a kernel update.

Summary table:

You will see the systemd variants in lesson 05-05.

Logging out does not shut the server down: it only ends your shell. The server keeps running and serving requests.

Or the Ctrl+D shortcut. In an SSH session, both also close the connection.

A distinction to be clear about from day one: exit closes your session; shutdown powers the machine off. Confusing them on a remote server means taking the company's service down and, if it is a machine in a data centre with no physical access, being unable to switch it back on. It is a mistake you make once in your life and remember forever.

• Confusing terminal and shell. The terminal is the window; the shell is the program that interprets. Changing terminal emulator does not change your shell.
• Believing that free shows the available memory. The correct column is available. Linux uses free RAM as a cache on purpose.
• Ignoring that Linux is case sensitive. Documents and documents are different directories. It is the number one cause of "but the file is right there".
• Thinking the terminal is frozen when typing the password. Nothing is displayed, by design.
• Reaching for sudo automatically at any "Permission denied". Sometimes that message means you are doing something you should not be. Understand why before escalating privileges.
• Working as root as a matter of routine. With sudo su - you lose traceability and protection from your own mistakes.
• Shutting the server down when you meant to log out. exit to leave. shutdown only when you really want to power the machine off.
• Not using Tab. It is the habit that most distinguishes a beginner from someone with mileage: fewer typos and free verification that paths exist.
• Tip. Save the result of your initial reconnaissance in a document. Having a picture of a healthy system turns diagnosing a sick one into comparing rather than guessing.
• Tip. Practise the shortcuts deliberately for a week, even if at first typing the path by hand feels faster. The investment pays back in days.
• Tip. If you get lost or do not know where you are, three commands always reorient you: whoami, hostname and pwd (you will see the last one in 02-03).

You see this prompt in one of your terminals:

Answer:

1. Which user is active and how do you know without running any command?
2. Which directory are you in?
3. What concrete risk does this situation involve and what precaution would you take?
4. Write the prompt you would see if operator logged in to their home directory on the laptop laptop-student.

Marta asks you for a status report on srv-tramontana before approving the deployment of Tramontana Bookings. State which command you would use to obtain each piece of data, which specific option, and how you would interpret the result:

1. The exact Ubuntu and kernel versions.
2. Total and genuinely available memory.
3. Free space on the root partition.
4. Uptime and system load.
5. Whether the server is physical or virtual.

Then write the report in three or four sentences, as you would give it to Marta.

Diagnose and resolve these three situations that happen to you during your first day:

1. You run cat /var/log/auth.log and get Permission denied.
2. You launch a command that has not returned control for two minutes and shows nothing.
3. You want to leave your SSH session on srv-tramontana, you type sudo shutdown -h now and you lose the connection. Marta calls saying the bookings website is not responding. Explain what has happened, how it is fixed and how to avoid it.

Solution to Exercise 1

1. The user is root. There are two independent clues in the prompt itself. The first is explicit: the string before the @ says root. The second is the more important one and the one to learn to read at a glance: the prompt ends in # instead of $. That convention is universal in Unix and works even with customised prompts that hide the username.

2. In /etc. It is the part between : and #. The absolute path is shown because it is not the home directory (if it were, ~ would appear). /etc is the system configuration directory, which you will see in the next lesson.

3. The risk and the precaution. The combination is especially delicate: a root session inside the system configuration directory. Any typo can leave the server unable to boot or without remote access. A badly typed rm on /etc/ssh/ locks you out of the server; on /etc/fstab, it stops it booting. And there is no confirmation, no recycle bin and no undo.

Concrete precautions:

• Leave the root session with exit and work as operator, using sudo only for the commands that need it. You recover traceability and protection.
• If a prolonged root session really is needed, copy any file before editing it: cp /etc/fstab /etc/fstab.bak.
• Check the prompt before every destructive command, and use Tab to confirm that paths exist.
• In a VM, take a snapshot beforehand if you are going to touch critical configuration.

4. The prompt would be:

With ~ because they are in their home directory (/home/operator) and with $ because they are a normal user.

Solution to Exercise 2

1. Ubuntu and kernel versions.

lsb_release -a gives the distribution (Ubuntu 24.04.1 LTS, code name noble) and uname -r the kernel version (6.8.0-41-generic). An alternative that gives both at once: hostnamectl. They are independent numbering schemes and both must be reported.

2. Total and available memory.

-h for readable units. What you report is total (3.8 GB) and above all available (3.2 GB). You should not report free, because it counts the disk cache as "used", and that cache is released instantly if a program needs it.

3. Free space on root.

Passing / as an argument limits the output to the root partition. You report the available gigabytes (15 GB) and the usage percentage (30 %). The percentage is the actionable figure: above 80 % you have to plan.

4. Uptime and load.

It gives both. The load (0.08 0.12 0.09) is interpreted against the number of cores, which you get with nproc. With 2 cores, those values indicate a practically idle system.

5. Physical or virtual.

The lines Chassis: vm and Virtualization: oracle confirm it. A direct alternative: systemd-detect-virt, which returns oracle on VirtualBox or none on physical hardware.

Report for Marta:

"srv-tramontana runs Ubuntu 24.04.1 LTS with kernel 6.8.0-41 on a VirtualBox virtual machine, 64-bit architecture. It has 3.8 GB of memory, of which 3.2 GB are available, and it is not using swap. The root partition is 30 % of 23 GB used, with 15 GB free. The average load is 0.08 across 2 cores, meaning the system is practically idle, and it has been up for 2 days with no pending updates. There are plenty of resources to deploy Tramontana Bookings. I recommend reviewing disk space once the application starts generating logs, and watching that it does not go above 80 % usage."

Solution to Exercise 3

Situation 1 — Permission denied when reading /var/log/auth.log.

Diagnosis: it is not a system error, it is the system protecting itself. auth.log records every authentication attempt, including users and connection origins. That is sensitive information: it reveals which accounts exist and where they connect from. That is why it belongs to the adm group and is not readable by normal users.

Solution:

Or better, because the file is long and usually only the latest entries are of interest:

A more elegant alternative: the operator user could be added to the adm group, which has read permission on the logs, and could then consult them without sudo. It is the correct solution if logs are going to be reviewed frequently, and it appears in lesson 05-01.

General tip: faced with a Permission denied, the right reaction is not "I'll add sudo", but "why is this protected?". Here the answer is legitimate and sudo is justified. In other cases, the message is warning you that you are in the wrong place.

Situation 2 — A command has not responded for two minutes.

Diagnosis: there are three possibilities and it is worth distinguishing them before acting:

• The command is genuinely working and taking time (copying large files, updating packages, compressing). Remember the Unix principle: silence means success, many commands do not report their progress.
• The command is waiting for input from the keyboard. This happens if you typed cat with no arguments: it sits waiting for whatever you type.
• The command is blocked: waiting for a network connection that never arrives, or for a busy resource.

A progressive solution:

1. Ctrl+C to interrupt it. It sends SIGINT and in most cases it solves the problem.
2. If it was waiting for input, Ctrl+D closes the input and lets it finish cleanly.
3. If Ctrl+C does not respond, switch to another virtual terminal (Ctrl+Alt+F2) or open another SSH session, and from there identify and terminate the process. The tools for that — ps, kill — are lesson 03-06.
4. Rebooting the machine is the last resort, not the first.

Prevention: before launching something that may take a while, consider whether it should be run in the background or inside a persistent session (tmux, screen), especially if you are connected over SSH and the connection could drop.

Situation 3 — You have shut down the production server.

What has happened: you confused logging out with powering the machine off. sudo shutdown -h now performed an orderly, immediate shutdown of srv-tramontana. The SSH connection dropped because the server was shutting down, not because there was a network problem. And Tramontana Bookings is not responding because the server hosting it is switched off. There is no data corruption — the shutdown was orderly — but there is a service outage.

How it is fixed:

• On a local VM: open VirtualBox and start it. One minute.
• On an accessible physical server: press the power button.
• On a remote server with no physical access: this is where the real seriousness of the mistake lies. You need an out-of-band console — IPMI, iDRAC, iLO — or the cloud provider's control panel. If you have none of those routes, the server cannot be powered on remotely, and somebody has to travel there physically. In a data centre in another city, that means hours of downtime.

How to avoid it, in order of effectiveness:

1. Use exit or Ctrl+D to log out. shutdown only when you really want to power the machine off. It is the rule that solves 100 % of cases.
2. Read the prompt before every dangerous command. The hostname is there precisely for this: srv-tramontana is not your laptop.
3. Make production terminals visually distinct, with different colours or prompts. In Module 3 you will see how to customise PS1; putting the production prompt in red is a very widespread and very effective practice.
4. On a real server, always give notice first: sudo shutdown -h +10 "Scheduled maintenance" leaves room to cancel with sudo shutdown -c if you realise your mistake.
5. Verify that a remote power-on route exists before shutting down any machine that is not in front of you. It is a two-minute check that prevents a disaster.

You are no longer looking at an incomprehensible black screen. In this lesson you have seen:

• What happens when you log in: the chain systemd → getty → login → shell, and the message of the day as a dashboard.
• The prompt character by character: user, machine, directory, and the $ versus the # that warns you that you are root.
• The difference between console, terminal, TTY and emulator, and the six virtual terminals as a lifeline.
• What the shell is, why Bash and how it differs from the terminal.
• Why a server carries no desktop, and what X11, Wayland, GNOME and KDE are.
• The anatomy of a command: command [options] [arguments], short and long options.
• The initial reconnaissance of srv-tramontana with uname, hostnamectl, uptime, free -h and df -h, and how to interpret what they say, including the trap of the free column.
• The survival shortcuts, with Tab as the most profitable habit.
• The normal user / root distinction and the responsible use of sudo.
• How to shut down, reboot and log out properly, and why you do not pull the plug.

You know who you are, which machine you are on and what state it is in. One last piece of orientation is missing: where you are, and above all, what is around you.

In the next lesson, The Linux File System Structure, you will see why on Linux there are no C: or D: drives but a single tree growing from /, you will walk through the FHS standard directories one by one, you will really understand what "everything is a file" means and what /proc and /sys are. And with that map in hand you will justify, standard in hand, why the Tramontana application goes in /opt/tramontana/app, its configuration in /etc/tramontana/, its logs in /var/log/tramontana/ and the backups in /srv/tramontana/backups. It is the lesson that turns the file system into familiar territory.