How To Install Apache on Fedora 44

Install Apache on Fedora 44

You need a web server but Fedora 44’s default package names confuse you. You have tried generic Linux guides that fail because they use Debian commands on RPM systems. This guide solves that problem by showing you exactly how to install Apache on Fedora 44 using the correct httpd package, proper systemd commands, and Fedora-specific firewall and SELinux configuration.

By following these 8 steps, you will have Apache running, port 80 open through firewalld, SELinux properly configured, and a working virtual host. This is not theory. Every command is tested on Fedora 44 released April 2026, which ships Apache httpd 2.4.66 from the official repositories.

Table of Contents

Prerequisites

Before you begin, confirm you have these requirements:

  • Operating System: Fedora 44 Workstation or Server (released April 2026)
  • User Permissions: A user account with sudo privileges (not root)
  • Terminal Access: Local terminal or SSH connection to your server
  • Network: Internet connectivity to download packages from Fedora repositories
  • Package Manager: dnf available (Fedora 44 uses dnf as the default package manager)
  • Firewall: firewalld active and running (default on Fedora 44)
  • SELinux: Enabled in Enforcing mode (default on Fedora 44)
  • Port Availability: Port 80 not already used by another service (check with sudo ss -tlnp | grep :80)

Step 1: Update Your System and Install Apache (httpd)

Why You Must Update First

Before installing any package, update your system to get the latest security patches. Fedora 44’s repositories contain Apache httpd version 2.4.66, which includes fixes for known vulnerabilities. Running an outdated system means you might install an older cached version that lacks these security updates.

Update Your System

Run this command to update all packages to their latest versions:

sudo dnf update -y

What this command does:

  • sudo runs the command with administrative privileges
  • dnf is Fedora’s package manager (replaces the deprecated yum command)
  • update fetches the latest package metadata and upgrades installed packages
  • -y automatically confirms the installation without prompting you

Expected output:

Updating and loading repositories
Repositories loaded
Package fedora-release-44-1.fc44.noarch updated
...
Dependency resolved
Upgrade 15 Packages
Total download size: 125 MB
Running transaction check
Transaction test succeeded
Running transaction
...
Complete!

The Complete! message confirms the update finished successfully.

Install the httpd Package

Now install Apache using the correct Fedora package name:

sudo dnf install httpd -y

What this command does:

  • httpd is the Apache package name on RPM-based systems (Fedora, RHEL, CentOS)
  • On Debian/Ubuntu systems, the package is called apache2, which does not exist on Fedora
  • Using sudo dnf install apache2 will fail with “no match” error on Fedora

Expected output:

Updating and loading repositories
Repositories loaded
Package httpd-2.4.66-4.fc44.x86_64 will be installed
Package httpd-core-2.4.66-4.fc44.x86_64 will be installed
Package httpd-filesystem-2.4.66-4.fc44.x86_64 will be installed
Package apr-1.7.2-7.fc44.x86_64 will be installed
Package apr-util-1.6.3-10.fc44.x86_64 will be installed
Dependency resolved
Install 5 Packages
Total download size: 18 MB
Running transaction check
Transaction test succeeded
Running transaction
...
Complete!

Why this specific version matters: Fedora 44 ships httpd 2.4.66-4.fc44, confirmed in the official Fedora Packages repository. This version includes modern HTTP/2 support and security fixes.

Verify the Installation

Confirm Apache installed correctly by checking the package and version:

rpm -q httpd

What this command does:

  • rpm is the Red Hat Package Manager
  • -q queries installed packages
  • This returns the exact package name and version installed

Expected output:

httpd-2.4.66-4.fc44

Now verify the server version:

httpd -v

What this command does:

  • Runs the httpd binary with the -v flag to print version information
  • Confirms the binary is accessible in your PATH

Expected output:

Server version: Apache/2.4.66 (Unix)
Server built:   Apr 27 2026 12:34:56

The Server built date shows when Fedora packaged this version.

Step 2: Start and Enable the Apache Service

Why You Need Both Start and Enable

Fedora 44 uses systemd to manage services. Starting a service makes it run now, but it stops when you reboot. Enabling a service registers it to start automatically on every boot. You must do both for a production web server.

Start Apache Immediately

sudo systemctl start httpd

What this command does:

  • systemctl is the systemd control utility
  • start launches the service immediately
  • httpd is the service name (not apache or apache2)

Why not use the legacy service command: The service httpd start command is deprecated on Fedora 44. systemctl provides better status output, respects service dependencies, and is the official interface.

Enable Apache at Boot

sudo systemctl enable httpd

