How to Install Apache HTTPD on Fedora Linux

Install Apache HTTPD on Fedora to turn your workstation or VPS into a dependable web server for staging apps, hosting internal tools, or powering production workloads. Apache’s proven module ecosystem and Fedora’s fast-moving stack deliver the flexibility to serve static sites, PHP applications, and reverse proxy backends.

This walkthrough covers updating Fedora with DNF, installing Apache, opening firewall ports, enabling services at boot, configuring virtual hosts, and automating TLS certificates. You will leave with a tuned Apache deployment you can maintain over the long haul.

Update Fedora Before Installing Apache

Updating your Fedora system ensures that it runs the latest software, which is essential for compatibility and security. Before installing new software, it is always a good practice to ensure your system is current.

Press Ctrl+Alt+T to open the terminal, then run the command below to update your packages:

sudo dnf upgrade --refresh

This command uses sudo for administrative rights and dnf upgrade to update all packages. The --refresh option ensures you are getting the latest information from your repositories. Let this process complete before moving to the next step to maintain system integrity and smooth functioning. Once your system is updated, you can proceed with the Apache installation.

Install Apache HTTPD with DNF

With your system up to date, installing Apache (also known as httpd) is straightforward using Fedora’s DNF package manager. You can install Apache with a single command.

In your terminal, run the following command:

sudo dnf install httpd

This command fetches and installs Apache on your Fedora system. DNF handles all necessary dependencies and initial configurations, simplifying the installation. The process is usually quick, leaving Apache ready for use upon completion.

After the installation completes, verify the service and ensure it is running as expected. This helps confirm that your Fedora system is ready to serve web content. Let’s enable and start the Apache service.

Enable the Apache Service at Boot

Once Apache is installed, the next crucial step is to start and enable the httpd service to ensure it runs on system boot. If it wasn’t automatically activated during installation, use these commands:

sudo systemctl start httpd
sudo systemctl enable httpd

Here, sudo systemctl start httpd begins the Apache service, and sudo systemctl enable httpd sets it to launch at boot. This two-step approach ensures Apache is active and persistently available.

Alternatively, you can combine these steps:

sudo systemctl enable httpd --now

The --now flag with sudo systemctl enable httpd starts Apache immediately while also configuring it to launch at boot, streamlining the process. Apache will always be available after a reboot.

Verify the Apache Service Status

It’s important to verify Apache’s status to ensure everything is running smoothly:

systemctl status httpd

This command provides Apache’s operational status. The output includes the service’s current state (e.g., active (running)) and any recent log messages, which are essential for troubleshooting. Regularly checking the status can help maintain a stable and functional Apache setup on your Fedora system. If you see any issues, address them before moving forward.

Open HTTP Ports in Firewalld

Once Apache is running, Fedora uses Firewalld as its default firewall management tool. If you need more detailed information about Firewalld configuration, see our comprehensive guide on how to install and configure Firewalld on Fedora. For added security, you might also want to configure Fail2ban with Firewalld to protect against brute-force attacks.

Allow Web Traffic Through Firewalld

After installing Apache (HTTPD) on Fedora, it is essential to configure Firewalld to allow traffic on ports 80 (HTTP) and 443 (HTTPS). These steps are vital for the security and accessibility of your web server. Without proper firewall configuration, your server may not be reachable from the internet.

Firewalld offers two equivalent approaches: using service names or specifying port numbers directly. Service names are recommended because they’re more readable and maintainable, but understanding both methods helps you work with different firewall configurations.

Method 1: Using Service Names (Recommended)

The cleanest approach uses Firewalld’s predefined service names. Each service definition maps to specific ports: http uses port 80, and https uses port 443:

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

This method is recommended by Fedora documentation because service definitions are centrally managed and automatically handle port mappings. The --permanent flag ensures the rules persist across reboots.

Method 2: Using Port Numbers Directly

Alternatively, you can specify ports directly. This approach gives you explicit control and is useful when running services on non-standard ports:

sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --reload

Here, 80/tcp explicitly opens TCP port 80 (HTTP), and 443/tcp opens TCP port 443 (HTTPS). Both methods achieve the same result, with Method 1 simply abstracting the port numbers into service names.

After applying either method, verify the firewall rules:

sudo firewall-cmd --list-all

