Creating A TEST Environment On Ubuntu Workstation

By Gerry Patterson

Creating a test environment for an Apache webhost does not necessarily require another webhost. It is easy enough to setup a copy of the webhost and run it as a TEST instance. This is very easy for Ubuntu users, who have access to everything required to make their workstation behave exactly like a server.

---

To Test Or Not To Test?

The principle of a TEST or DEVELOPMENT environment is well established in Enterprise computing circles. However, in the early days of the Internet it was possible to setup a web site without a development host, and the idea was not embraced with enthusiasm by the motley crew of geeks and gifted amateurs who were building sites back in those pioneering days. Web sites often consisted of simple static pages, and it was possible to setup a mirror image of the website on a local drive and make changes offline. When everything looked ok, the pages could be uploaded to the webhost.

There were a couple of little inconvenient details that crept in. For example using this approach, it was necessary to use links relative to the Apache Root folder. This can lead to some rather cumbersome relative links.

Websites have become more complex. Nowadays a webmaster must contend with CGI. This may be perl or PHP. Pages often also use style sheets and the data is likely to be stored in a DBMS such as MySQL or postgres. Also the webhost may be running a Java server such as Apache Tomcat.

Altering a website is no longer as simple as it was when there were only static pages to contend with. It may be possible to design the site to cope with new material being constantly uploaded, but a major change which impacts the entire website could be risky. Some examples of changes that should be tested first include:

• New style sheets.
• New core subroutines in CGI scripts or new components in CGI scripts.
• New javascript subroutines.
• DBMS upgrade or alteration.

These are but a few of the changes that could have serious consequences for a website. In fact any change which has the potential to have a major impact on appearance or may have system wide implications requires thorough testing. Without a test environment, such changes can cause extended outages or missing or useless pages displaying the much-maligned "Under Construction" icons.

However, you may not want to dedicate a host to this. If so, it might be possible to use a workstation as a development host. This does have the potential of disrupting two workstations however. The workstation which is now "pretending" to be the host and the workstation that you are using to pretend it is a client. There is also the problem of DNS. As you work on your TEST site at foo.com, what do you do when numerous links are encountered to to www.foo.com?

If you are using Ubuntu, it is easy to setup one workstation to be a development environment for your webhost, and to make it so that this environment can be switched on or off. So that when it is not being used for development it reverts to being a standard workstation. All you need is Apache, Tomcat, bind9, MySQL (and/or postgres). All of these are available as Ubuntu modules.

I have setup my Kubuntu workstation to be such a development environment. This method could be used for any Ubuntu workstation on a LAN with a static IP address.

---

Finding the software.

All the necessary software can be obtained with Debian APT (Advanced Packaging Tool). Unfortunately, I did not take notes when I installed the software. I installed each package as I required. However, when I tried to install Apache on an Ubuntu and tomcat on an Ubuntu workstation, several additional packages were recommended.

At present these are the commands that will install Apache, tomcat and BIND:

1. Install Apache.

       sudo apt-get install apache2
   

2. Install Tomcat.

       sudo apt-get install tomcat5.5
   

   Note: On an Ubuntu this resulted in the following messages:

   The following extra packages will be installed:

   ant jsvc libbcel-java libcommons-beanutils-java libcommons-collections-java libcommons-collections3-java libcommons-daemon-java libcommons-dbcp-java libcommons-digester-java libcommons-el-java libcommons-launcher-java libcommons-logging-java libcommons-modeler-java libcommons-pool-java libecj-java liblog4j1.2-java libmx4j-java libregexp-java libtomcat5.5-java

   Suggested packages:

   ant-doc libbcel-java-doc libcommons-beanutils-java-doc libcommons-collections3-java-doc liblogkit-java libavalon-framework-java classpath-doc ecj libgnumail-java jython libapache2-mod-jk tomcat5.5-admin tomcat5.5-webapps

   Recommended packages:

   ant-optional ant-gcj libecj-java-gcj liblog4j1.2-java-gcj

   The following NEW packages will be installed:

   ant jsvc libbcel-java libcommons-beanutils-java libcommons-collections-java libcommons-collections3-java libcommons-daemon-java libcommons-dbcp-java libcommons-digester-java libcommons-el-java libcommons-launcher-java libcommons-logging-java libcommons-modeler-java libcommons-pool-java libecj-java liblog4j1.2-java libmx4j-java libregexp-java libtomcat5.5-java tomcat5.5

3. Install BIND.

       sudo apt-get install bind9
   

Installing the recommended packages may make life easier when you need some documentation.

---

Setting Up The TEST Webhost

After installing Apache and Tomcat, you will need to set the configuration to be similar to the the production instance. If the production instance is running the same versions of software, you may be able to use the same configuration files, with only small modifications.

Once again, I did not make any notes about the files which I had to change to configure Tomcat and Apache. However this is something that is highly specific for each installation. Most of the config files are kept in /etc

One thing you will need is a process which copies PROD to TEST. In my case I wrote a script which copies the nightly backups to the test instance. The backup consists of all the static pages, CGI scripts and backup of the databases.

So while you are setting up your test instance and copying the data into it, you should perhaps think about how the scripts you use might be incorporated into a general purpose script which copies PROD to TEST.

---

Setting Up DNS

