Okay, so we should now have a running config available for us. You can retest it now by running the sudo /usr/local/apache2/bin/apachectl start command. At this point, if you point your browser over, you should reach whatever index.html or directory listing is available in your personal user Sites directory.
It is worth noting that you can modify the
Beyond this, we also want to install MySQL, which is a light and simply database package freely available as well. You can download the latest package here MySQL. Again the installation commands are fairly straightforward, simply enter the following series of commands in your expanded directory:
- sudo configure
Okay, so now to PHP. This package is pretty much a must-go for most installs, and in particular for wordpress, apart for being light and fast, it also extremely well integrated with other SQL database packages that I will get to in a short bit. The only thing to watch out with this installation will be to ensure that we also include the DSO for the php package over with Apache. Unfortunately, as PHP is a third-party code set, we can not include it in native form into Apache without a bit of added difficulty. So, to keep things simple, we’ll load it up using Apache’s DSO apxs library packager tool. This load-up is done at the configuration stage which involves the following steps:
- Go to your extracted PHP package source set directory
- Enter the following commands
- ./configure \
- You’ll notice the last command option –disable-cgi is perhaps not your preferred option but it seemed to workaround a little issue with the 5.3.3 release. There should either be a quick fix for this or else a correction available in later versions.
Now you should have created a php module over in to you /usr/local/apache2/modules/ directory called libphp5.so. We now need to do two things:
- Ensure that the php.ini file in your /private/etc/ directory is available and then ensure that the php module is called up by the Apache configuration file.
- Simply copy over the /etc/php.ini.default over to /etc/php.ini
- sudo cp /etc/php.ini.default /etc/php.ini
- Now go back into your apache configuration file and enable the relevant library
- sudo pico /usr/local/apache2/conf/httpd.conf
- Edit the file by adding in the relevant section the following line
- LoadModule php5_module /usr/local/apache2/modules/libphp5.so
- Exit the configuration file and remember to save
- Restart your apache server (if the daemon wasn’t running then just enter start instead of graceful)
- sudo /usr/local/apache2/bin/apachectl graceful
And there you go, you now have a MySQL, php5 enabled functional web server with one of the lightest server loads out there. You will barely notice its operations on your daily runtime which is a bit of an advantage over other GUI front-end solutions out there. In addition, you now have a base upon which to configure-up or over which you can then mirror whatever your dedicated hosted solution will deliver.
Okay, so you now have a server running smoothly but it lacks that little visibility that you can get from resolvable text domain names. In addition, though the website is visible inside your intranet, there lacks sufficient visibility on the outside world to access it. A few options are available to you:
- You can register a domain name fairly cheaply and gain rapid traction over your net identification by subscribing to a domain registrar
- Or, you can sign-up for a free sub-domain provider and gain some ‘named’ visibility over the internet.
The sub-domain providers out there essentially offer the right to piggy back over their domain name and then forward back traffic over to your ip, even if your ip is dynamic. This therefore allows one to have [insert name here].subdomain-provider.com addresses available for the rest of the world to access you. There are a number of sub-domain providers out there with the most famous ones being: DYNDNS and No-IP. Both these providers let you register for free, always an added bonus, and, in addition, often have connectivity functions built into your router or modem to keep their registration details up to date.
Now for the router/modem section, a little bit more configuration is required. Usually most routers have a basic configuration layout accessible by a web browser by simply pointing this over to 192.168.1.1 and will then prompt you for an admin id and password to access their configuration setups. Otherwise, you should be able to telnet into these using a standard telnet or ssh package. Once on these you will have to configure a number of features, first the actual NAT/PAT translation table, then ensure that sufficient freedom is allowed for incoming traffic and, if the manufacturer allows it, automatic updates of the sub-domain register provider’s IP assignation.
The NAT/PAT table is basically a translation table that the router uses to assign external traffic requests over to your network. It allows multiple private-IP addresses to share one public IP address and gives your server the ability to respond to requests sent out to the internet IP assigned to your router/modem. These settings should be fairly straightforward on your router/modem, only thing to check is that they forward over to the right port on your server, usually port 80 unless this was configured differently. Also, you might want to extend the broadcast protocols to UDP as well as TCP but this is entirely up to you.
The next thing to check are your firewall or security settings, clearly, you would prefer to keep these as safe as possible. So one way to maintain a simply level of access on your network without amending any other agent security rules is to set up a logical DMZ (demilitarised zone) linking the IP traffic straight over from the outside over to your chosen server. Again, this should be straightforward to do, however, both the DMZ and NAT/PAT might be hidden in the ‘advanced’ setting options of your router.
Last thing to verify is whether the router allows automated updates back to the sub-domain provider. If this is the case then simply input the relevant information and let the router update the domain registrar in due course. All of this should facilitate the flow for you. An alternative would be to set up a basic script on your server to run in background or as a cron job that checks your current internet IP and updates the server automatically. Last but not least, there should also be simple desktop packages available from the sub-domain register to really facilitate this task for you – this might be the least time consuming option out of all three but it does involve running another graphical object on your desktop (and if you forget to launch it then your domain remains unreachable). Continue to Part 4