# 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.

| Hypervisor type | Where it runs | Examples |
| --- | --- | --- |
| Type 1 — bare-metal | Directly on the physical hardware | VMware ESXi, Microsoft Hyper-V, KVM-based platforms |
| Type 2 — hosted | As an application on a host operating system | Oracle VirtualBox, VMware Workstation |

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:

```bash
ssh username@server-ip
```

For example:

```bash
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:

```bash
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:

```bash
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:

| Service | Purpose |
| --- | --- |
| `httpd` | Runs the Apache HTTP web server |
| `sshd` | Accepts remote SSH connections |
| `firewalld` | Manages firewall rules |
| `chronyd` | Keeps system time synchronized |
| `tuned` | Applies system performance-tuning profiles |

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:

```bash
systemctl action unit
```

For example:

```bash
systemctl restart httpd
```

Here:

*   `systemctl` is the management command.
    
*   `restart` is the requested action.
    
*   `httpd` is the service being managed.
    

### Common systemctl commands

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

These actions are not interchangeable:

| Command | What it changes |
| --- | --- |
| `start` | Starts the service in the current session |
| `stop` | Stops it now |
| `restart` | Stops and starts it again; useful after many configuration changes |
| `status` | Shows whether it is running and displays recent status information |
| `enable` | Configures it to start automatically at boot |
| `disable` | Prevents automatic startup at boot; it does not necessarily stop a running service |

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

```bash
systemctl enable --now httpd
```

To verify both conditions separately:

```bash
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:

```bash
systemctl cat httpd
```

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

```bash
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

```bash
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

```bash
systemctl enable --now httpd
```

### Step 3: Check its status

```bash
systemctl status httpd
```

### Step 4: Create a simple web page

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

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

### Step 5: Test it locally

```bash
curl http://localhost
```

If Apache is working, the terminal should return:

```text
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:

```bash
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:

```bash
firewall-cmd --list-all
```

The complete request path now looks like this:

```text
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?**
    
    ```bash
    rpm -q httpd
    ```
    
2.  **Is the service running?**
    
    ```bash
    systemctl status httpd
    ```
    
3.  **What do its logs say?**
    
    ```bash
    journalctl -u httpd --since today
    ```
    
4.  **Is it listening on the expected port?**
    
    ```bash
    ss -ltnp | grep ':80'
    ```
    
5.  **Does it work locally?**
    
    ```bash
    curl http://localhost
    ```
    
6.  **Does the firewall allow the traffic?**
    
    ```bash
    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:

```bash
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

| DNF | Flatpak |
| --- | --- |
| Manages RPM packages | Manages Flatpak applications and runtimes |
| Used for system packages, services, libraries, and command-line tools | Used mainly for graphical desktop applications |
| Integrates closely with RHEL | Runs applications with sandboxing and Flatpak runtimes |
| Uses configured RPM repositories | Uses configured Flatpak remotes |

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:

```bash
dnf install -y flatpak
```

### See configured remotes

```bash
flatpak remotes
```

### Add Flathub for the current user

```bash
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

```bash
flatpak search firefox
```

### Understand the application ID

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

```text
org.mozilla.firefox
```

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

### Install an application

```bash
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

```bash
flatpak list
```

To show only applications and hide runtimes:

```bash
flatpak list --app
```

### Run an application

```bash
flatpak run org.mozilla.firefox
```

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

### Update applications and runtimes

```bash
flatpak update
```

### Uninstall an application

```bash
flatpak uninstall --user org.mozilla.firefox
```

### User installation vs system installation

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

```bash
# 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

```bash
# 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](https://github.com/anousheh-hussain/cloud-devops-notes)
    

## References

*   [Red Hat Enterprise Linux 10 — Setting up the Apache HTTP web server](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/deploying_web_servers_and_reverse_proxies/setting-up-the-apache-http-web-server)
    
*   [Red Hat Enterprise Linux 10 — Installing applications by using Flatpak](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/administering_rhel_by_using_the_gnome_desktop_environment/installing-applications-by-using-flatpak)
    
*   [Flatpak documentation — Using Flatpak](https://docs.flatpak.org/en/latest/using-flatpak.html)
    

* * *

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