Friday, August 12, 2011

Trying Ubuntu Linux (3)

I have an idea that someday I might try to teach students how to set up a web site (for example, EMBOSS on a local network would be nice). Python would be a perfect fit and it should be fun and extensible. I would probably want a neutral platform to do that (since most would be trained on Windows and I know nothing except OS X), so I looked into adding Apache Server to my Ubuntu 11.0.4 Desktop install (posts here and here).

There is a nice guide on the web from Ubuntu (here), and some simple instructions are here, and the Apache docs are here. I could have started by grabbing the Server version of Ubuntu, but instead I did:

sudo apt-get install apache2

As easy as that. Start and stop commands:

sudo /etc/init.d/apache2 start

sudo /etc/init.d/apache2 stop
sudo /etc/init.d/apache2 restart

To test it, just use Firefox and point it at localhost or The index page is at /var/www/index.html (the "document root" is /var/www). If you want to get a little fancier, you can grab PHP:

sudo apt-get install php5 libapache2-mod-php5

sudo /etc/init.d/apache2 restart

And put this in /var/www/test.php:

<?php phpinfo(); ?>

Go to localhost/test.php and it should print a bunch of details about your setup.

I spent a lot of time working on access control (Apache docs here). I should probably have read the VirtualBox guide first (here):
A virtual machine with NAT enabled acts much like a real computer that connects to the Internet through a router. The "router", in this case, is the VirtualBox networking engine, which maps traffic from and to the virtual machine transparently. The disadvantage of NAT mode is that, much like a private network behind a router, the virtual machine is invisible and unreachable from the outside internet; you cannot run a server this way unless you set up port forwarding (described below).

Actually, we will want to do this later. A lot of time was wasted because I followed the "simple" instructions (e.g. Apache's) and couldn't figure out why stuff didn't work.

It turns out that although /etc/apache2/apache2.conf and /etc/apache2/httpd.conf have relevant settings there are a bunch of other files (in directories under /etc/apache2/). If you want to change access to the document root or scripts, you have to modify /etc/apache2/sites-available/default. Guess I should have read the first page (here) of the Ubuntu Server docs. It's right there!

Here is part of the file in the original form:

	ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all

I'm not sure what all of this does, but using ScriptAlias means that (Apache docs again):
The ScriptAlias directive tells Apache that a particular directory is set aside for CGI programs. Apache will assume that every file in this directory is a CGI program, and will attempt to execute it, when that particular resource is requested by a client.

I just modified /usr/lib/cgi-bin/ to be /home/te/cgi-bin/.

And, since we will ultimately care about access permissions, you should read (at least) this page of the docs, which explains that

		Order allow,deny

is explained as:
First, all Allow directives are evaluated; at least one must match, or the request is rejected. Next, all Deny directives are evaluated. If any matches, the request is rejected. Last, any requests which do not match an Allow or a Deny directive are denied by default.
First, all Deny directives are evaluated; if any match, the request is denied unless it also matches an Allow directive. Any requests which do not match any Allow or Deny directives are permitted.

I copied from further down in the file (about access to /usr/share/docs) to the ScriptAlias directive above:

        Order deny,allow

Deny from all
Allow from ::1/128

The subnet masking stuff will need an explanation of its own.

So now, I can put the first script from the second part of this post (that prints data from os.environ in cgi-bin under my home directory, and it works.

No comments: