The idea is to take you through all the steps needed to get up and running, some basic familiarity with computers and Linux is assumed, but not a lot.

• Server Setup 1: OS installation
  This goes through a few pre-requisites, and then launches into the installation.
• Server Setup 2: Initial tweaks
  These first few steps will make your life easier when administering this server.
• Server Setup 3: Install Webserver
  We’ll install and test the webserver software – Apache.
• Server Setup 4: Going Public
  Configure the server, DNS and your router to allow public access to a placeholder website.
• Server Setup 5: HTTPS
  Enable secure connections to your new website with Lets Encrypt and certbot.
• Server Setup 6: WordPress Pre-requisites
  Get ourselves ready to install WordPress – we need PHP and a database.
• Server Setup 7: Install WordPress
  Get WordPress installed so you have a functional website!
• Server Setup 8: WordPress tweaks
  A few tweaks to optimise WordPress.
• Server Setup 9: Nextcloud Prep
  Preparatory work before the Nextcloud installation.
• Server Setup 10: Nextcloud Installation
  Get the database and files system configured, then install Nextcloud
• Server Setup 11: Config Improvements
  Some little tweaks to improve the security of our server
• Server Setup 12: Collabora
  Install and configure Collabora Online Development Edition
• Server Setup 13: Security Improvements
  Move the WordPress configuration out of the web root
• Server Setup 14: Backups
  This shows how to collect together all the data you need to completely back up your server.
• Server Setup 15: Optional Extras
  Further optional tweaks to make your installation better.

One recommendation that many security experts make is that the WordPress configuration files should be outside the web root. Lets make this change.

WordPress

Create a new folder called /var/www_config. Put a new folder in here, wordpress

cd /var
sudo mkdir www_config
cd www_config
sudo mkdir wordpress

Copy the WordPress configuration file across, and set it’s permissions so no-one apart from www-data (and root, of course) can read it:

sudo cp -a /var/www/wordpress/wp-config.php /var/www_config/wordpress/
sudo chown -R www-data:www-data /var/www_config
sudo chmod -R u=rX,go= /var/www_config

Now we need to tell Apache that the when PHP scripts on the wordpress site run, they can only access the folders we want them to:

• /var/www/wordpress : our wordpress installation
• /var/www_config/wordpress : our wordpress config
• /tmp : WordPress needs this for handling plugin upgrades etc.

Modify the wordpress Apache site configuration file and add this line inside the VirtualHost section:

php_admin_value open_basedir "/var/www/wordpress/:/var/www_config/wordpress/:/tmp/"

Now reload Apache.

Finally, WordPress still needs to be able to find this file, so replace the contents of the original wp_config.php with this:

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once('/var/www_config/wordpress/wp-config.php');

It’ll take effect the moment you save it, so now visit your site from the client, and hopefully nothing has broken!

Nextcloud

For some reason this isn’t as widely recommended by Nextcloud users. I’ll investigate and update this post with my suggestion.

For now, just make sure only www-data can read and write the config file:

sudo chown -R www-data:www-data /var/www/nextcloud/config/
sudo chmod -R u=rX,go= /var/www/nextcloud/config/

The final of the 3 big pieces – this provides document editing capability in Nextcloud.

Install Collabora

There are a couple of ways to install Collabora, and the recommended way is to use a Docker image. That isn’t ideal for us because the Docker version will use more resources which we can’t afford if you’re running this on something old. Instead, Collabora provide respositories, so these commands will:

1. Install a little tool me we need
2. Get the security keys so the repository is safe to use
3. Add the repository to our /etc/apt/sources.list.
4. Install Collabora

sudo apt install gnupg
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0C54D189F4BA284D
sudo echo 'deb https://www.collaboraoffice.com/repos/CollaboraOnline/CODE-debian10 ./' | sudo tee -a /etc/apt/sources.list
sudo apt update && sudo apt install loolwsd code-brand

Configure Collabora

Modify /etc/loolwsd/loolwsd.xml

sudoedit /etc/loolwsd/loolwsd.xml

We’ll disable SSL in collabora itself, because Apache will handle that. Find <ssl desc="SSL settings">. Look at the line below. Change the second-to last word to false. It should now be this:

