The Logbook #08 - Linux Behind the Scenes: Services, SSH, Firewalls, and Flatpak

When I first started using Linux, I learned commands one at a time. I knew that systemctl start httpd started a web server and that ssh connected me to another machine—but I did not fully understand what was happening behind those commands.

This week, I focused on connecting those pieces.

In this post, I will cover a few foundational terms, explain how Linux services are managed with systemd, set up a simple Apache web server, and finally look at how Flatpak installs desktop applications differently from DNF.

Note: I practised these commands on Red Hat Enterprise Linux (RHEL) while logged in as the root user, as we do during system-administration practice. Therefore, the administrative commands below do not use sudo. On a regular user account, equivalent commands require appropriate privileges.

1. A Few Terms That Made Everything Easier

Before working with services and software, it helps to understand a few terms that appear everywhere in Linux.

Configuration file

A configuration file is a file that stores settings used by a program or service.

Instead of changing the program's source code, we edit its configuration to control how it behaves. For example, a web server's configuration can define which port it listens on, where website files are stored, and which modules are enabled.

Configuration files are commonly found inside /etc.

Plug-in

A plug-in is an additional component that adds a feature to an existing program without replacing the entire program.

For example, a plug-in may add authentication support, a new command, or integration with another tool.

Bare metal

Bare metal means a physical computer running an operating system directly on its hardware, without a virtualization layer between them.

Virtual machine and hypervisor

A virtual machine (VM) is a software-created computer with its own virtual CPU, memory, storage, and operating system.

A hypervisor creates and manages virtual machines by allocating physical resources to them.

I use VMware Workstation on my laptop to run a RHEL virtual machine, so that is a Type 2 hypervisor setup.

2. What Does SSH Actually Do?

SSH (Secure Shell) lets us securely access and control another machine over a network.

Suppose my laptop needs to manage a remote Linux server:

• My laptop is the SSH client because it initiates the connection.

• The remote machine is the SSH server because it accepts the connection.

• The sshd daemon on the server listens for SSH connections.

• SSH normally uses TCP port 22.

To connect, I can run:

ssh username@server-ip

For example:

ssh zia@192.168.1.50

Once the connection is established, commands typed in my terminal are executed on the remote machine, not on my laptop. SSH encrypts the communication between the client and server.

SSH authentication

Two common ways to authenticate are:

1. Password authentication — enter the remote user's password.

2. SSH key authentication — the client keeps a private key, while the matching public key is placed on the server.

The private key must remain secret. The public key can safely be copied to the server.

Checking the SSH service

The remote server needs its SSH service running:

systemctl status sshd
systemctl enable --now sshd

The second command both starts sshd now and enables it to start automatically during future boots.

If firewalld is running on the server, SSH must also be allowed through the appropriate firewall zone:

firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload

Opening SSH on my laptop is not required merely to connect out to another machine. The firewall rule matters on the machine accepting incoming SSH connections.

3. Services and Daemons in Linux

A service is a program or process that provides a function, usually in the background.

Examples include:

A daemon is a background process that waits for work or continuously provides a service. Many daemon names end in d, such as sshd and httpd, although this is a convention rather than a strict rule.

What is systemd?

systemd is the system and service manager used by RHEL and many other Linux distributions.

During boot, the Linux kernel starts systemd as the first user-space process, normally with Process ID (PID) 1. systemd then starts the services and other units required by the system.

What is systemctl?

systemctl is the command-line tool used to communicate with systemd.

The basic pattern is:

systemctl action unit

For example:

systemctl restart httpd

Here:

• systemctl is the management command.

• restart is the requested action.

• httpd is the service being managed.

Common systemctl commands

systemctl start httpd
systemctl stop httpd
systemctl restart httpd
systemctl status httpd
systemctl enable httpd
systemctl disable httpd

These actions are not interchangeable:

To start a service now and enable it for future boots in one command:

systemctl enable --now httpd

To verify both conditions separately:

systemctl is-active httpd
systemctl is-enabled httpd

What is a unit file?

systemd manages resources as units. A service unit file, such as httpd.service, contains instructions that tell systemd how the service should be started, stopped, and supervised, along with dependencies and boot-related settings.

Common unit-file locations include:

• /usr/lib/systemd/system/ for files supplied by installed packages

• /etc/systemd/system/ for administrator-created units and overrides

• /run/systemd/system/ for temporary runtime units

To see the unit file used for a service:

systemctl cat httpd

If a unit file is manually added or changed, tell systemd to reread its unit definitions:

systemctl daemon-reload

This reloads systemd's unit-file configuration. It does not automatically restart the service itself.

4. Practical Example: Running an Apache Web Server

Apache HTTP Server provides web pages to clients. On RHEL, its package and service are called httpd.

Step 1: Install Apache

dnf install -y httpd

dnf installs the httpd package and its required dependencies from configured RPM repositories.

Step 2: Start it now and at boot

systemctl enable --now httpd

Step 3: Check its status

systemctl status httpd

Step 4: Create a simple web page

Apache's default document root on RHEL is /var/www/html.

echo "Hello from The Logbook" > /var/www/html/index.html

Step 5: Test it locally

curl http://localhost

If Apache is working, the terminal should return:

Hello from The Logbook

Step 6: Allow HTTP through the firewall

If other machines need to open the page and firewalld is active, allow the predefined HTTP service:

