I mentioned a week or so ago that I would be having another article published in the near future. I’m happy to announce that the article is now available. I hope you’ll take a few minutes and head over to have a read. If you have any comments, or suggestions on accuracy or improvements please do let me know and I’ll update where necessary.
I know I haven’t been blogging much lately. I’ve been occupied with other responsibilities. Besides work and school I’ve been dedicating a lot of time volunteering on the GNOME Sysadmin team, trying to make sure that it remains a well-oiled development machine! I had a few minutes this evening however and I thought I would give you a heads up on an article I’m waiting to have published.
As some of you know, I have been writing off and on for Packt Publishing‘s online Article Network. I’ve covered a number of Ubuntu related topics such as: “What’s New in Ubuntu 9.10“, “Network Based Ubuntu Installations“, “Ubuntu 9.10: How to Upgrade“, “Creating Local Ubuntu Repositories“, “Five Years of Ubuntu“, “Ubuntu User Interface Tweaks“, “Install GNOME-Shell on Ubuntu 9.10“, “Securely Encrypting Removable Media“, and “Folding @ Home on Ubuntu“.
My latest article, which should be published this week sometime, is a quick-install guide to Ubuntu Server 10.04 toward the goal of a “LAMP” web-server. The article includes screenshots for installing Ubuntu Server, installing the Apache, MySQL and PHP components, and installing a WordPress installation, managed by subversion. It probably sounds like there is quite a bit to it, doesn’t it?
The best part of the article is that you can go from zero to WordPress in fifteen minutes! I’ve timed it. Twice. I setup a virtual machine and by following these instructions I can go from no operating system to a working WordPress installation in under fifteen minutes. It’s really quite amazing! Ubuntu Server is so user friendly, and they’ve put in enough attention to the little details, that really anyone can set up a web server and start publishing content in no time!
I have a follow-up article in the works (still a few weeks out, at least) which outlines expanding your web server to include SSL, virtual hosts (multiple sites), managing and upgrading your WordPress engine using subversion, and more.
I’ll post links when both of these publish. Until then…
Christer
I just read an article over at Dustin Kirkland’s blog regarding the enormous server farm that Weta Digital has setup to render blockbuster movies. Apparently the latest Blockbuster, Avatar, had scenes rendered using a 35,000 core Ubuntu-based server farm. 35,000! That is hard to imagine! They’ve also rendered a few other films you may have heard of:
It is amazing to think that in just a few short years Ubuntu has gained such a reputation that it would be used for such high-end commercial services.
A few years ago I did a talk at a local conference regarding Ubuntu in the Enterprise. Sadly, at the time, it was very hard to find any real solid documentation regarding large businesses using Ubuntu day-to-day. Sure it had crept onto some corporate desktops, but it was very hard to find it elsewhere. Now, we have stories like this and I’m sure this is just the tip of the iceberg!
What other companies do you know that run Ubuntu in production? I’m sure many of us would be interested to find out where else it is being used.
(Note: more details and links regarding Weta Digital and the source of this data at Dustin’s blog.)
This is the last of my servers / desktops / laptops that is not yet running Ubuntu 8.04 “Hardy”. In my testing on non-production machines and semi-production machines the upgrades have worked absolutely perfectly. I wanted to post an announcement / warning that I would be upgrading this server to Ubuntu 8.04 at some point today. I’ll post on the progress. Heads up however. If the blog manages to disappear altogether you’ll know what happened 
The other day I thought I’d give the Ubuntu 6.06 LTS to 8.04 LTS direct upgrade path a try on my Ubuntu 6.06 server. It ran smoothly (over ssh no less), until I ran into one bug at the end. I reported it, with a reply back the next day. Two days later it has been fixed and I tried an upgrade again. I’m happy to say that the direct upgrade path worked perfectly on a fresh install of Ubuntu 6.06 Server. Here is how I did it:
Ubuntu 6.06 to Ubuntu 8.04 Upgrade (Server)
I verified that my current install was completely up to date:
sudo aptitude update
sudo aptitude upgrade
sudo aptitude dist-upgrade
Also, to be thorough, this is what my sources.list looked like (each ‘deb’ entry should be one single line):
deb http://archive.ubuntu.com/ubuntu dapper main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu dapper-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu dapper-security main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu dapper-proposed main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu dapper-backports main restricted universe multiverse
Once I had applied all updates (if you’re already up to date, you don’t need a reboot) I then installed the server-based update utility:
sudo aptitude install update-manager-core
Once this is installed you’re ready to begin the upgrade process. You can start the upgrade using:
sudo do-release-upgrade -d
note: once Ubuntu 8.04 final is released the -d option will no longer be needed.
At this point it’ll do some checking, verify and update the newer repository and ask you a few questions along the lines of “There is no going back from here, are you sure you want to upgrade?” After that its smooth sailing.
If you do run into any issues during the upgrade please report them against the update-manager-core package in Launchpad.
Last nite I sat down and configured AWStats on my Ubuntu 7.10 server. I had previously been using statcounter, a free stat service, but I had noticed that it was one of the causes of slowdown on my page loads. Having to access an external site and javascript wasn’t helping. I also run the server so I have full access to the server logs, why not just use those directly.
So far I am really happy with AWStats. It appears to be running properly and pulling in a lot more data than statcounter ever did. It actually is showing me that I had much more traffic than I thought. I had mentioned 5,000 the other day, which I have long since surpassed based on AWStats output.
I’d like to share the steps I took for installing and configuring AWStats on my Ubuntu Server.
Installation
Ubuntu has the AWStats package available in the repositories, which we can install with:
sudo aptitude install awstats
This will install the basic files, but there is still a bit of configuring to do, so we’ll dive into that next.
Auto Configuration
From the tutorials that I found elsewhere in my searching there is a awstats_configure.pl file that will try to configure it for you. I did not use this personally, but if you’d like to try it you can run:
sudo perl /usr/share/doc/awstats/examples/awstats_configure.pl
The rest of this tutorial will discuss manual configuration, but if anyone can offer feedback concerning the configure script I’m sure many would be interested.
Manual Configuration
I configured my system manually, which I will outline below. The only requirements here are that you have access to the apache2 logs, or that you have custom log locations for each of your virtual domains (if used). For more information on custom log locations for virtual domains see my previous post, Configuring Virtual Hosting on Ubuntu with Apache2.
The first step is creating an awstats.conf file for your domain. This can be done by moving or copying the /etc/awstats.conf, and giving it a more unique name:
sudo cp /etc/awstats/awstats.conf /etc/awstats/awstats.domain.tld.conf
I created a unique file, using the syntax awstats + domain.tld + conf for each of the domains hosted on my server. Each of these also has their own unique log file as well.
We’ll then edit our new /etc/awstats with custom values for that domain. The main points you’ll want to look for within this file:
Once you’ve made these changes you’ll want to build your initial statistics, which will be generated from the current logs on your machine. We can do this using:
sudo /usr/lib/cgi-bin/awstats.pl -config=domain.tld -update
What this will do is scan the /etc/awstats folder for anything of the pattern awstats + domain.tld + conf, reading that config to generate its output. You should see some output here, and depending on the size of your logs it’ll take anywhere from a few seconds to a few minutes or hours. Each time it is run after that will be minimal, as it only updates the information, but the initial generation can take some time.
Configure Apache to Display AWStats
At this point our statistics should be generated (if not, go back and double check you haven’t missed anything!), but we need a way to see them. We’ll need to configure Apache2 to show us these stats. The way I did this was by using an Include in my apache2.conf, instead of cluttering up the default config file. This is generally my preferred method.
Apache2.conf already has a line near the botton Include /etc/apache2/conf.d/, which will read anything in there as additional data. What I did was create a new file in the /etc/apache2/conf.d/ directory called awstats, and filled it with the following content:
Alias /awstatsclasses "/usr/share/awstats/lib/"
Alias /awstats-icon/ "/usr/share/awstats/icon/"
Alias /awstatscss "/usr/share/doc/awstats/examples/css"
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
ScriptAlias /awstats/ /usr/lib/cgi-bin/
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
This is basically creating some access aliases, and defining the cgi-bin paths, etc. Once this is saved you should be able to restart Apache2 and we’ll should be able to access our stats. Restart Apache2 using:
sudo /etc/init.d/apache2 restart
You should now be able to access your statistics using:
http://domain.tld/awstats/awstats.pl
Assuming you didn’t get any errors during your stats generation, and Apache2 didn’t complain when you restarted the service, you should see statistics at this point.
Continually Updating Your Stats
The last thing you’ll probably want to do is update your statistics via cron. This will allow you to have your site statistics updated on a regular basis, not requiring intervention on your part. What I have done is added a line to my /etc/crontab file telling AWStats to update every ten minutes. I have seen minimal system load even when updating a dozen sites on that interval. To update every ten minutes we’ll add the following line:
*/10 * * * * root /usr/lib/cgi-bin/awstats.pl -config=domain.tld -update >/dev/null
Repeat this line, updating the domain.tld value for any site you want continually updated.
Securing Statistics
If you’d like to make your statistics private you might be interested in one of my previous posts, Limiting Access To Websites & Directories with .htaccess.