<enable type="bool" desc="Controls whether SSL encryption between browser and loolwsd is enabled (do not disable for production deployment). If default is false, must first be compiled with SSL support to enable." default="true">false</enable>

In the line below that, the second-to last word should be true.

<termination desc="Connection via proxy where loolwsd acts as working via https, but actually uses http." type="bool" default="true">true</termination>

Now find <wopi desc="Allow/de..... Add a line below it, swapping in your Nextcloud domain name, with the dots "." escaped with backslashes "\.".

<host desc="Regex pattern of hostname to allow or deny." allow="true">nextcloud\.example\.org</host>

Save and close the file, then restart Collabora

sudo systemctl restart loolwsd

Test

There isn’t a whole lot of testing we can do on Collabora as an intermediate step, but this will at least confirm the server is running. This command asks Collabora for a file saying what it’s capable of:

cd ~
wget http://localhost:9980/hosting/capabilities

If it seems to run OK, you should now have a file called capabilites in your home (~) directory. Lets look at what’s inside:

cat ~/capabilities

{"convert-to":{"available":true},"hasMobileSupport":true,"hasTemplateSaveAs":false,"hasTemplateSource":true,"productName":"Collabora Online Development Edition"}

Looking good!

Configure Apache

In this situation, all Apache has to do is act as a proxy between Collabora and the internet – we can’t connect it directly because otherwise the other sites (WordPress and Nextcloud) wouldn’t work.

Enable these 3 modules:

sudo a2enmod proxy proxy_http proxy_wstunnel

Edit the main Collabora SSL Apache configuration file:

sudoedit /etc/apache2/sites-available/collabora-le-ssl.conf

Change it to this:

<VirtualHost *:443>
    ServerName collabora.example.org
    ErrorLog ${APACHE_LOG_DIR}/collabora_error.log
    CustomLog ${APACHE_LOG_DIR}/collabora_access.log combined

    SSLCertificateFile /etc/letsencrypt/live/collabora.example.org/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/collabora.example.org/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
	# Encoded slashes need to be allowed
	AllowEncodedSlashes NoDecode

	# Container uses a unique non-signed certificate
	SSLProxyEngine On
	SSLProxyVerify None
	SSLProxyCheckPeerCN Off
	SSLProxyCheckPeerName Off

	# keep the host
	ProxyPreserveHost On

	# static html, js, images, etc. served from loolwsd
	# loleaflet is the client part of Collabora Online
	ProxyPass           /loleaflet http://127.0.0.1:9980/loleaflet retry=0
	ProxyPassReverse    /loleaflet http://127.0.0.1:9980/loleaflet

	# WOPI discovery URL
	ProxyPass           /hosting/discovery http://127.0.0.1:9980/hosting/discovery retry=0
	ProxyPassReverse    /hosting/discovery http://127.0.0.1:9980/hosting/discovery

	# Capabilities
	ProxyPass           /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities retry=0
	ProxyPassReverse    /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities

</VirtualHost>

Basically, the bits we’ve added are a two-way connector between Apache and Collabora, and it needs slightly different things for all of the different features.

Reload Apache.

Configure Nextcloud

1. Log into Nextcloud with your admin account.
2. Click on the circle with your initial in the top right corner, choose Apps.
3. Click on Office & text from the menu on the left.
4. Find Collabora Online and click Download and enable
   

5. Click on the circle with your initial in the top right corner, choose Settings.
6. Click on Collabora Online near the bottom of the menu on the left.
7. Choose Use your own server
8. Enter your Collabora domain name with the https:// and then hit save.

Now go back to the files section and give it a try!

• You should have the option to create a New Document, New Spreadsheet or New Presentation from the “+” icon.

• Or if you have any files on Open Document (.odt, .ods, .odp) or Open Office XML (.docx, .xlsx, .pptx) formats you can try opening them. They should open for editing in Collabora:

Before enabling public access to Nextcloud, lets take a moment to improve things a little.

Apache Config

First up, let’s force the use of the HTTPS and make sure we haven’t left any security holes by stripping back the HTTP config file to it’s bare bones.