What this command does:

  • Creates a symlink in /etc/systemd/system/multi-user.target.wants/
  • This tells systemd to start httpd during the multi-user boot phase
  • Without this, Apache will not run after a reboot

Combine Start and Enable

You can run both commands in one line:

sudo systemctl enable --now httpd

What the --now flag does:

  • Starts the service immediately (like start)
  • Enables it for boot (like enable)
  • Reduces the chance of forgetting one step

Verify the Service Status

sudo systemctl status httpd

What this command does:

  • Shows the current state of the httpd service
  • Displays the last 10 log lines from the service
  • Shows the process ID (PID) and memory usage

Expected output:

● httpd.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
     Active: active (running) since Mon 2026-06-15 10:45:23 WIB; 2min ago
   Main PID: 12345 (httpd)
      Tasks: 8 (limit: 512)
     Memory: 45.2M
     CGroup: /system.slice/httpd.service

Key indicators to check:

  • Loaded: loaded means systemd found the service file
  • Active: active (running) confirms the service is running
  • enabled means it will start on boot
  • Main PID shows the process ID

If you see Active: inactive (dead), the service failed to start. Check the error log in Step 8.

Step 3: Configure the Firewall to Allow HTTP Traffic

Why Fedora Blocks Port 80 by Default

Fedora 44’s firewalld operates in a default-deny posture. All inbound traffic is blocked unless you explicitly permit it. This protects new services from accidental exposure. Installing Apache does not automatically open port 80—you must do this manually.

Check Current Firewall Status

sudo firewall-cmd --state

Expected output:

running

If you see not running, start it:

sudo systemctl start firewalld
sudo systemctl enable firewalld

Open HTTP (Port 80)

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

What this command does:

  • --add-service=http adds the predefined HTTP service rule
  • This opens port 80/tcp for inbound traffic
  • --permanent writes the rule to disk so it survives reboot

Why --permanent is required: Without this flag, the rule exists only in runtime memory. The next firewalld reload or system reboot deletes it, and your website becomes inaccessible.

Open HTTPS (Port 443)

sudo firewall-cmd --permanent --add-service=https

Why open HTTPS now even without SSL configured:

  • Modern browsers increasingly reject plain HTTP connections
  • Adding the firewall rule now costs nothing and saves a return trip later
  • You will configure TLS certificates in the next steps section

Reload the Firewall

sudo firewall-cmd --reload

What this command does:

  • Applies all --permanent rules to the running firewall
  • Without reload, the rules you added are not active yet

Verify Open Ports

sudo firewall-cmd --list-all

Expected output:

public:
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: ssh dhcpv6-client http https
  ports:
  protocols:
  forward: no
  masquerade: no
  icmp-blocks:
  rich rules:

What to confirm:

  • http and https appear in the services: line
  • Your interface (e.g., eth0) is listed under interfaces:

If http or https is missing, reload the firewall again and check for typos.

Step 4: Adjust SELinux for Apache

What SELinux Is and Why You Should Not Disable It

SELinux (Security-Enhanced Linux) is mandatory access control enforced by default on Fedora 44. It operates in Enforcing mode, which blocks processes from accessing files or ports outside their policy even if Unix permissions allow it.

Why not disable SELinux: Disabling it removes a critical security layer. A misconfigured Apache without SELinux can expose your entire filesystem. A properly configured Apache with SELinux only serves files in /var/www/html and cannot read /etc/passwd even with root permissions.

Check SELinux Status

sestatus

Expected output:

SELinux status:                 enabled
SELinux enablement:             enabled
Current mode:                   enforcing
Mode from config file:          enforcing
Policy from config file:        targeted

Key line: Current mode: enforcing confirms SELinux is active.

Default httpd SELinux Contexts Work Automatically

Fedora ships pre-built SELinux policies for httpd. The default document root /var/www/html already carries the httpd_sys_content_t type, so standard installs work without SELinux changes.

Why this matters: This explains why Apache works immediately after installation but breaks when you move content to a custom directory like /srv/mysite.

Configure SELinux for Custom Document Roots

If you want to serve content from a non-standard path (e.g., /srv/mysite), you must add a SELinux rule:

sudo dnf install -y policycoreutils-python-utils

What this installs:

  • policycoreutils-python-utils provides the semanage command
  • This tool manages SELinux policy rules
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/mysite(/.*)?"

What this command does:

  • semanage fcontext manages file context rules
  • -a adds a new rule
  • -t httpd_sys_content_t sets the SELinux type to “web content”
  • "/srv/mysite(/.*)?" matches the directory and all files inside it
sudo restorecon -Rv /srv/mysite/

What this command does:

  • restorecon applies the SELinux policy to files on disk
  • -R recurses into subdirectories
  • -v prints verbose output showing what changed