firewall-cmd --permanent --add-service=http
firewall-cmd --reload

HTTP normally uses TCP port 80, while HTTPS normally uses TCP port 443.

The --permanent option saves the rule so it remains after reboot. --reload applies the permanent configuration to the running firewall.

Check the active firewall configuration with:

firewall-cmd --list-all

The complete request path now looks like this:

Browser -> server firewall -> httpd -> /var/www/html/index.html

The service may be running correctly while the website is still unreachable from another machine if the firewall blocks HTTP. That is why checking only systemctl status httpd is not always enough.

A simple troubleshooting order

When a service does not work, I now check it layer by layer:

1. Is the package installed?

   rpm -q httpd
   

2. Is the service running?

   systemctl status httpd
   

3. What do its logs say?

   journalctl -u httpd --since today
   

4. Is it listening on the expected port?

   ss -ltnp | grep ':80'
   

5. Does it work locally?

   curl http://localhost
   

6. Does the firewall allow the traffic?

   firewall-cmd --list-services
   

This order helps separate a service problem from a network or firewall problem.

5. Flatpak: A Different Way to Install Applications

Normally, RHEL installs software as RPM packages using DNF. These packages are built for the distribution and use libraries available on the operating system.

For example:

dnf install package-name

This approach integrates applications closely with the operating system, but desktop application developers may need to package their software differently for multiple Linux distributions. A distribution's repositories may also intentionally provide an older, well-tested version instead of the newest release.

Flatpak provides another way to distribute and run applications across Linux distributions.

A Flatpak application uses:

• The application itself

• A runtime containing shared libraries needed by multiple applications

• Any additional dependencies that are not already supplied by that runtime

• A sandbox that limits the application's access to the rest of the system

This reduces dependency and compatibility problems, although Flatpak applications can use more disk space because runtimes and additional components must also be installed.

Repository vs remote

Flatpak downloads applications and runtimes from repositories. A configured source pointing to one of these repositories is called a remote.

One well-known remote is Flathub, which hosts Flatpak applications from many publishers. A remote is the source; Flatpak is the tool that communicates with it.

A sandbox improves isolation, but it does not automatically make every application trustworthy. The publisher and requested permissions still matter.

DNF and Flatpak are not replacements for each other

Flatpak does not replace DNF. I would use DNF for components such as httpd, system utilities, libraries, and administrative tools. Flatpak is useful for desktop applications.

On RHEL 10, Flatpak is especially relevant because Flatpaks are the default delivery method for Firefox and Thunderbird.

6. Essential Flatpak Commands

Install Flatpak itself

Flatpak is first installed as a normal RPM package:

dnf install -y flatpak

See configured remotes

flatpak remotes

Add Flathub for the current user

flatpak remote-add --user --if-not-exists flathub \
https://dl.flathub.org/repo/flathub.flatpakrepo

Here:

• --user configures the remote only for the current user.

• --if-not-exists avoids an error if it has already been added.

• flathub is the local name assigned to the remote.

Search for an application

flatpak search firefox

Understand the application ID

Flatpak applications have unique IDs, usually written in reverse-domain style:

org.mozilla.firefox

Using the application ID avoids confusion when applications have similar names.

Install an application

flatpak install --user flathub org.mozilla.firefox

This means: use Flatpak, install for the current user, get the application from the flathub remote, and select the application with the ID org.mozilla.firefox.

List installed Flatpaks

flatpak list

To show only applications and hide runtimes:

flatpak list --app

Run an application

flatpak run org.mozilla.firefox

Desktop environments normally add installed applications to the graphical application menu as well.

Update applications and runtimes

flatpak update

Uninstall an application

flatpak uninstall --user org.mozilla.firefox

User installation vs system installation

A Flatpak can be installed for one user or for the entire system:

# Current user only
flatpak install --user flathub application-id

# System-wide
flatpak install --system flathub application-id

Using --user is often convenient for a personal desktop because it does not affect other users.

What Finally Clicked for Me

The biggest lesson this week was that Linux problems are often made of multiple layers.

Installing httpd gives the system the required program. Starting it creates the running service. Enabling it controls what happens after reboot. The firewall decides whether remote traffic can reach it. Its configuration and content files decide how it behaves and what it serves.

Flatpak follows a different model: it focuses mainly on portable desktop applications, shared runtimes, remotes, and sandboxing. It complements the system package manager instead of replacing it.

Understanding what each layer is responsible for makes the commands much easier to remember—and makes troubleshooting feel far less random.

Quick Command Recap

# Manage services
systemctl enable --now httpd
systemctl status httpd
systemctl restart httpd
systemctl is-active httpd
systemctl is-enabled httpd

# Check logs
journalctl -u httpd --since today

# Allow HTTP through firewalld
firewall-cmd --permanent --add-service=http
firewall-cmd --reload

# Manage Flatpak applications
flatpak remotes
flatpak search application-name
flatpak install --user remote-name application-id
flatpak list --app
flatpak run application-id
flatpak update
flatpak uninstall --user application-id

Detailed Notes on GitHub

• Cloud and DevOps Notes

References

• Red Hat Enterprise Linux 10 — Setting up the Apache HTTP web server

• Red Hat Enterprise Linux 10 — Installing applications by using Flatpak

• Flatpak documentation — Using Flatpak

This post is part of The Logbook, where I document what I learn while building practical Linux, cloud, and DevOps skills.