sudoedit /etc/apache2/sites-available/nextcloud.conf

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

The default Apache configuration gives access to a little too much – we can lock that down, and just open up the bits we want later with the site-specific configuration files.

sudoedit /etc/apache2/apache2.conf

Look for this section and put a # at the beginning of every line so they’re ignored.

<Directory /usr/share>
	AllowOverride None
	Require all granted
</Directory>

<Directory /var/www/>
	Options Indexes FollowSymLinks
	AllowOverride None
	Require all granted
</Directory>

Now we have to give access back just where want it:

sudoedit /etc/apache2/sites-available/nextcloud-le-ssl.conf

Before the ErrorLog line, add this:

<Directory /var/www/nextcloud>
    Require all granted
</Directory>

Then do the same for the WordPress config:

sudoedit /etc/apache2/sites-available/wordpress-le-ssl.conf	

Before the ErrorLog line, add this:

<Directory /var/www/wordpress>
    Require all granted
</Directory>

Restart Apache (you should know how to do that by now – look back through the previous posts until you find it.)

Nextcloud Administration Warnings

Log into your nextcloud administrator account, click on the circle with your initial in the top right corner, choose setttings. On the page that pops up, pick Overview from the menu on the right.

The system will think for a moment, then show a list of warnings:

If your list is the same as mine, I’ll show you how to fix the first 2, but you can work through the others on your own if you like.

PHP Memory Limit

“The PHP memory limit is below the recommended value of 512MB.”

It isn’t essential to fix this, and if you’re running nextcloud on an old, lower powered machine I wouldn’t recommend it, because that’s the limit per script, and a script fires up every time someone access your site, so with a few users doing heavy things, you’ll have a problem.

If you do want to do it, edit the PHP configuration file:

sudoedit /etc/php/7.3/apache2/php.ini

Find this line and change the number to what you want:

memory_limit = 512M

Then restart Apache

Enable HSTS

“The “Strict-Transport-Security” HTTP header is not set to at least “15552000” seconds. For enhanced security, it is recommended to enable HSTS as described in the security tips .”

You can follow that link in the tip to find out the details of how we fix this, but these are the steps:

Enable the Apache headers module:

sudo a2enmod headers

Modify the Nextcloud apache configuration:

sudoedit /etc/apache2/sites-available/nextcloud-le-ssl.conf

Add this after the ServerName line:

Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"

And reload Apache

Re-enable public access

Now we’ve dealt with a few potential security issues, you can enable access to Nextcloud from outside you network.

sudoedit /etc/apache2/sites-available/nextcloud-le-ssl.conf

Either delete, or comment out these 3 lines. You can make a line into a comment by putting a # at the beginning of the line. That means it will be ignored.

<Location />
    Require ip xxx.xxx.xxx.0/24
</Location>

Reload apache and you’re done!

Database

Again, same as for WordPress, we need a database and a user. Same command to login as the root database server user:

sudo mysql -u root -p

a similar set of SQL commands to set up the nextcloud database:

CREATE USER 'nc_usr'@'localhost' IDENTIFIED BY 'password';
CREATE DATABASE IF NOT EXISTS nc_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES on nc_db.* to 'nc_usr'@'localhost';
FLUSH privileges;
EXIT;

Disable Public Access – a different way

Like before, we don’t want the Nextclound site to be public until we’ve completed the installation & configuration. On the other hand, we don’t want to do the same as before (cutting our server off from the internet by turning off port forwarding on the router) because we have an active WordPress installation that people might be using.

To do this we’ll tell Apache to only respond to requests (for the Nextcloud site) from your internal network, not from the public internet:

sudoedit /etc/apache2/sites-available/nextcloud.conf

Add this section, just before the ErrorLog line, replacing the xxx.xxx.xxx with the first 3 blocks of your IP address on your network.

<Location />
    Require ip xxx.xxx.xxx.0/24
</Location>

Reload apache:

sudo systemctl reload apache

Download the installer script

Navigate to the nextcloud folder

cd /var/www/nextcloud

Download the installer script, and pass ownership of it and the entire nextcloud folder to www-data (which is apache, remember).

