Technology Tales

Setting up a test web server on Ubuntu

Installing all the bits and pieces is painless enough so long as you know what's what; Synaptic does make it thus. Interestingly, Ubuntu's default installation is a lightweight affair with the addition of any additional components involving downloading the packages from the web. The whole process is all very well integrated and doesn't make you sweat every time you need to install additional software. In fact, it resolves any dependencies for you so that those packages can be put in place too; it lists them, you select them and Synaptic does the rest.

Returning to the job in hand, my shopping list included Apache, Perl, PHP and MySQL, the usual suspects in other words. Perl was already there, as it is on many UNIX systems, so installing the appropriate Apache module was all that was needed. PHP needed the base installation as well as the additional Apache module. MySQL needed the full treatment too, though its being split up into different pieces confounded things a little for my tired mind. Then, there were the MySQL modules for PHP to be set in place too.

The addition of Apache preceded all of these, but I have left it until now to describe its configuration, something that took longer than for the others; the installation itself was as easy as it was for the others. However, what surprised me were the differences in its configuration set up when compared with Windows. There are times when we get the same software but on different operating systems, which means that configuration files get set up differently. The first difference is that the main configuration file is called apache2.conf on Ubuntu rather than httpd.conf as on Windows. Like its Windows counterpart, Ubuntu's Apache does use subsidiary configuration files. However, there is an additional layer of configurability added courtesy of a standard feature of UNIX operating systems: symbolic links. Rather than having a single folder with the all configuration files stored therein, there are two pairs of folders, one pair for module configuration and another for site settings: mods-available/mods-enabled and sites-available/sites-enabled, respectively. In each pair, there is a folder with all the files and another containing symbolic links. It is the presence of a symbolic link for a given configuration file in the latter that activates it. I learned all this when trying to get mod_rewrite going and changing the web server folder from the default to somewhere less susceptible to wrecking during a re-installation or, heaven forbid, a destructive system crash. It's unusual, but it does work, even if it takes that little bit longer to get things sorted out when you first meet up with it.

Apart from the Apache set up and finding the right things to install, getting a test web server up and running was a fairly uneventful process. All's working well now, and I'll be taking things forward from here; making website Perl scripts compatible with their new world will be one of the next things that need to be done.

Switching from Windows XP to Ubuntu

After a pretty rotten weekend attempting to keep Windows XP running, I finally lost the will to persevere and began yearning for stability. That has taken me into the world of Ubuntu; I am writing this in Firefox running on the said Linux distribution. Thanks to the wonders of VMware, I have been able to observe the swish and slick nature of Ubuntu, and I must that it did sway me. Installation has been slick and efficient and is a dream compared to XP, let alone previous Linux incarnations that I have encountered over the years. Start up is also speedy. All in all, there appears to be a certain confidence about the OS that was sadly absent from my Windows experience in recent times.

Still, I am not deserting the world of Windows completely, though. As it happens, I installed Ubuntu on a spare hard drive that I had, so the Windows installation is still out there. In addition, VMware virtual machines should allow me to stay in there without the ever present risk of a PC getting rendered inoperable. There is also the unfinished business of making myself at home on Ubuntu, hopefully without my wrecking anything. I have yet to give my hardware a full workout to check that all is well. Setting up a web development capability is also on the cards, as is getting those virtual machines. Assuming that there are no showstoppers, it could be an interesting ride.

Running multiple files on Windows using just two batch commands

Repairing Windows installations like I have had to do all too often in the last few weeks means that I have a load of updates that need to be performed. My preference for using Shavlik NetChk Protect means that I have a folder full of executable path files. That encapsulates the first step: creating a folder and adding the files that you want to run. The next step is to run a command like this:

dir /b * > exec.bat

The /b is the switch that gives a bare file list and that is stored in exec.bat. Running exec.bat affords a bit more automation. While it is that this might need a spot more sophistication to be truly automatic, it's still a good start.

Repairing Windows XP

I have been having an accident-prone time of it with Windows XP recently, and have had plenty of reason to be thankful for the ability to perform a repair installation. Here are the steps:

• Pop the installation disk into your PC's DVD drive and reboot the PC.
• If you have your PC set it up to boot from DVD's in its BIOS, then you at least will have the option to do this. You may find that this happens by default, but I needed to tell it to do the deed.
• Select normal installation from the first menu that is presented to you by the installer.
• Accept the licence agreement.
• Press R at the next menu and that'll repair the installation.
• Follow all the menus from there on; it'll be all the usual stuff from here on in, and there should be no need to reactivate Windows or reinstall all of your other software afterwards.

There is a repair option on the first screen (step 3 above) but this takes you into the dark recesses of the command line and isn't what I was needing. I do have to say that they do leave the required option late on in the installation process and that assumes on users having a risk taking streak in them, something that definitely does not apply to everyone. If your boot.ini file is not well, you may find yourself needing to do the full installation and that wipes the slate clean for you, extending the recovery process.

Keep a hold on those serial numbers…

In the times when all software was bought boxed, there were fewer issues with finding serial numbers, activation codes and the like. If you were tidy and retained the packaging and documentation while knowing where to find them, you were away. However, in these days of software distribution over the web, things are a little less clear-cut. The said codes tend to reside in emails sent following the purchase and, if you are like me, they tend to be scattered around the place; it is not a good thing when you need to get your software reinstalled after a system meltdown, like what I am needing to do. Another trap is that expensive software could disappear all of a sudden if your hard drive crashes, not an enticing thought. A spot of backup of both the installer and product key seems very much in order.

Troubleshooting missing HAL.DLL and boot configuration issues in Windows XP

My PC is very poorly at the moment and Windows XP re-installation is the prescribed course of action. However, I have getting errors reporting missing or damaged HAL.DLL at the first reboot of the system during installation. Because I thought that there might be hard disk confusion, I unplugged all but the Windows boot drive. That only gave me an error about hard drives not being set up properly. Thankfully, a quick outing on Google turned up a few ideas. However, I should really have started with Microsoft, since they have an article on the problem. About.com has also got something to offer on the subject and seems to be a good resource on installing XP to boot: I had forgotten how to do a repair installation and couldn't find the place in the installation menus. In any event, a complete refresh should be a good thing in the long run, even if it will be a very disruptive process. While I did consider moving to Vista at that point, bringing XP back online seemed the quickest route to getting things back together again. Strangely, I feel like a fish out of water right now, but that'll soon change...

Update: It was, in fact, my boot.ini that was causing this and replacement of the existing contents with defaults resolved the problem...

VMware and ZoneAlarm

Contrary to appearances given by this blog, I am not exclusively a Windows user. In fact, I have sampled Linux on a number of occasions in the past and I use VMware to host a number of different distributions – my Ubuntu installation is updating itself as I write this – as I like to keep tabs on what is out there. I also retain a Windows 2000 installation for testing, and have had a virtual machine hosting a test release of Vista not so long ago. I also have my finger in the UNIX world with an instance of OpenSolaris, though it is currently off my system thanks to my wrecking its graphics set up. However, ZoneAlarm has been known to get ahead of itself and start blocking VMware. If you go having a look on the web, there is no solution to this beyond a complete system refresh (format the boot drive and reinstall everything again) and I must admit that this sounds like throwing out bath, baby and bathwater together. I did find another approach, though: removing ZoneAlarm and reinstalling it. This wipes all its remembered settings, including the nefarious one that conflicted with VMware in the first place. It's remarkable that no one else has considered this, but it has worked for me, and having to have the security software relearn everything again is much less painless than rebuilding your system.