Simple Perl and CGI example

This is probably the simplest possible example to get Perl working through cgi on Apache HTTPD. Instructions are for Ubuntu 12.04.

Install apache httpd:

sudo apt-get install apache2

Add the following "hello.pl" script to the /usr/lib/cgi-bin directory:

#!/usr/bin/perl

print "Content-type: text/html\n\n";
print "Hello World!";
exit;

Point your browser at http://localhost/cgi-bin/hello.pl and that's it!

Apache - Enabling the info module

If you've ever wanted to have something like the phpinfo page for Apache, that showed all of the modules that were enabled as well as configuration and compilation settings, just make use of the mod_info module:

This can be useful for getting a definitive answer on which configuration files are being loaded as well as what modules are being loaded and what they're configured to.

However, as with phpinfo, you have to keep security in mind when using it as a lot of this information can be used by potential attackers. The recommended way of securing it is just modifying the configuration file (/etc/apache2/mods-available/info.conf) to deny access from all but trusted IP addresses:

<ifmodule mod_info.c>

<location /server-info>
    SetHandler server-info
    Order deny,allow
    Deny from all
    Allow from localhost ip6-localhost
#    Allow from .example.com
</location>

</ifmodule>

By default, the only access allowed is from localhost.

How to setup Apache as a Tomcat proxy

In this post we're going to setup Apache to act as a proxy for the Tomcat application server on Ubuntu. First off we need to install the "tomcat6" package from the Ubuntu repositories, which is as simple as:

sudo apt-get install tomcat6
and answering "Y" to download Tomcat along with all of its dependencies. To make sure that the Tomcat server is running, try to open up port 8080 on the machine in your browser. If all is well you will see the Tomcat server Welcome page. If not, you may need to start up the server, which can be done with:

sudo service tomcat6 start

Next we need to install the Apache HTTP server, which "apt-get" also makes easy for us:

sudo apt-get install apache2

Again, just enter "Y" when asked whether to download the package and all of its dependencies.

In order to enable Apache to act as a proxy for Tomcat, we're going to need to make use of the "proxy" and "proxy_http" modules. Unfortunately these two modules don't come enabled by default, so we're going to have to enable them and restart apache for the changes to take effect:

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo service apache2 restart

Now we need to tell the proxy module how to proxy the requests and where to proxy them to. For this I've created a "tomcat-proxy" file under /etc/apache2/sites-available/, which we're going to enable using Apache's a2ensite command. The file itself looks like the following:

ProxyRequests Off
ProxyPreserveHost On
ProxyTimeout 1000
TimeOut 1000
#
# Configure the mod_proxy
#
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/

After editing the file we enable the site and reload Apache's configuration:

sudo a2ensite tomcat-proxy
sudo service apache2 reload

And that's it! If everything's gone to plan we should be able to hit up port 80 on our server and get the Tomcat welcome page.

Note that this isn't the only way to configure Apache as a proxy. A more sophisticated way is to make use of the AJP protocol/module, which is custom designed to work with Tomcat.

To get Apache proxying to Tomcat using the AJP protocol, we have to enable the Apache module and restart Apache for the changes to take effect:

sudo a2enmod proxy_ajp
sudo service apache2 restart
Next we have to enable the AJP connector in Tomcat. This is done in the /etc/tomcat6/server.xml file. If you edit this file you'll need to uncomment a line, which looks like:

<connector port="8009" protocol="AJP/1.3" redirectport="8443"></connector>

and restart Tomcat:

sudo service tomcat6 restart

The next step is to simply go back to our configuration file under /etc/apache2/sites-available/tomcat-proxy and change the protocol and port of the URL's we supplied the ProxyPass and ProxyPassReverse directives:

ProxyRequests Off
ProxyPreserveHost On
ProxyTimeout 1000
TimeOut 1000
#
# Configure the mod_proxy
#
ProxyPass / ajp://127.0.0.1:8009/
ProxyPassReverse / ajp://127.0.0.1:8009/

You'll notice we've replaced "http" in the URL with the custom "ajp" protocol. Restart Apache and hitting port 80 on the server should redirect you to the Tomcat welcome page as before.

