
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.
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
sudoprivileges (not root) - Terminal Access: Local terminal or SSH connection to your server
- Network: Internet connectivity to download packages from Fedora repositories
- Package Manager:
dnfavailable (Fedora 44 usesdnfas the default package manager) - Firewall:
firewalldactive and running (default on Fedora 44) - SELinux: Enabled in
Enforcingmode (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:
sudoruns the command with administrative privilegesdnfis Fedora’s package manager (replaces the deprecatedyumcommand)updatefetches the latest package metadata and upgrades installed packages-yautomatically 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:
httpdis 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 apache2will 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:
rpmis the Red Hat Package Manager-qqueries 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
-vflag 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:
systemctlis the systemd control utilitystartlaunches the service immediatelyhttpdis the service name (notapacheorapache2)
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: loadedmeans systemd found the service fileActive: active (running)confirms the service is runningenabledmeans it will start on bootMain PIDshows 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=httpadds the predefined HTTP service rule- This opens port 80/tcp for inbound traffic
--permanentwrites 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
--permanentrules 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:
httpandhttpsappear in theservices:line- Your interface (e.g.,
eth0) is listed underinterfaces:
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-utilsprovides thesemanagecommand- This tool manages SELinux policy rules
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/mysite(/.*)?"
What this command does:
semanage fcontextmanages file context rules-aadds a new rule-t httpd_sys_content_tsets 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:
restoreconapplies the SELinux policy to files on disk-Rrecurses into subdirectories-vprints 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:
- Service not running:
sudo systemctl status httpd - Port 80 not open:
sudo firewall-cmd --list-all - 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_logand/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 OKif 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:
reloadapplies new config without dropping existing connectionsrestartkills all active requests and starts fresh- Use
reloadfor config changes,restartonly 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 -pcreates the directory and any missing parent directories/var/www/mysite.com/public_htmlis the document root for your site
Set Directory Ownership
sudo chown -R $USER:$USER /var/www/mysite.com/
What this command does:
chownchanges file ownership$USER:$USERsets owner and group to your current user-Rrecurses 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:
ServerNameis the primary domain nameServerAliasis an alternative name (like www)DocumentRootis where your website files liveErrorLogandCustomLogare separate log files per siteOptions -Indexesdisables directory listingAllowOverride Allpermits.htaccessfilesRequire all grantedallows 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]