Web Server Creation

Updated 2016-02-06

I use WordPress to create my websites. These notes are intended to be reminders to my self. If you choose to use them, you do so at your own risk. A few notes about the setup process:

1. You need a fixed IP (also called a static IP). You get this from your Internet Service Provider (ISP) (Comcast / ATT etc). This will be a routable IP address. The gateway has two IP addresses, the outside IP (called the WAN IP) and the inside (called the LAN IP). The inside IP will be in the range of for ATT and for Comcast. (lookup non-routable IP addresses on the internet if you want to know more)

2. Your Web-server will be a computer which also has a static IP. This static IP will be a non-routable IP. If your network is small (less than 20 or 30 devices, I suggest that you assign static IP’s by using the first three octets from the gateway’s LAN IP and using that as the starting values for the devices inside your network. For example, assume the Gateway LAN IP is, then you could make your web-server be Give it a subnet mask of, and you can use the DNS server your ISP assigned or the Goggle DNS of and

3. Once you have those two devices working to the point where you can use the web-server box to connect to the internet, (try using Firefox to bring up Google) now you start configuring the web-server box to actually be a web-server. Check the gateway router and open required ports (443 and 80) and set them to port forward to the web-server box.

Setup your web-server
A. Fedora (Last used Fedora 23 workstation spin)

Manually configure disk space.

/boot 50G

swap 20G

/ all remaining disk space

As soon as you can get it booted off of the hard disk, start sshd

service sshd start

chkconfig sshd on

Follow instructions here .

B. dnf -y update

C. dnf -y install httpd mysql-server perl emacs php system-config-printer dolphin

dnf -y install fedora-upgrade php-mysql k3b firewall-config

dnf -y install system-config-network gnome-desktop switchdesk

D. dnf -y update

E. fedora-upgrade

F. Reboot. Note the only time a Linux box should need to be rebooted is:

1. OS upgrade.

2. recreating selinux labels (most of the time this can be managed without the reboot.)

G. edit /etc/hostname to be correct

Change /etc/hostname file be floozy.yourdomain.com
Where floozy is the name you want to assign to your server (It can be anything you want, I suggest that you keep it short, Do not use the name of anybody you know.)

H. Configure php.ini

edit /etc/php.ini

fix the following defaults:




default port 3306

4. Test:
service httpd start
Check to make sure httpd is working.

service httpd status

chkconfig httpd on


check http and https

(be sure to click on options → “runtime to permanent” )

At this point you should be able to point your browser (on the web-server box) to and see the Apache test page.

5. Get your domain name (Godaddy, NetworkSolutions, etc). Point the domain name to your static IP as assigned by your ISP. Contact your service provider (Comcast or whatever) and make sure that your reverse DNS is correct. The Registrar (Godaddy, Network Solutions, etc) typically creates the info on their servers and it takes 4 – 24 hours to propagate (become visible to you).
Test by using nslookup.

6. If you have another computer to work with, inside your firewall you can use it to do testing if you fix it correctly. Change the /etc/hosts file in your testing machine to point to the LAN IP of the web-server:

Add  lines like this:



At this point, you can use your the browser on your smart phone or your test machine to lookup your domain name and see your test page. (Turn off WiFi temporarily while using the smart phone to do this test.) If you don’t have a smart phone, you can test from another machine inside your firewall (see above) go to your nearest public library and use on of their computers. If you don’t see the test page, no point in proceeding until you see it.

7. Now, some high level configuration steps in the web-server:
In /etc/httpd/conf/httpd.conf
Make sure that the Listen line says
Listen 80

Fix the serverName line in this file to specify your primary fully qualified name:
ServerName www.example.com

8. type:
service httpd stop
service httpd start

Re test: A lot of stuff can go wrong in getting things going to this point. It is best to be sure you have this much right.

9. In /etc/httpd/conf.d
Create a file called WEBSITE.conf (Use the the name of your website where I put WEBSITE.) download the webserverfiles

Unzip the webserver.zip and look at example.conf

Copy this file and rename it to yourdoman.com.conf and put it in /etc/httpd/conf.d

If you host more than one site, you should add them as website2.com.conf, etc in this same directory.

10. Setup mysql

service mariadb start

chkconfig mariadb on

Go into MySQL and setup MySQL (password protect root)
mysql -u root

SET PASSWORD FOR ‘root’@’localhost’ = PASSWORD(‘acomplexpassword’);


Be sure to write this password down.

11. Create the database and user for your WordPress domain.

For each domain you will need to have four pieces of information here. WRITE THEM DOWN and save them. (or enter them in a spread sheet, but be sure to keep the spread sheet offline. Use a thumb drive. And keep it hidden. See example spreadsheet in the zip file which is embeeded in step 9.)

Database name (I usually end my database names with something that will remind me that this is a database name like _dbn.)

User name (tie this to the website.)

Password (use something that is un-guessable.)

Prefix ( use wp and something from your domain-name, if your domain name is “EXAMPLE.com”, you might choose a prefix of wpec_.)

Since we are planning ahead, we know that we will need a completed, testable, reapeatable backup plan. We are going to want to have a plan that allows you to rebuild this wordpress site from our backup.

create a directory /root/wordpress-support

and a directory /root/wordpress-backup

Now create the following files (Use examples from the zip file in step 9, Customize and rename.)




chmod +x make_website.com.sh

run the new files


Make sure that there are no errors. Repeat for all sites/domains.

12. Download WordPress from wordpress.com to your /root/downloads folder

13. Copy the wordpress zip file to /var/www

14. Unzip WordPress. It will create a wordpress folder. Rename the wordpress directory to website.com

15. Repair ownership
cd /var/www/
chown -R apache.apache  website.com/*

Check permissions:

Should be 755 for directories.

find . -type d -exec chmod 755 {} +

Should be 644 for all other

find . -type f -exec chmod 644 {} +

Check your SELINUX context. Should be httpd_sys_rw_context_t

If it is not, fix immed.

cd /var/www

chcon -R -v -t httpd_sys_rw_context_t  /var/www/website.com

Check your work

ls -lZ /var/www/website.com

Note: three reasons for updates to fail are fixed above:

Ownership, permissions, selinux context.

16. Configure WordPress

cd /var/www/domain
cp wp-config-sample.php wp-config.php

edit the file wp-config.php
put in values for DB_NAME, DB_USER, DB_PASSWORD, $table_prefix
add one line that says
define( ‘FS_METHOD’, ‘direct’);

Point your browser at the website and bring the webite up up. When WordPress comes up, you will login to the website and finish the install and you can take updates to themes and such.

17. Start setting up your backup processes. You need another computer to server as your backup machine.

On the Web server:
ssh-keygen -t rsa

chmod 700 .ssh

chmod 600 .ssh/*
ssh backupuser@backupmachine mkdir -p .ssh

At this point if you can’t login:

A. Make sure that sshd is installed and running on the backup machine.

B. Check firewall-config on the backup machine. Make sure that ssh is checked.
cat .ssh/id_rsa.pub | ssh backupuser@backupmachine ‘cat>> .ssh/authorized_keys’
ssh -X backupuser@backupmachine

If this asks for a password, something failed. Most likely there is some kind of issue on the backup server.

A. Permissions  700 of the .ssh dir, 600 on .ssh/authorized_keys

B. You may have selinux issues

To see if you have selinux issues:

type ls -Z .ssh/authorized_keys

If it shows any fcontext besides ssh_home_t you need to fix it.

semanage fcontext -a -t ssh_home_t /home/backupuser/.ssh/authorized_keys

restorecon -r .ssh

ls -Z .ssh/authorized_keys

If ok, reboot and check again.

If it fails at any point, type:

touch /.autorelabel


On the backup machine be sure to create a directory for your webserver backups.

mkdir webserver_backup_directory

18. Next we create some directories and scripts on the webserver.

You will need several scripts for your website. ( You already have two files in wordpress-support for each domain.)

Create a bash script called


(see webserverfiles.zip in step 9)

19. Now start creating the backup scripts for the individual domains which are on your host.

This backup script for each domain will be called /root/wordpress-support/bck-domain.sh  It needs to contain the two lines: (see webserverfiles.zip in step 9)


./Generic_backup.sh /var/www website-name user pass database_name

Next you need to create the backup_all.sh script. (see sample in webserverfiles.zip from step 9) This script will run the backup script for all sites served by your webserver and copy it to your backup machine.



repeat this line for all site served on this box, then finally add:

rsync -rvh -e ssh /root/ backupuser@backupmachine:webserver_backup_directory/

20. Create the Generic restore script as /root/wordpress-support/Generic_restore.sh (see webserverfiles.zip in step 9)

21. Now create the actual restore script.

create the following files




chmod +x /root/wordpress-support/drp_website.com.sh

Use the template from webserverfiles.zip in step 9.

22. Once you have created all of the files, test them.


Remove the website, remove the website’s conf, drop the user and the database.


service httpd reload

Call up the domain on your browser.

23. Add the follow line to the web server crontab

Use command crontab -e

If you do not have a crontab already, add the header:

#min hr dom mon dow command

Then add

30   00   *   *   *  /usr/bin/dnf -y update

Update the system software at zero dark 30.

15 18 * * 5 /root/wordpress-support/.backup-all.sh
This means that cron should run a back up at:
15 min after the hour of 6 pm on Friday evenings only.

If this machine is to be a failover, do not allow backup to run (comment out the command in crontab). Instead run a recover_all about an hour after the “live” machine run its backup_all script.

24. Check your work:




In wordpress-support

Generic files (should be two)


The following files should exist for each wordpress domain

Backup_all.sh (one)







25. Protect your website, add plugins:
Bullet Proof security
ipcloud (if you have more than one domain.)

26. Add content and start using WordPress to do useful stuff.

Note: Web server SSL is a separate topic. You need SSL if you are going to:

Process Credit Cards.

Allow users to access their email via a website (Squirrel Mail)


27. Failover process

Steps 2-4, 6(probably), 7,8 (definitely), 23

Determine the last good backup’s date.

Now execute each “rst” script.




Up in the country.