What's the difference between the two approaches to proxing? Functionally there's not really any difference that the user gets to see. However, the AJP is a binary protocol, compared to the regular HTTP proxy method that the first approach uses. This should mean less data passed between the proxy and application server as well as lower latencies. Look out for a future post benchmarking the two approaches to see what the real-world difference in performance between the two approaches is.

Apache HTTP Server userdir module

As a part of setting up a development environment for creating web applications/sites to be deployed to Apache HTTP Server, one of the things I would highly recommend is making use of the userdir module. This module allows a user to create their own directory (under /home/[user]/public_html) and have that directory automatically be made accessible by Apache at http://localhost/~[username]/ and thus skips a lot of the headaches that are caused by permission problems.

To set up this module, first you need to create this directory:

mkdir ~/public_html

The next step is to enable the module:

sudo a2enmod userdir

Note that if you want to change the name of the directory or any other settings for this folder, you can do so by editing the /etc/apache2/mods-available/userdir.conf file.

Then, finally we just need to restart apache for the module to be loaded:

sudo /etc/init.d/apache2 restart

If it all went well, you should now be able to open your browser and browse to http://localhost/~[username]/ and see the contents of your public_html directory.

Another very important thing to mention is that by default, PHP processing is disabled on this directory. If you need to turn on PHP processing, you need to modify the /etc/apache2/mods-available/php5.conf file:


<IfModule mod_php5.c>
<FilesMatch "\.ph(p3?|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch "\.phps$">
SetHandler application/x-httpd-php-source
</FilesMatch>
# To re-enable php in user directories comment the following lines
# (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
# prevents .htaccess files from disabling it.
<IfModule mod_userdir.c>
<Directory /home/*/public_html>
php_admin_value engine Off
</Directory>
</IfModule>
</IfModule>


Like it says in the commented out sections of this file, you just need to comment out the mod_userdir.c section to enable PHP on the ~/public_html directory.

Apache HTTP Server VirtualHost directive

Once of the things which always catches me out is the use of the VirtualHost directive in the configuration files for the Apache HTTP server. When you need to set up virtual hosting (i.e. more than one host off of the same IP, differentiated by the hostname) you need to use this directive. However, don't make the assumption that you can do something like:

<VirtualHost www.example.com>...</VirtualHost>

and that this will result in having a server defined for the 'www.example.com' hostname. The VirtualHost directive is used only to define the IP that this "virtual server" should listen on. It does not define which hostname it should reply to. While the above configuration is legal, the actual behaviour of Apache's HTTP Server is to lookup the hostname, convert it to an IP and use that in the directive. Functionally, it is no different than doing:

<VirtualHost [IP Address of www.example.com host]>...</VirtualHost>

Using the hostname in this part of the configuration might lead to some unexpected behaviour. For me, I added this directive with a hostname, expecting that the configuration section would only apply to a particular hostname, when in fact it matched all hostnames using that IP.

The correct way to define a hostname based virtual host is to make use of the ServerName and additionally ServerAlias directives inside the VirtualHost stanza.

So there's only web development...

So, after talking to a friend of mine he came up with a statement that I believe sums up the New Zealand IT industry pretty well. "Its all web development". The industry here contains a few large companies, which hire some CS/SE graduates, but the vast majority will find themselves after university working on some aspect of developing essentially web pages.

For someone who doesn't particularly enjoy web development, this is a rather bitter pill to swallow, learning that if you want to work in any other aspect of IT, you should probably move to Australia/UK/America.

What's even more disappointing is that during my 5 and a half years at university, there was hardly any emphasis placed on web development. I think in total there were 2 courses that dealt with any kind of web development. This leaves a large gap in my education, as people that are hiring are looking for experience with CSS, Javascript, AJAX, technologies which the university does not teach at all, and PHP/ASP.NET, MySQL/MSSQL which the university does a poor job of teaching. In fact looking at the curriculum the only thing that the Computer Science degree seems to prepare you for is more Computer Science.

So anyway... It's no use bitching about the past now. If I'm doomed to become a web developer then I might as well become the best fucking web developer this side of the equator. But this is going to involve a lot of learning. The type of learning I dread and generally avoid. Learning by yourself, in your own spare time. Having to force yourself to read another chapter after coming home from work tired and worn out from your shitty job. The really hard kind of learning... fuck.

But I do in fact have a plan. And having a plan keeps me from having a total nervous breakdown, something which I've been really close to this last month.

My plan essentially involves learning everything about web technology, from the ground up, from setting up a LAMP server to AJAX. This is an ambitious goal for me, one which might take over a year or more to complete as I don't know how much time I will be able to commit to my "2nd education". But I do know roughly what it will involve.

Step 1: Wiring up my house. That is to say put in ethernet cables connecting the bedrooms of the house, the living room and the garage. This will allow me to put my de facto webserver (old HP pentium 4 my girlfriend was going to throw out) into the garage and to have it running full time. This computer is a mixture of web server and storage server (after adding a 320GB HDD) and will serve files to the internet and to the different devices around the house (in the future I could have a separate machine as a file server and a webserver) This should also give me experience on how to set up a network for a SOHO (Small Office Home Office).

Step 2: Domain Name. Opening an account with a dynamic dns provider and setting up a domain name. Probably going to use dyndns.com as it seems to be quite popular.

Step 3: Learning about webservers, file servers, ssh servers, nfs servers, ftp servers, proxies etc... Because I want my web/storage server to be universally accessible it needs to be able to serve files across a wide range of protocols. For each of the types of server I need to

1. Install the software
2. Configure the software i.e. get it to do what I want securely

Luckily I have found a resource that deals with these issues and a lot more. The resource being www.linuxhomenetworking.com. The website is well written, easy to read and up to date. It's also free.

[NOTE: I should mention now that I intend to use only OSS software as a part of this education, for reasons which I will probably write about later]

Step 4: Install software for the management of my server. This includes things like Webmin, MySQL Administrator, PHPMyAdmin and perhaps some software to configure Apache (is there a decent GUI frontend for Apache or does it come down to editing config files?)

Step 5: Installing existing CMSs' and understanding how they work. Looking at software such as Joomla!, Drupal, Wordpress, Blogger (is the blogger source code available?), Silverstripe (Go NZ!) etc... and looking at how they are made, paying particular attention to how they handle extensibility (add-ons, extensions) and theming. However for the basic ideas on how to create a CMS I'll probably start with php-mysql-tutorial.com. It should be interesting to see how much difference in the designs of these CMSs' there is and the benefits/disadvantages of each approach.

Step 6: Learn Cascading Style Sheets. I have a real love/hate relationship with CSS. That is to say I f***ing hate CSS. As far as I'm concerned, CSS is a great idea (separation of content and presentation), implemented in a totally illogical, counter-intuitive, overly complex way. But to be fair, that's what I thought of a lot of programming languages I learned until I "got" them. So maybe sometime in the future I will really love CSS, but I wouldn't bet money on it. I'm probably gonna go with the tutorials from W3Schools or failing that get a book from the university library on CSS.

Step 7: Learn Javascript. Again, I feel like I'm 10 years behind the learning curve with this one, but thanks to university (and my own lack of interest in web development) this is another area which I have hardly any experience with. With this one I'm gonna follow the W3Schools tutorials and if needed get a book from the uni library.

Step 8: Learn XHTML. Another one from W3Schools. Basically need to learn along with Javascript to be able to understand AJAX in step 9.

Step 9: Learn AJAX. Start with W3Schools tutorial on AJAX, then can move on to other examples on the internet. There's so many on the web that the biggest problem learning is going to be information overload. A book might be useful as well.

So then the question arises as to what to do with all of this new web development knowledge and the server sitting in my garage. The thing to do I guess would be to make a website to showcase my talents which could be a point of reference for people seeking examples of my skills/knowledge.

Also the idea of creating a photo gallery CMS based on the work I did with LaPhotographie is an idea I've had for a while. Such a system would, of course be open source and perhaps some day take off and become more than a pet project.

And the possibility of turning the setup in my garage into a web hosting company is there as well.

So there you go, that's my plan. It helps me to keep busy and ignore the fact that I'll probably end up doing web development for a long, long time.