sudo wget https://download.nextcloud.com/server/installer/setup-nextcloud.php
sudo chown -R www-data:www-data /var/www/nextcloud

We should also create a data folder outside the /var/www folder, which improves security:

sudo mkdir /var/nc_data
sudo chown -R www-data:www-data /var/nc_data

Run Installation Script

On the client machine, open a browser and go to nextcloud.example.org/setup-nextcloud.php

You should see the Setup Wizard, most it should be easy to understand, click your way through:

Put a “.” in the box like it says because the Nextcloud installer is already in the correct place

• Enter the details for the database and database user you created above.
• Make an admin account with a strong password.
• Change the data folder to the one we just created: /var/nc_data,
• I’d recommend unticking the Install recommended apps box. You can add them later if you like.

Once this is done you should be able to log in and start using it!

First, we need 1 extra PHP module:

sudo apt install php-gd

Like with WordPress, we’ll create a folder and apache configuration for Nextcloud:

cd /var/www
sudo mkdir nextcloud
sudoedit /etc/apache2/sites-available/nextcloud.conf

And we’ll use essentially the same apache configuration we used for wordpress, with a few tweaks.

<VirtualHost *:80>
    ServerName nextcloud.example.org
    DocumentRoot /var/www/nextcloud
    
    <Directory /var/www/nextcloud/>
        Require all granted
        AllowOverride All
        Options FollowSymLinks MultiViews

        <IfModule mod_dav.c>
            Dav off
        </IfModule>
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/nextcloud_error.log
    CustomLog ${APACHE_LOG_DIR}/nextcloud_access.log combined
</VirtualHost>

We’ll also create a temporary configuration for collabora while we’re here:

sudoedit /etc/apache2/sites-available/collabora.conf

<VirtualHost *:80>
    ServerName collabora.example.org
    ErrorLog ${APACHE_LOG_DIR}/collabora_error.log
    CustomLog ${APACHE_LOG_DIR}/collabora_access.log combined
</VirtualHost>

This is just a barebones template that’s just enough to let us set up HTTPS later.

Enable the sites and reload apache:

sudo a2ensite nextcloud collabora
sudo systemctl reload apache2

DNS

We need to create DNS Entries for Nextcloud and Collabora:

1. Log into the control panel for your domain.
2. Create a CNAME record
   • Domain: e.g. nextcloud.example.org
   • Data: e.g. example.org if you had a fixed IP, or the dynamic DNS server address you created e.g. anotherexample.ddns.net
3. Do the exact same for collabora.example.org

HTTPS

Use certbot again to enable https on both nextcloud.example.org and collabora.example.org

sudo certbot --apache

When it asks you which sites you want to activate HTTPS for, you can select multiple options by putting a comma separated list. You can also choose to allow certbot to automatically reconfigure apache to Redirect (option 2 when it asks you).

In this post we’ll configure another site that will hold your WordPress installation (but not install WordPress yet) and make it available on the internet.

Domain name setup

While it’s technically possible to get at your site without a domain name, it’s pretty awkward.

So, go buy one – they’re cheap, and there and hundreds to choose from. Just google “domain name”. A few bits of advice:

• While there are some very cheap deals, it’s often just for the first year. Pay attention to the renewal price, in case you want to keep the domain a long time.
• Look for WHOIS Privacy or a similar feature. You’re required (by law) to provide your real name and contact details when you buy a domain, but WHOIS Privacy means that the information is protected and not publicly available. It might cost extra.

So now you own a little slice of the internet. For the rest of this example I’ll assume it’s example.org. You can do what you like with this, like creating websites at www.example.org, thingy.example.org or set up an email service with joebloggs@email.example.org. For this tutorial, We’ll install WordPress at www.example.org.

Apache Site Configuration

First up, lets create a webpage in a new folder in /var/www/

cd /var/www
sudo mkdir wordpress
cd wordpress
sudoedit index.html

We’ll put some real HTML in it this time:

<html>
    <head>
        <title>My website</title>
    </head>
    <body>
        <h1>Hello Everyone</h1>
        <p>It's not ready yet, but check back soon for my new blog!</p>
    </body>
