Clients, servers and shared resources¶

Exercise clients-servers-and-shared-resources-annex.pdf · PDF

This morning you sent a photo. Where is it now? Not only in your phone. It sits on a computer you have never seen, and that computer handed it to your friend the moment their phone asked for it.

That computer is a server. Until now you configured one machine (Unit 5) and connected machines together (Unit 3). From today, one machine works for the others. In this unit you build a real one, step by step, for a real-looking company.

The restaurant: clients, servers, services¶

All year the computer was a kitchen. Today the kitchen opens to the public. Picture it: a kitchen with three small serving windows (hatches), each with a number painted above it, and customers waiting outside.

flowchart LR
    subgraph CLIENTS ["Clients (the customers)"]
        direction TB
        C1["<b>deb-lab</b><br>asks for a shell"]
        C2["<b>win11</b><br>asks for a file"]
    end
    subgraph SRV ["ubu-srv (the kitchen)"]
        direction TB
        P22["<b>port 22</b><br>SSH hatch"]
        P445["<b>port 445</b><br>file-sharing hatch"]
        P631["<b>port 631</b><br>printing hatch"]
    end
    C1 -->|"SSH protocol"| P22
    C2 -->|"SMB protocol"| P445

A server is a role, not a kind of box: a program that offers a service to other machines.

Your laptop is a client when it opens a web page and a server when it shares a folder. The same machine can do both in the same second.

Local and network resources¶

A resource is anything useful a computer can offer: files, a printer, a program, a shell, Internet access.

• A local resource is inside or plugged into your own machine.
• A network resource is given to you by another machine, through the network.

What do you lose when the network cable is cut? Everything in the right-hand column. And what do you gain with it? One copy for everybody, one backup, one place to give permissions.

Find the services on your machine¶

Each service waits on a port. The command ss (socket statistics) lists them:

ss -tln
sudo ss -tlnp        # -p adds the program name; needs sudo to see them all

• -t = TCP, -l = only listening sockets, -n = show numbers instead of names, -p = which program.

A typical line on ubu-srv:

LISTEN 0 4096 0.0.0.0:22 0.0.0.0:*

Read it as: something waits on port 22, on every address of this machine. The part before the colon tells you who can reach it:

What you will probably find:

The unit project: the Tramuntana office server¶

Tramuntana Apps is a 12-person app studio in Palma. Today every file lives on somebody's laptop, the designers send logos by chat, and nobody knows which copy is the latest one. When Pau's laptop died, a week of work died with it.

The company buys one small server. You are the person they hire to set it up. Your server is the VM ubu-srv (Ubuntu Server 26.04 LTS, no desktop); the clients are deb-lab (Debian 13) and win11. By 20 May it must offer:

Three rules for the whole project:

1. Snapshot first. Take a snapshot of ubu-srv before each session. If you break it, you go back ten minutes, not five weeks.
2. Check from a client. A service works when a client can use it, not when the install command ends.
3. Least privilege. Everybody gets what the job needs and nothing more. Permissions go to groups, not to people.

At the end of every session you add an entry to ~/server-log.md: the date, what you changed (file or command), how you checked it, and one problem you had with its solution. In Unit 7 this log becomes the server's documentation.

Give the server an address and a name¶

A client finds a server by its address. If DHCP gives ubu-srv a different address next week, every client is lost. So servers get a static IP address, one that never changes. Ours is 192.168.122.10, inside the virtual network default of virt-manager (192.168.122.0/24, gateway and DNS 192.168.122.1).

First find the interface name:

ip -br a

Then create /etc/netplan/60-static.yaml with sudo nano. Netplan is Ubuntu's network configuration tool, and its files are written in YAML, a format where indentation is the structure:

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: false
      addresses: [192.168.122.10/24]
      routes:
        - to: default
          via: 192.168.122.1
      nameservers:
        addresses: [192.168.122.1]

sudo chmod 600 /etc/netplan/60-static.yaml
sudo netplan try          # press Enter when it asks, if you see no error
ip -br a
ping -c 3 192.168.122.1

netplan try applies the change and rolls it back by itself after 120 seconds if nobody presses Enter. That is the safety net when you change the network of a machine you may not be able to touch.

Now the client needs a name for the server. On deb-lab:

echo "192.168.122.10 ubu-srv" | sudo tee -a /etc/hosts
ping -c 3 ubu-srv

/etc/hosts is the machine's local phone book: it is read before DNS is asked. If ping ubu-srv fails, the line is missing or has a typo.

Who works here: groups and users¶

Marta sits at her laptop and wants a file on the server. How does the server know she is Marta? She needs an account on the server. Accounts on deb-lab do not exist on ubu-srv: each machine has its own /etc/passwd.

On ubu-srv:

for g in dev design admin; do sudo groupadd $g; done
sudo useradd -m -s /bin/bash -G dev marta
sudo useradd -m -s /bin/bash -G dev pau
sudo useradd -m -s /bin/bash -G design joan
sudo useradd -m -s /bin/bash -G admin aina
for u in marta pau joan aina; do sudo passwd $u; done

Check the result with id marta and getent group dev (it should list marta,pau). Then ask the most important question: what can each user do?

$ sudo -l -U aina
User aina may run the following commands on ubu-srv:
    (ALL) ALL

Aina, from the administration department, can run every command as root. Nobody gave her that. Look for the reason:

sudo grep -n admin /etc/sudoers

Ubuntu ships the line %admin ALL=(ALL) ALL in /etc/sudoers: an old rule from the years when Ubuntu's administrators were in a group called admin. We created a group with the same name for a different reason, and it inherited the power. Fix it with sudo visudo: put # in front of that line, save (Ctrl+O, Enter, Ctrl+X) and check again:

$ sudo -l -U aina
User aina is not allowed to run sudo on ubu-srv.

Finally, create the folders the next sessions will share, and start your log:

sudo mkdir -p /srv/samba /srv/nfs
ls -ld /srv/samba /srv/nfs
nano ~/server-log.md

Key takeaways¶

• A server is a role: a program that offers a service to clients. The same machine can be both.
• A local resource is on your machine; a network resource is given by another machine, and gives one copy, one backup and one place for permissions.
• Each service waits on a port. ss -tln lists them; 0.0.0.0 means the network can reach it, 127.0.0.1 means localhost only.
• A server needs a static IP address (Netplan on Ubuntu, netplan try as the safety net) and a name the clients resolve (/etc/hosts before DNS).
• Each machine has its own accounts. Give permissions to groups, and always check what a user can do: on Ubuntu a group called admin gets sudo.

Quick check¶

Today you sat in front of the server's console. A real server lives in a locked room: next, you learn to manage it without ever touching it, with SSH remote access.