You should see either services: http https (Method 1) or ports: 80/tcp 443/tcp (Method 2) in the output. Your server is now ready to accept web traffic on both HTTP and HTTPS.

Security Considerations for Firewall Rules

Understanding the security implications of these changes is crucial. Opening only necessary ports like 80 and 443 minimizes potential vulnerabilities, safeguarding your server from unauthorized access and threats. Always review your firewall settings carefully after making changes.

Check Apache in a Web Browser

To confirm successful configuration, access the Apache (HTTPD) default landing page:

1. Open your web browser.
2. Navigate to http://localhost or http://<your_server_ip>.

If configured correctly, the Apache default page should appear, confirming the server’s operational status. Otherwise, revisit the previous steps to troubleshoot any issues.

Troubleshooting Apache Post-Installation on Fedora

If you encounter issues after installation, such as the service not starting or web pages not loading, check your Firewalld settings, SELinux status, and Apache’s configuration files (typically in /etc/httpd/conf/ and /etc/httpd/conf.d/).

SELinux Troubleshooting Tip for Apache on Fedora

Temporarily setting SELinux to permissive mode with sudo setenforce 0 can help diagnose if SELinux is blocking Apache. However, this is for troubleshooting only. Always return SELinux to enforcing mode (sudo setenforce 1) after resolving issues to maintain system security. Leaving SELinux permissive can leave your system vulnerable. Use this tip sparingly when you run into access issues.

Create a Virtual Host After Installing Apache HTTPD on Fedora

Step 1: Create and Configure Website Directories

Start by creating a directory for your virtual host on Fedora Linux. This directory will act as the document root for your website’s files. For a domain like example.com, use the following command:

sudo mkdir /var/www/example.com

Replace example.com with your actual domain name. This directory (/var/www/example.com) will hold all website files, including HTML, images, and scripts. For organizational and security purposes, creating separate directories for different virtual hosts is advisable.

Set the directory’s ownership and permissions so that Apache can access it:

sudo chown -R apache:apache /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 755 "{}" \;
sudo find /var/www/example.com -type f -exec chmod 644 "{}" \;

The first command changes the directory ownership to the apache user and group. The find -exec commands set the necessary permissions using chmod: directories get 755 (read, write, execute for owner; read and execute for group and others) and files get 644 (read and write for owner; read for others).

Create an index.html file in this directory (e.g., /var/www/example.com/index.html). This file is typically the first page visitors see. Use a text editor like Nano to create this file:

sudo nano /var/www/example.com/index.html

Inside the editor, you can add the following sample HTML structure:

<html>
  <head>
    <title>Welcome to example.com</title>
  </head>
  <body>
    <h1>Welcome to Example Domain</h1>
    <p>This is a sample page for the domain example.com.</p>
  </body>
</html>

Customize this HTML to fit your site’s needs. Save and exit the editor (in Nano, this is typically Ctrl + X, then Y to confirm, then Enter). You are now ready to configure your virtual host.

Step 2: Configure Apache for Virtual Hosts

A. Set Up Virtual Host Directories in Apache Configuration

Create the sites-available and sites-enabled directories within Apache’s configuration path. These directories help organize your virtual host configuration files:

sudo mkdir -p /etc/httpd/sites-available /etc/httpd/sites-enabled

Point Apache at the sites-enabled directory with a small drop-in file. This keeps your configuration separate from Fedora's packaged defaults, so updates will not overwrite your changes:

sudo tee /etc/httpd/conf.d/z-sites-enabled.conf >/dev/null <<'EOF'
IncludeOptional sites-enabled/*.conf
EOF

The z- prefix ensures the include loads after other configuration files, and the IncludeOptional directive automatically picks up any virtual hosts you symlink into sites-enabled. You can now proceed to create your specific virtual host configuration file.

B. Create the Virtual Host Configuration File

Now, create a new configuration file for your domain (e.g., example.com.conf) inside the /etc/httpd/sites-available/ directory:

sudo nano /etc/httpd/sites-available/example.com.conf

In the file, add the following basic virtual host configuration. Remember to adjust ServerName, ServerAlias, and DocumentRoot as needed for your domain and directory structure:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com/
    ErrorLog /var/log/httpd/example.com-error.log
    CustomLog /var/log/httpd/example.com-access.log combined
</VirtualHost>

C. Grant Apache Access to the Document Root

To allow Apache to serve files from your new document root (/var/www/example.com/) and ensure public access, add a <Directory> block inside your site-specific configuration. Keeping the stanza in /etc/httpd/sites-available/example.com.conf (or another drop-in you control) means Fedora package updates will never overwrite it.

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com/
    ErrorLog /var/log/httpd/example.com-error.log
    CustomLog /var/log/httpd/example.com-access.log combined

    <Directory /var/www/example.com/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>

Save and exit the configuration file. This setup keeps the access rules alongside the virtual host, which is easier to maintain and survives package upgrades cleanly.

Step 3: Enable the Virtual Host for Apache on Fedora

After creating the virtual host configuration file (e.g., example.com.conf in /etc/httpd/sites-available/), you need to enable it. To do so, create a symbolic link (symlink) from your configuration file in sites-available to the sites-enabled directory:

sudo ln -s /etc/httpd/sites-available/example.com.conf /etc/httpd/sites-enabled/

Before bouncing the service, validate the configuration to catch typos or missing directives:

sudo apachectl configtest

If the output shows Syntax OK, proceed with the service restart or reload to activate the virtual host.

Finally, restart Apache to apply all the configuration changes. This step is necessary for your new virtual host to become active:

sudo systemctl restart httpd

After restarting Apache, visit http://example.com (or your actual domain) in your web browser. If you haven’t configured DNS for your domain yet, and you’re testing locally, you might need to edit your local /etc/hosts file or use the server’s IP address if configured appropriately for direct IP access to the virtual host (though domain-based virtual hosts are standard). You should see the index.html landing page you created earlier. If not, double-check your configuration files for typos or errors, and review Apache’s error logs (/var/log/httpd/error_log or your custom virtual host error log).

Manage Apache HTTPD Service on Fedora

Disable the Apache Test Page on Fedora

By default, Fedora displays a test page when you access your server without any content. This is useful for verifying Apache works, but you’ll want to disable it once you have actual content or virtual hosts configured.

To disable the test page, comment out all lines in /etc/httpd/conf.d/welcome.conf:

sudo nano /etc/httpd/conf.d/welcome.conf

Add a # at the beginning of each line to comment them out, or simply rename the file:

sudo mv /etc/httpd/conf.d/welcome.conf /etc/httpd/conf.d/welcome.conf.disabled

After disabling the test page, restart Apache to apply the changes:

sudo systemctl restart httpd

Now when you access your server’s IP address without a configured virtual host, you’ll see a standard 403 Forbidden error instead of the Fedora test page. This is expected behavior once you have virtual hosts configured for specific domains.

Understand Apache Server Logs

Apache server logs are crucial for monitoring server activity and troubleshooting issues. By default on Fedora, Apache’s main logs are typically located in /var/log/httpd/. The standard filenames are access_log for access logs (records of all requests processed by the server) and error_log for error logs (records of errors Apache encountered). However, as shown in the virtual host example, you can (and should) customize these log filenames on a per-virtual-host basis (e.g., example.com-access.log, example.com-error.log). Reviewing these logs regularly helps you quickly identify and resolve potential problems.

Fedora runs Apache under systemd, so you can also tail the journal when you need a live view across restarts:

sudo journalctl -u httpd --follow

Adjust Fedora Packaged Web Apps for Remote Access

When you install web applications from Fedora’s repositories, they often default to Require local inside /etc/httpd/conf.d/appname.conf. That keeps dashboards locked to the host. If you want remote users to reach the app, edit the relevant <Directory> block and swap in Require ip 192.0.2.0/24 for a trusted subnet or Require all granted for global access. Save the file, run sudo apachectl configtest, and reload Apache after confirming the syntax. Keep your rules as narrow as your situation allows.

Fedora Configuration File Best Practices

Fedora’s Apache configuration follows a specific hierarchy that you should understand before making changes. The main configuration file is /etc/httpd/conf/httpd.conf, and additional configurations live in /etc/httpd/conf.d/*.conf. Files in conf.d/ are read alphabetically, so z-foo.conf overrides settings from foo.conf.

Important: Do not directly edit configuration files shipped by Fedora packages (like httpd.conf or files in conf.d/). When packages update, your changes will be saved as .rpmsave files, and new defaults will be written to .rpmnew files, forcing you to manually merge changes.

Instead, create new override files with alphabetically-later names. For example, to override settings in /etc/httpd/conf.d/ssl.conf, create /etc/httpd/conf.d/z-ssl-local.conf with your custom settings. The z- prefix ensures your file is read last and takes precedence. This approach keeps your customizations separate from package-managed files and survives updates cleanly.

After making any configuration changes, always test the syntax before reloading:

sudo apachectl configtest

If the test shows “Syntax OK,” reload or restart Apache to apply your changes:

sudo systemctl reload httpd

Filter Health Checks Out of Access Logs

If a load balancer or monitoring job hammers a specific URL, tag that traffic with SetEnvIf and tell Apache to ignore it. Add the following to a site-specific configuration file:

SetEnvIf Request_URI "^/status$" skip_log
CustomLog /var/log/httpd/example.com-access.log combined env=!skip_log

Requests that match the /status path get the skip_log flag, and the env=!skip_log condition keeps them out of the access log. Adjust the regular expression to match your own health-check endpoint.

Example: Custom Log Filenames in Virtual Host

To change the log filenames for a specific virtual host, you edit its configuration file (e.g., /etc/httpd/sites-available/example.com.conf). For instance, here’s how you would define custom log names within the <VirtualHost> block:

<VirtualHost *:80>
    ServerName www.example.com
    DocumentRoot /var/www/example.com
    
    # Custom log file names for this virtual host
    CustomLog /var/log/httpd/www.example.com-access.log combined
    ErrorLog /var/log/httpd/www.example.com-error.log
</VirtualHost>

This configuration directs access logs to www.example.com-access.log and error logs to www.example.com-error.log within the /var/log/httpd/ directory. Remember to provide the full, correct file path. After making such changes, always restart Apache (sudo systemctl restart httpd) to apply them.

Essential Apache Service Management Commands

Managing the Apache service (httpd) involves a set of systemctl commands that allow you to control its operation. With these commands, you can start, stop, restart, or reload Apache as needed.

Stopping Apache:

To stop the Apache server, use:

sudo systemctl stop httpd

This command halts the Apache service. You should use this when you need to perform maintenance or updates that require the server to be offline.

Starting Apache:

To start the Apache server if it is stopped, use:

sudo systemctl start httpd

This command activates the Apache service, making it ready to serve web content.

Restarting Apache:

To stop and then start the Apache server (a full restart), use:

sudo systemctl restart httpd

Restarting is necessary for most configuration changes to take effect or to recover from certain errors. Generally, you should restart Apache after making significant modifications.

Reloading Apache:

To apply configuration changes gracefully without dropping active connections, use:

sudo systemctl reload httpd

Reloading applies many configuration changes without disrupting the running service. This is often preferred over a restart for minor updates if supported by the changes made.

Disabling Apache on Boot:

To prevent Apache from starting automatically when the system boots, use:

sudo systemctl disable httpd

This command removes Apache from the list of services that start on system boot. Use this if you want to manually control when Apache runs.

Enabling Apache on Boot:

To set Apache to start automatically when the system boots (if previously disabled), use:

sudo systemctl enable httpd

This ensures that Apache starts whenever the system boots up, providing consistent web service availability. As a result, your website will typically always be accessible after a reboot.

Secure Apache with a Let’s Encrypt Certificate

Install mod_ssl for HTTPS Support

Before requesting certificates, Apache relies on the mod_ssl module for TLS. Fedora keeps it in the base repositories, so verify it is available before requesting certificates:

sudo dnf install mod_ssl

This installs /etc/httpd/conf.d/ssl.conf with Fedora’s hardened defaults and enables the module automatically. If you previously stripped the package, reinstalling it is faster than rebuilding the configuration by hand.

Install Certbot for SSL/TLS Certificate Automation

First, begin by installing Certbot, a tool for automating the acquisition and renewal of SSL/TLS certificates, thereby ensuring HTTPS encryption for your website. To install Certbot, execute the following command:

sudo dnf install certbot python3-certbot-apache

Generate SSL/TLS Certificate for Your Domain

After installation, generate an SSL/TLS certificate for your domain with this command:

sudo certbot --apache -d example.com -d www.example.com

Replace the example domains with the hostnames you serve. Including both the apex domain and the www alias covers the most common visitor paths in a single certificate.

Optional Hardening Flags for Certbot

For a fully automated HTTPS setup with strict transport security, use the extended command below:

sudo certbot --apache --agree-tos --redirect --hsts --staple-ocsp --email you@example.com -d example.com -d www.example.com

• –apache: Indicates the certificate is for an Apache server.
• –agree-tos: Agrees to Let’s Encrypt’s terms of service.
• –redirect: Redirects HTTP traffic to HTTPS.
• –hsts: Enables HTTP Strict Transport Security, ensuring only secure HTTPS connections.
• –staple-ocsp: Activates OCSP stapling for verifying the SSL certificate.
• –email: Your email address associated with the certificate.
• -d: Lists every domain and subdomain covered by the certificate.

Add --dry-run and --staging only when rehearsing the process against Let’s Encrypt’s test environment. Remove those options when you are ready to issue a real certificate.

Configure Apache to Use the SSL Certificate

Following certificate generation, Certbot automatically places the files in /etc/letsencrypt/live/example.com/ with correct SELinux contexts. However, if you’re manually installing certificates or troubleshooting, you may need to restore SELinux contexts to ensure Apache can access the files:

sudo restorecon -Rv /etc/letsencrypt/

This command recursively restores the default SELinux security contexts for all files in the Let’s Encrypt directory. On Fedora, SELinux is enabled by default and enforces strict access controls. If contexts are incorrect, Apache won’t be able to read certificate files even with correct file permissions.

Preferred: Add HTTPS Block to Your Virtual Host

With SELinux contexts set, wire the certificate into the same virtual host you enabled earlier. Edit /etc/httpd/sites-available/example.com.conf (or the file you symlinked) and append an HTTPS block that references your Let’s Encrypt files:

<VirtualHost *:443>
  ServerAdmin webmaster@localhost
  ServerName example.com
  ServerAlias www.example.com
  DocumentRoot /var/www/example.com/
  ErrorLog /var/log/httpd/example.com-ssl-error.log
  CustomLog /var/log/httpd/example.com-ssl-access.log combined

  SSLEngine on
  SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

  <Directory /var/www/example.com/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
  </Directory>
</VirtualHost>

Save the file, then rerun the syntax test before reloading Apache so the HTTPS virtual host comes online cleanly:

sudo apachectl configtest

sudo systemctl reload httpd

Fallback: Update ssl.conf Manually

If you prefer a single global TLS configuration, place the certificate directives in /etc/httpd/conf.d/z-ssl-local.conf or, as a last resort, edit /etc/httpd/conf.d/ssl.conf. Fedora package updates may create .rpmnew or .rpmsave files, so be prepared to merge changes before reloading Apache.

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

After adjusting the global configuration, run sudo apachectl configtest followed by sudo systemctl reload httpd. Keep dated backups of any manual edits so you can reapply them if an update overwrites the stock file.

Verifying and Renewing the SSL Certificate

Post-installation, visitors reach your site over https://www.example.com once you enable Certbot’s redirect option (either answer Yes when prompted or include --redirect). To keep the certificate valid, you still need to renew it regularly.

Setting Up Automatic Certificate Renewal

Before you rely on automation, run a dry run to confirm Certbot can complete the process end to end:

sudo certbot renew --dry-run

This command uses Let’s Encrypt’s staging infrastructure to validate your configuration without modifying production certificates. Resolve any reported issues before moving on to automation.

SSL Certificate Renewal and Management

Keeping your TLS certificates healthy starts with a clear picture of their current status, then automating renewals so HTTPS stays uninterrupted. The steps below help you confirm expiration dates and put renewal tasks on autopilot.

Verifying SSL Certificate Status

Before automating the renewal process, it’s crucial to understand the current status of your SSL certificates. To check the status, including the expiration dates of all certificates managed by Certbot, use this command:

sudo certbot certificates

This command provides a list of all SSL certificates handled by Certbot, along with their respective expiration dates. This information is essential to confirm that your certificates are active and to understand when they will require renewal. Once you know the status, you can proceed to automate renewals.

Automating SSL Certificate Renewal

To ensure uninterrupted HTTPS service, SSL certificates must be renewed periodically. Automating this process is vital for maintaining a secure website. Fortunately, Certbot makes this easy.

Enable the Certbot Systemd Timer

Fedora’s Certbot packages ship with a systemd timer that handles renewals for you. Enable it so systemd runs the paired service automatically:

sudo systemctl enable --now certbot-renew.timer

The timer schedules certbot-renew.service twice per day and only renews certificates that are within 30 days of expiring. Verify the schedule and last run whenever you need reassurance:

systemctl list-timers certbot-renew.timer

For troubleshooting, check the timer status or review recent logs:

sudo systemctl status certbot-renew.timer
sudo journalctl -u certbot-renew.service --since "24 hours ago"

With the timer active, systemd keeps your certificate automation in sync with the rest of Fedora’s services without any extra scripts to maintain.

Optional: Use Cron on Minimal Systems

If you disable systemd timers or maintain older hosts, a cron job is still a workable fallback. Install Cronie and ensure the scheduler is running:

sudo dnf install cronie
sudo systemctl enable --now crond.service

Edit root’s crontab and add a renewal entry. Pick a schedule that suits your maintenance window and keep the output quiet unless something fails:

sudo crontab -e

0 6,18 * * * certbot renew --quiet

Do not enable both the systemd timer and a cron job at the same time; pick one scheduler to avoid duplicate renewals. Confirm your choice is active with sudo systemctl status crond or by inspecting /var/log/cron on legacy setups.

Understanding Certbot’s Renewal Process

Certbot intelligently manages the renewal process. It only attempts to renew certificates that are within 30 days of expiration. If a certificate does not need renewal, Certbot will not perform any action. This efficiency ensures your server is not burdened with unnecessary processes and that your SSL certificates are always up to date. You can rest assured that your site remains secure.

Setting up this automated renewal process is a best practice for maintaining continuous HTTPS encryption, ensuring your website remains secure and trusted by users and search engines. Automation saves time and reduces the risk of certificate expiration.

Generate a Self-Signed Certificate for Testing

Need HTTPS for a lab machine or an offline demo? Create a self-signed certificate directly on Fedora. The example below produces a one-year RSA certificate and drops it into the system-wide TLS directories:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:4096 \
  -keyout /etc/pki/tls/private/example.com.key \
  -out /etc/pki/tls/certs/example.com.crt

Point the SSLCertificateFile and SSLCertificateKeyFile directives in your virtual host to those paths and reload Apache. Browsers will warn users because the certificate is self-signed, so reserve this approach for trusted environments.

Deploy Certificates from Other Authorities

If you buy a certificate from a commercial provider (or receive one from an enterprise PKI), copy the certificate, matching private key, and any intermediate bundle into /etc/pki/tls/. Lock the key down with sudo chmod 600 /etc/pki/tls/private/yourdomain.key, restore SELinux labels with sudo restorecon -Rv /etc/pki/tls, and update your <VirtualHost> block to reference the new files. Finish with sudo systemctl reload httpd so Apache serves the new chain.

Maintenance & Cleanup for your Apache HTTPD Fedora Installation

Once the server is live, routine maintenance keeps performance sharp and prevents configuration drift. Use the following checklists to secure directories, stay on top of updates, and remove unused components before they create trouble.

Secure Directories and Files on Apache on Fedora

Ensuring the security of your server involves setting appropriate permissions for files and directories. Overly permissive settings can expose your server to risks. Always use the least permissive settings necessary for your application to function.

Setting Secure Permissions

For directories and files under /var/www/example.com/, use these commands:

sudo find /var/www/example.com/ -type d -exec chmod 755 "{}" \;
sudo find /var/www/example.com/ -type f -exec chmod 644 "{}" \;

These find -exec commands with chmod set directories to 755 (read, write, execute for the owner, and read and execute for others) and files to 644 (read and write for the owner, read for others), which are standard secure permissions. Following these steps significantly reduces the risk of unauthorized access.

Special Permissions for Specific Applications

Note that some applications, like phpBB, may require 777 permissions on certain folders. Always adjust permissions based on application requirements. However, it’s crucial to avoid using 777 unless absolutely necessary.

Comprehensive Security Approach

Remember, setting permissions is just one aspect of security. Implementing SSL certificates and proper firewall configurations are also crucial for robust server protection. These measures work together to keep your server safe.

Update Apache HTTPD After Installation on Fedora

Keeping Apache up to date is crucial for security and performance. Make it a habit to check for updates regularly for your Apache HTTPD Fedora setup.

Updating Apache

To update Apache, along with other system packages, use the following command:

sudo dnf update --refresh

This command refreshes the package database and updates all installed packages, including Apache. After updating, it’s wise to test your configuration to ensure everything works as expected.

Uninstall Apache HTTPD from Fedora

In scenarios where Apache needs to be removed from the system, follow these steps to ensure a clean uninstallation. Removing Apache HTTPD from Fedora is straightforward.

Disabling and Stopping Apache

Disable and stop the Apache service as shown below:

sudo systemctl disable httpd --now

This command stops the Apache service and prevents it from starting automatically at boot.

Uninstalling Apache

To remove Apache from your system, execute the following command:

sudo dnf remove httpd

This command uninstalls the Apache package.

Cleaning Up Leftover Files

After uninstallation, review the Apache configuration directory and back up any custom virtual hosts, certificates, or scripts you want to keep. A quick archive preserves your work in case you reinstall later:

sudo tar -czf ~/httpd-config-backup-$(date +%F).tar.gz /etc/httpd

Once you confirm the backup is safe, prune only the directories you created (such as sites-available, sites-enabled, or custom snippets). Keeping the packaged defaults intact avoids breaking future reinstallations.

Quick Reference Table for Apache HTTPD on Fedora

Action	Command
Update system packages	sudo dnf upgrade --refresh
Install Apache	sudo dnf install httpd
Start Apache	sudo systemctl start httpd
Enable Apache on boot	sudo systemctl enable httpd
Check Apache status	systemctl status httpd
Restart Apache	sudo systemctl restart httpd
Reload Apache config	sudo systemctl reload httpd
Stop Apache	sudo systemctl stop httpd
Disable Apache on boot	sudo systemctl disable httpd
Test Apache config	sudo apachectl configtest
Test Apache config (short)	sudo apachectl -t
Show virtual host config	sudo apachectl -S
View error log	sudo tail -f /var/log/httpd/error_log
View access log	sudo tail -f /var/log/httpd/access_log

Real-World Configuration Examples for Apache HTTPD on Fedora

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Custom Error Pages

Replace default Apache error pages with custom HTML files that match your site’s design. Add these directives to your virtual host configuration:

ErrorDocument 404 /custom_404.html
ErrorDocument 500 /custom_500.html

Create the corresponding HTML files in your document root (/var/www/example.com/), then reload Apache to apply the changes.

Password Protect a Directory

<Directory /var/www/example.com/secure>
    AuthType Basic
    AuthName "Restricted Content"
    AuthUserFile /etc/httpd/.htpasswd
    Require valid-user
</Directory>

Create the password file with: sudo htpasswd -c /etc/httpd/.htpasswd username

Advanced Tips for your Apache HTTPD Fedora Installation

To get the most out of Apache HTTPD on Fedora, explore advanced modules, performance tuning, and security best practices. Fedora’s integration with Apache makes it easy to expand your web server’s capabilities as your needs grow. As you gain experience, you can further optimize your setup.

Best Practices & Reminders for Apache HTTPD on Fedora

• Back up configs and web data before making major changes: For instance, sudo cp -a /etc/httpd /etc/httpd.bak and sudo cp -a /var/www /var/www.bak
• Keep Apache and your system updated for security and stability.
• Minimize enabled modules to reduce attack surface.
• Use strong permissions and avoid 777 except where absolutely required (and never on config files).
• Regularly monitor logs for unusual activity or errors.
• Test configuration changes with sudo apachectl configtest before restarting Apache.

Reduce Version Details in Error Pages

Apache advertises its build details in error pages and response headers by default. Trim that footprint by creating /etc/httpd/conf.d/z-hardening.conf with the following lines:

ServerTokens Prod
ServerSignature Off

ServerTokens Prod limits the Server: header to just Apache, while ServerSignature Off removes the banner from directory listings and error pages. Reload Apache after adding the file. Keep an eye on vendor support requirements because some security scanners expect to see these directives in place.

Conclusion

Apache HTTPD delivers a proven web server platform with Fedora’s fast-moving package stack. The installation covers repository updates, firewall configuration, virtual host setup, and automated SSL renewal through Certbot. Your Fedora system now runs a production-ready web server that handles static sites, PHP applications, and reverse proxy backends while staying current with regular updates and monitoring.