Why both commands are required: semanage fcontext registers the rule in the policy database, but restorecon actually labels the files. Without restorecon, Apache still cannot read the files.

Verify SELinux Context

ls -Z /srv/mysite/

Expected output:

unconfined_u:object_r:httpd_sys_content_t:s0 index.html

The httpd_sys_content_t type in the middle confirms SELinux allows Apache to read this file.

Step 5: Test Apache in Your Browser

Open Your Browser and Navigate

Open Firefox, Chrome, or any browser and enter:

http://localhost

Or if testing from another machine:

http://YOUR_SERVER_IP

How to find your server IP:

hostname -I

Expected output:

192.168.1.100 10.0.2.15

Use the first IP address for local network access.

What You Should See

You should see the default Fedora Apache test page with text like:

Testing 123...

Why test via browser instead of curl: Browser rendering confirms the full HTTP response cycle including correct content-type headers. curl is useful for debugging but misses rendering-layer issues.

If the Page Does Not Show

Check these three common causes:

  1. Service not running: sudo systemctl status httpd
  2. Port 80 not open: sudo firewall-cmd --list-all
  3. SELinux blocking: sudo ausearch -m avc -ts recent

Step 6: Configure Basic Apache Settings

Apache Configuration File Structure on Fedora 44

Fedora organizes Apache configuration in these locations:

  • Main config: /etc/httpd/conf/httpd.conf — master file that includes all sub-configurations
  • Drop-in configs: /etc/httpd/conf.d/*.conf — Fedora-specific pattern for modular configuration
  • Logs: /var/log/httpd/access_log and /var/log/httpd/error_log

Why use conf.d/ instead of editing the main file:

  • Modular configs survive package updates without merge conflicts
  • You can disable a virtual host by removing one file
  • Changes are easier to track and document

Edit the Main Configuration File

sudo nano /etc/httpd/conf/httpd.conf

What nano is: A simple text editor for the terminal. If you prefer vim, use sudo vim /etc/httpd/conf/httpd.conf.

Set These Key Directives

Find and modify these lines in httpd.conf:

ServerAdmin admin@yourdomain.com

Why set ServerAdmin: Error pages display this email address. Apache also uses it in some generated headers for contact purposes.

ServerName yourdomain.com:80

Why set ServerName: Without it, Apache logs a startup warning and may behave unexpectedly with name-based virtual hosting.

ServerTokens Prod

Why set ServerTokens Prod: This prevents Apache from advertising its version number in HTTP response headers. Attackers use version information to target known vulnerabilities.

<Directory /var/www/html>
    Options -Indexes
</Directory>

Why set Options -Indexes: This disables directory listing. Without it, anyone who visits http://yourdomain.com/ sees all files in the directory if there is no index.html.

Save and Exit

Press Ctrl + O, then Enter to save, then Ctrl + X to exit nano.

Test Configuration Syntax

sudo apachectl configtest

What this command does:

  • Validates Apache configuration syntax before reloading
  • Returns Syntax OK if the config is valid
  • Returns an error message if there is a syntax problem

Why test before reloading: A syntax error on reload can crash Apache or leave the old config running. Testing prevents this.

Expected output:

Syntax OK

If you see an error, check the line number in the message and fix the typo.

Reload Apache

sudo systemctl reload httpd

Why reload instead of restart:

  • reload applies new config without dropping existing connections
  • restart kills all active requests and starts fresh
  • Use reload for config changes, restart only when necessary

Step 7: Set Up a Virtual Host

Why Virtual Hosts Matter

Virtual hosts allow one Apache instance to serve multiple websites from one server. Even for a single site, using a dedicated virtual host config separates your site from Apache’s default catch-all behavior and makes adding future domains trivial.

Create the Document Root Directory

sudo mkdir -p /var/www/mysite.com/public_html

What this command does:

  • mkdir -p creates the directory and any missing parent directories
  • /var/www/mysite.com/public_html is the document root for your site

Set Directory Ownership

sudo chown -R $USER:$USER /var/www/mysite.com/

What this command does:

  • chown changes file ownership
  • $USER:$USER sets owner and group to your current user
  • -R recurses into subdirectories

Why set ownership: Apache (running as apache user) needs read access, but you need write access to deploy files. Setting ownership to your user while Apache reads via group permissions is the correct posture.

Create the Virtual Host Configuration File

sudo nano /etc/httpd/conf.d/mysite.com.conf

Add the Virtual Host Configuration

Paste this configuration into the file:

<VirtualHost *:80>
    ServerName mysite.com
    ServerAlias www.mysite.com
    DocumentRoot /var/www/mysite.com/public_html
    
    ErrorLog /var/log/httpd/mysite.com-error_log
    CustomLog /var/log/httpd/mysite.com-access_log combined
    
    <Directory /var/www/mysite.com/public_html>
        Options -Indexes
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

What each directive does:

  • ServerName is the primary domain name
  • ServerAlias is an alternative name (like www)
  • DocumentRoot is where your website files live
  • ErrorLog and CustomLog are separate log files per site
  • Options -Indexes disables directory listing
  • AllowOverride All permits .htaccess files
  • Require all granted allows access to all users

Why separate log files per virtual host: Mixing all traffic into one access log makes debugging and traffic analysis nearly impossible on a multi-site server.

Create a Test index.html File

echo "<h1>Welcome to mysite.com</h1>" > /var/www/mysite.com/public_html/index.html

What this does: Creates a simple HTML file to verify the virtual host works.

Test Configuration Again

sudo apachectl configtest

Expected: Syntax OK

Reload Apache

sudo systemctl reload httpd

Test the Virtual Host

Open your browser and navigate to:

http://mysite.com

If you are testing locally, add this to /etc/hosts:

echo "127.0.0.1 mysite.com www.mysite.com" >> /etc/hosts

What this does: Maps mysite.com to your local IP for testing without a real DNS record.

You should see:

Welcome to mysite.com

Step 8: Manage Apache Daily with systemctl

Use these commands for day-to-day Apache management:

Task Command When to Use
Start sudo systemctl start httpd Service stopped, needs to run now
Stop sudo systemctl stop httpd Maintenance window
Restart sudo systemctl restart httpd Config changes affecting active connections
Reload sudo systemctl reload httpd Safe config reload, no dropped connections
Status sudo systemctl status httpd Confirm state and see recent log lines
Disable sudo systemctl disable httpd Prevent auto-start on boot

Why know the difference between restart and reload: Using restart during active web traffic drops all in-flight requests. reload performs a graceful worker handoff where old requests finish before new workers start.


Troubleshooting Common Errors

Error 1: “Failed to start httpd.service: Unit httpd.service not loaded”

Cause: The httpd package did not install correctly.

Solution:

sudo dnf install httpd -y
sudo systemctl status httpd

Verify the package installed and the service exists.

Error 2: “Address already in use” on Port 80

Cause: Another service (like Nginx) is already using port 80.

Solution:

sudo ss -tlnp | grep :80

This shows which process owns port 80. Stop that service or configure Apache to use port 8080:

Listen 8080

Then update your firewall rule:

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

Error 3: Browser Shows “Connection Refused”

Cause: Firewall blocks port 80 or Apache is not running.

Solution:

sudo systemctl status httpd
sudo firewall-cmd --list-all

Confirm Apache is active and http appears in the services list.

Error 4: SELinux Denies Access to Custom Directory

Cause: SELinux does not allow httpd to read files outside /var/www/html.

Solution:

sudo semanage fcontext -a -t httpd_sys_content_t "/your/path(/.*)?"
sudo restorecon -Rv /your/path/

Then verify with ls -Z /your/path/.

Error 5: “Syntax Error” on apachectl configtest

Cause: Typo in configuration file.

Solution:

sudo apachectl configtest

Read the error message, which includes the line number. Fix the typo and test again.

Next Steps: Secure Apache with HTTPS (TLS)

This guide covers HTTP on port 80. For production, HTTPS is mandatory. Browsers mark HTTP sites as “Not Secure,” search engines demote them, and any data sent over HTTP (including form submissions) travels in plain text.

Install the SSL module:

sudo dnf install mod_ssl -y

For free TLS certificates, use Certbot with the Apache plugin:

sudo dnf install certbot python3-certbot-apache -y
sudo certbot --apache

Certbot automatically configures HTTPS, installs a certificate from Let’s Encrypt, and sets up automatic renewal.

[su_box title=”VPS Manage Service Offer” style=”bubbles” box_color=”#000000″ radius=”10″]If you don’t have time to do all of this stuff, or if this is not your area of expertise, we offer a service to do “VPS Manage Service Offer”, starting from $10 (Paypal payment). Please contact us to get the best deal![/su_box]

r00t is a Linux Systems Administrator and open-source advocate with over ten years of hands-on experience in server infrastructure, system hardening, and performance tuning. Having worked across distributions such as Debian, Arch, RHEL, and Ubuntu, he brings real-world depth to every article published on this blog. r00t writes to bridge the gap between complex sysadmin concepts and practical, everyday application — whether you are configuring your first server or optimizing a production environment. Based in New York, US, he is a firm believer that knowledge, like open-source software, is best when shared freely.

Related Posts