</html>

Now we’ll create the apache site that’ll show you this page. This time the address will be www.example.com

sudoedit /etc/apache2/sites-available/wordpress.conf

<VirtualHost *:80>
    ServerName www.example.org
    DocumentRoot /var/www/wordpress

     <Directory /var/www/html/wordpress/>
        Options +FollowSymlinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/wordpress_error.log
    CustomLog ${APACHE_LOG_DIR}/wordpress_access.log combined
</VirtualHost>

We’ll enable this site, disable the default site while we’re at it, and reload apache:

sudo a2ensite wordpress
sudo a2dissite 000-default
sudo systemctl reload apache2

Configure the hosts files on your client:

xxx.xxx.xxx.xxx www.example.org

And load it up www.example.org in the browser on your client to test!

Port Forwarding

So, what we’ve done so far:

• Configure a server that is a website that works inside your home network.

The next step is:

• Send traffic that arrives at your router (from the internet) to your server.

That’s called Port Forwarding. If you’re unfamiliar with the concept of ports in computer networking, I like to think of them like telephone extension numbers when you call a large company – the main phone number gets you to the reception, but if you also have the extension number, you gets straight to the right department.

Port forwarding means that when traffic arrives at your router, it looks at what the port is, then uses that to decide which device on the network to send the traffic to.

Exactly how you get your router to do this is dependant on the make and model of your router – you can look in the documentation for it – the name of this feature is usually port forwarding, but could be Permit Access, Port Sharing, or something related. The website portforward.com is a great resouces for rotuer-specific information on how to do this.

Your router might have built in profiles for hosting a website: they’ll usually be called something like (the names in brackets are the secure versions of the same thing).

• Website (Secure Website)
• HTTP (HTTPS)
• HTTP Server (HTTPS Server)

If not, you need to forward traffic arriving on ports 80 to your server (either by IP or hostname), also on ports 80. Do the same exact thing with port 443 as well.

DNS configuration

The final step is to make it so that when someone types in your domain name (e.g. www.example.org) the traffic gets to your router.

How this depends on your ISP. I’m going to assume they aren’t blocking you from hosting a website. You’ll either have a fixed IP address (great!) or dynamic IP address (not so great, but still workable).

This is the public IP of your router, not your local network IP address that we’ve been working with so far. This is what appears when you Google What’s my IP Address.

Ask your ISP if you’re not sure if your IP address is fixed or dynamic.

Fixed IP

If your internet service includes a fixed IP, this next steps are pretty simple.

1. Find out what the IP address is. e.g. 203.0.113.123
2. Log into the control panel for your domain.
3. Look for an option to create or modify DNS records
4. Create an A record.
   • The Domain section will be the bare domain you just bought – e.g. example.org
   • The Data is your fixed IP address e.g. 203.0.113.123
5. Create a CNAME record
   • Domain: e.g. www.example.org
   • Data: e.g. example.org