The reason I install DNS on the workstation is because I plan to run a local version of DNS which is a mirror of the domain's primary DNS, with one important exception. The host that I wish to emulate is set to the local host. This is pretty easy if you are responsible for the configuration of your DNS. If not then you may be able to guess the details by using nslookup.

In Ubuntu (and Kubuntu) the standard location for BIND configuration files is in /etc/bind. The file /etc/bind/named.conf will contain zone entries for all the domains you have been delegated. Since this is not a real DNS server, you may take control of one of these zones. If your actual webhost is www.foo.com.au and you may have configured the zone foo.com.au as follows:

zone "foo.com.au" {

type master;
file "/etc/bind/db.foo.com.au";

};

Inside the file /etc/bind/db.foo.com.au, will be the configuration information for the FOO domain. It might look something like this:

$TTL 86400 ; FOO zone foo.com.au. IN SOA gate.foo.com.au. fred.foo.com.au. (                 2009042600 ; Serial (date)                 86400   ; refresh                 7200    ; retry                 864000  ; expire                 86400 ) ; minimum ; nameservers         IN      NS ns         IN      NS ns1 ns      IN      A  116.121.49.143 ns1     IN      A  116.121.49.96 ; hosts whost  IN      A  116.121.49.143 gate   IN      A  116.121.49.143 ; mx record foo.com.au.  IN MX 10 gate.foo.com.au.              IN MX 20 blah.isp.com.au. ; nicknames www     IN      CNAME whost ftp     IN      CNAME whost mail    IN      CNAME gate ; system info gate    IN      HINFO "Intel" "Linux" whost   IN      HINFO "Intel" "Linux"

You will need to setup your TEST DNS in a similar fashion, using non-routable addresses from your LAN. For example if your LAN is configured for 192.168.1/24, and your workstations uses the address 192.168.1.19, and has a hostname of hw04, you would set it up as follows

$TTL 86400 ; FOO zone foo.com.au. IN SOA hw04.foo.com.au. fred.foo.com.au. (                 2009042812 ; Serial (date)                 86400   ; refresh                 7200    ; retry                 864000  ; expire                 86400 ) ; minimum ; nameservers         IN      NS ns ns      IN      A  192.168.1.19 ; hosts hw04   IN       A  192.168.1.19 ; mx record foo.com.au.  IN MX 10 hw04.foo.com.au. ; nicknames www     IN      CNAME whost ; system info hw04    IN      HINFO "Intel" "Linux"

Next you need to modify resolv.conf. Linux will still abide by changes made to resolv.conf even though most distributions have their own GUI interface for networking. You should create a TEST config file (call it something like resolv.conf.test), so that it can be copied over the regular resolv.conf file. It will contain something like the following:

nameserver 127.0.0.1
search foo.com.au.
domain foo.com.au

Note: Make sure you first backup the existing resolv.conf (call the backup copy something like /etc/resolv.conf.normal).

Now when you start DNS, regular queries on the localhost (like www.google.com or www.ubuntu.com) will go to the Internet, but queries to foo.com.au will resolve to the local host. If you start your Apache server, your workstation will now operate as a TEST instance behind your firewall.

---

Startup Scripts

There was one small problem after I setup the workstation in this manner. The first time I started the Apache server, I noticed the following error message:

Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName

This was fixed with the following command:

hostname hw04.foo.com.au

Where hw04 and foo.com.au are the values you have assigned for the (workstation) hostname and your domain, as discussed previously. This makes your workstation behave more like a server (in accordance with the DNS entries). I added a hostname command to the script that starts the Apache Test Instance. I called this script start_test and placed it in the location /usr/local/sbin (this folder has been added to the root user's PATH). Now all that is required to start the TEST instance is this command:

sudo start_test

I then press Ctrl-Alt-Backspace and login again (see an explaination of the X-server problem below).

The start_test script looks something like this:

#!/bin/sh -e echo setting up TEST environment on `hostname` hostname hw04.foo.com.au # NB: make sure that rc.local over-writes this at startup cp /etc/resolv.conf.test /etc/resolv.conf /etc/init.d/bind9 restart /etc/init.d/apache2 restart /etc/init.d/tomcat5.5 restart mkdir /tmp/cgi chown apache:apache /tmp/cgi echo done

The reason for the mkdir command is that many of the CGI scripts use this folder to write temporary data. The /tmp/cgi folder is purged and removed whenever the Kubuntu workstation is restarted (which is standard behaviour for workstations).

However after I did this, I noticed the following error message would flash up momentarily whenever I used "vi":

_IceTransSocketUNIXConnect: Cannot connect to non-local host foo

This appears to be something to do with the X-server. For many processes it can be ignored. But for certain X-windows programs it could be fatal. I found the easiest way to fix it on Kubuntu was to log-off and log-on.

The Kubuntu workstation now had two functions:

1. Regular workstation
2. Apache webhost testbed.

I decided to set it up so that the default startup mode was regular workstation.

This involved including a script like the following in rc.local:

#!/bin/sh -e # # rc.local # # put any other stuff you might want to here ... # setup resolv.conf for normal browsing and stop BIND and apache cp /etc/resolv.conf.normal /etc/resolv.conf /etc/init.d/bind9 stop /etc/init.d/apache2 stop exit 0

This ensures that whenever the machine is shutdown the default startup mode is regular workstation.

---