Installed is not running: serve your first Linux page

The installer finishes, returns your prompt, and leaves you with a reasonable question: where is the web page?

Installing the software is only one part of serving it. A program must be running, and that program needs the directory to read and the address where it should listen. In this lab, you will connect those pieces yourself, then change the port to see which setting the program actually follows.

Use the disposable Ubuntu VM with administrator permission and a synthetic practice page you control. These commands use Ubuntu’s configured repositories to install Python 3 and curl. On an employer-managed machine, follow the approved package process instead.

sudo apt update
apt-cache policy python3 curl
sudo apt install python3 curl
python3 --version
curl --version
dpkg-query -W -f='${Package} ${Version}
' python3 curl

Ubuntu tracks the installed software as packages. An executable is the program you can run. Installing the python3 package supplies the interpreter and its required files; it does not create your page or start a program listening for requests. The prompt has returned because installation finished, not because the page is being served.

Which software did the installer leave behind?

apt update refreshes the list of packages available from the repositories. It does not upgrade everything already installed. apt install works on the named packages and their required dependencies, and may update a named package when a newer candidate is available. Read the proposed transaction before accepting it so you know which changes it is about to make.

The version commands and dpkg-query show what is actually on this guest. Keep their output with the exercise. If a command later behaves differently from a tutorial, those versions give you a place to begin the comparison. Staying with Ubuntu’s supported repositories also keeps this first package workflow consistent.

Put a running program in front of the page

Here is the page and the command that will serve it. The printf command writes the practice text into index.html, replacing that file’s existing contents.

mkdir -p ~/linux-basics/service
printf 'Dispatch practice service
' > ~/linux-basics/service/index.html
python3 -m http.server 8080 --bind 127.0.0.1 --directory ~/linux-basics/service

The last command stays busy in the foreground rather than returning the prompt. Open a second terminal into the same guest and request the page from there:

curl -i http://127.0.0.1:8080/

You should receive HTTP 200 and the practice text. The address 127.0.0.1 points back to the guest itself; it is the guest’s loopback address. Your host’s browser lives on a different machine from this point of view. Using a second guest terminal keeps the first request in the same place as the listener.

Now press Ctrl+C in the server terminal and repeat curl. The connection should fail because the process listening on port 8080 has stopped. The file is still there. Python is still installed. You have changed only the running process, and the difference appears immediately in the client’s result.

These pieces can vary independently. Software may be installed but stopped, running at another address, or answering from the wrong directory. To see another of those differences, we can move the listener while leaving the page alone.

The settings file the server never reads

First write down the intended settings and make a backup:

printf 'port=8080
bind=127.0.0.1
' > ~/linux-basics/service.conf
cp -p ~/linux-basics/service.conf ~/linux-basics/service.conf.backup

The filename looks promising, but Python’s built-in server does not automatically read this service.conf. It is our note about what we intend. The arguments in the launch command tell the program what to do. A perfectly edited note can therefore sit beside a server that has not changed at all.

Change the note to port 8081. Stop the old foreground server, then run the earlier Python command with 8081 instead of 8080. From the second guest terminal, request http://127.0.0.1:8081/, then the old 8080 URL. With only the new server running, the first should return the page and the second should fail to connect.

The launch argument moved the listener. Editing the note alone would not have done it. To return to the starting arrangement, copy service.conf.backup over the note, stop the 8081 process and launch the original 8080 command. Check the original URL again. This time the note and the running program agree because both were restored.

Restore the service without removing its tools

Returning this exercise to its earlier state means restoring the page and port. Python and curl can stay installed for the next lesson. Uninstalling or downgrading a package would change more than this small experiment needs, and package removal can leave configuration files behind anyway.

The foreground server is for development, not a hardened production website. The next lesson gives it systemd supervision inside the same private lab. You will already know what that manager must arrange: start the installed program with the right inputs, then let a client check whether the intended page comes back.

Package management and the development server

Ubuntu’s package-management documentation explains apt and dpkg. The Python http.server documentation covers its binding and directory options, along with the security limitations that make it unsuitable for production use.