6. Save all the changes, and after a little while (could be seconds, could be hours) you’ll be able to get at your website from outside your home network! Try on your phone with wifi switched off (so you’re using your mobile (cellular) data.

Dynamic IP

This means every time your router connects to the internet, it could have a different IP address. This means an A record with a fixed IP like above won’t work.

You’ll need use a Dynamic DNS Service to get around this.

Each of these has two parts:

• An online service
  • There are lots of services, no-ip.com is a large and well respected one with a free service level and a linux client.
• An update client – a program running on a device on your network that tells the online service where it is.
  • This could run on anything – your router might be able to run it – have a look through it’s documenation and see if your chosen Dynamic DNS service is supported.

So the steps are:

1. Pick a Dynamic DNS Service and sign up.
2. Create a domain name within their system e.g. anotherexample.ddns.net. It doesn’t matter what name you choose.
3. Either configure your router with your account details, or follow your chosen service’s instructions to install & configure the client on your server.
4. You should be able to see if it’s working by logging into the Service and checking what the IP is and when it was last updated. It should show your public IP address.
5. Log into the control panel for your domain.
6. Look for an option to create or modify DNS records
7. Create a CNAME record
   • Domain: e.g. www.example.org
   • Data: e.g. anotherexample.ddns.net (that you created above)
8. Save all the changes, and after a little while (could be seconds, could be hours) you’ll be able to get at your website from outside your home network! Try on your phone with wifi switched off (so you’re using your mobile (cellular) data.

Tidying up

Once you’ve verified that that you can get at your website from outside your network, I’d recommend removing the entry in your client’s hosts file. This means that when your client tries to access your website, it’ll use the public IP address (instead of the private IP address inside your network). However, your router should be smart enough to realise that, and direct the request to your server. This may be marginally slower, but it’ll make it easier to catch and fix DNS or router issues when inside your network.

Install Apache

Now we’ll install the software that actually serves webpages to your browser.

Install apache

sudo apt install apache2

check it’s running:

sudo systemctl status apache2

The output should look something like this:

sandy@waldorf:/mnt$ sudo systemctl status apache2
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2020-05-19 13:41:38 BST; 21s ago
     Docs: https://httpd.apache.org/docs/2.4/
 Main PID: 1128 (apache2)
    Tasks: 55 (limit: 4523)
   Memory: 18.0M
   CGroup: /system.slice/apache2.service
           ├─1128 /usr/sbin/apache2 -k start
           ├─1129 /usr/sbin/apache2 -k start
           └─1130 /usr/sbin/apache2 -k start

Press q if it won’t let you do anything else after showing this message.

Let’s test it!

On your client pc, open a web browser and type in http://hostname or http://xxx.xxx.xxx.xxx swapping the hostname or IP address of your server as approprite. You need to type the “http://” otherwise your browser will think you’re doing a search. You should see a page like this:

Additional test configuration

This step is optional, but may help later. We’ll configure a test site that will give us lots of useful information about our websever, great for debugging if (when) something goes doesn’t work.

First, pick a domain name. If you already own one you want to use for this site, then use that otherwise you can make something up. I’ll use example.org for this tutorial. Our test site will be at a subdomain: test.example.org

first, create a directory to hold files we want to test:

sudo mkdir /var/www/test

make an index.html in this folder

sudoedit /var/www/test/index.html

"Hello, world wide web!"

Normally this file would contain html tags, but this’ll do for a quick test

Create test.conf in /etc/apache2/sites-available

sudoedit /etc/apache2/sites-available/test.conf

<VirtualHost *:80>
    ServerName test.example.org
    DocumentRoot /var/www/test

    <Location />
		Require ip     192.168.2.0/24
	</Location>

	<Location "/server-info">
		SetHandler server-info
	</Location>

	<Location "/server-status">
		SetHandler server-status
	</Location>
    
    ErrorLog ${APACHE_LOG_DIR}/test_error.log
    CustomLog ${APACHE_LOG_DIR}/test_access.log combined

</VirtualHost>

You should modify the xxx.xxx.xxx to the first 3 blocks of the server’s IP address on your network.

This sets up a website that can show a lot of useful information, and the Require lines mean it’s only accessible from inside your network. Maybe I’ll break down the contents of this in a later blog post. Comment if you’d like to see that.

Enable mod_info which will allow you to see lots of useful debugging information

sudo a2enmod info

Finally, enable the site and restart apache

sudo a2ensite test
sudo systemctl restart apache2

Last step, configure the hosts file on your client

Windows
Open notepad as an Administrator
Add a line which has

xxx.xxx.xxx.xxx test.example.org

… swapping in your server ip address and the domain name you chose above.

Go to these addresses and see if it works

test.example.org

test.example.org/server-status

test.example.org/server-info

If that’s all working, we’re good to move onto the next step!

You’ve set up a shiny new webserver, installed php, mysql, and it all seems to be going swimmingly.  You’ve even created phpinfo() file and everything seems to be working.

Then you copy something into the html folder, and just get endless 403 errors when trying to access it.

So you faff around with permissions, users, groups.  No change, nothing works.

In my case, SELinux was the devil here.

This ServerFault post shows how to fix it
ServerFault: Completely random 403 errors despite explicit Allow from all

and for more info:
CentOS Wiki: HowTos > SELinux