SQL SELECT statements have the following form:

SELECT COLUMNS 
FROM TABLES 
[WHERE CONDITIONS] 
[GROUP BY COLUMNS 
[HAVING CONDITIONS]
]   
[ORDER BY COLUMNS ASC|DESC]

The way SQL processes these directives is slightly different:

FROM TABLES
[WHERE CONDITIONS] 
[GROUP BY COLUMNS 
[HAVING CONDITIONS]
] 
[ORDER BY COLUMNS ASC|DESC]
SELECT COLUMNS

FROM Clause

FROM TABLE [AS ALIAS] .. TABLE [AS ALIAS]

This lets SQL know which tables are being used for the query and any aliases they might be referenced as in the query. The aliases are only necessary when an inner join is performed.

Examples

• FROM table1, table2
• FROM table1 as t1, table2 as t2
• FROM table1 as t1a, table1 as t1b

This last example is a join and requires the aliases.

WHERE Clause

WHERE CONDITIONS

This lets SQL know which rows should be selected from the table based on the conditions passed. The conditions can also be combined with the logical or and and operators. (Which should be properly parenthesized to demonstrate priority.)

The following operators can act on columns in a where clause:

• =
• <> (also !=)
• >
• <
• >=
• <=
• BETWEEN
• LIKE
• IN

Examples

• WHERE t1.c1 = “string”
• WHERE t1.c1 = t2.c1 and t1.c2 <> t2.c2
• WHERE t1.c1 = t2.c1 and (t1.c2 <> t2.c2 or t1.c3 <> t2.c3)
• WHERE t1.c1 in (value set)

This last example demonstrates using either an explicit set or a subquery where the subquery returns a list of values that filter this main query.

GROUP BY Clause

GROUP BY COLUMNS

This lets SQL know to group the table for aggregate filtering operations. For example if you need to sort based on the max sales of your sales people you could group by your sales members’ identifiers and then use a HAVING clause to filter based on their max(sales_amount). This clause is only really useful when a HAVING clause is useful.

Multiple GROUP BY columns just restricts the groupings to be tighter and tighter. For example, if you have three columns t1, t2, and t3 and you use a GROUP by t1, t2 you will end up with the following groupings:

-------------------------------------------------------------------------------
t1 and t2 are all the same in this group; t3 varies
-------------------------------------------------------------------------------
t1 and t2 are all the same in this group; t3 varies
-------------------------------------------------------------------------------

Examples

• GROUP BY c1, c2
• GROUP BY c1

HAVING Clause

HAVING CONDITIONS

This is very similar to the WHERE clause and the logical operators and and or can be used as in the WHERE clause. The difference here is that typically you’ll be filtering based on an aggregate operation on an ungrouped column to filter out groups.

Examples

• HAVING max(t3) > n
• HAVING average(t3) between x and y

ORDER BY Clause

ORDER BY COLUMNS ASC|DESC

This lets SQL know you want to sort the specified columns ascending or descending. The sorting will be applied to the columns in the order that they are specified. Thus it works similar to the way groups work it makes groups out of the first specification and then the second and so on. Performing the new operation only within the context of the previous. Thus the following data would be sorted as shown:

Before Sorting:

----------------
| c1 | c2 | c3 |
----------------
| aa | aa | aa |
| bb | bb | bb |
| aa | dd | ee |
| cc | cc | cc |
| aa | bb | cc |
----------------

After Sorting (ORDER BY c1, c2, c3):

----------------
| c1 | c2 | c3 |
----------------
| aa | aa | aa |
| aa | bb | cc |
| aa | dd | ee |
| bb | bb | bb |
| cc | cc | cc |
----------------

Examples

• ORDER BY c1
• ORDER BY c1, c2, c3

SELECT Clause

SELECT COLUMNS

This lets SQL know which columns (or what projection) of the table to actually display. One can also specify aggregate functions here to perform functions such as counting, averaging, etc.

Examples

• SELECT col1, col2
• SELECT col1, t1.col2
• SELECT COUNT(col1)

Conclusion

Remember that SQL SELECT statements are not processed in the order that they are parsed. This will simplify the query building process to think of it as operations on a set of data (since that is what it is). The steps are as follows:

1 Select the set to act on.
2 Filter out elements from the set. 3 Group the remaining elements. 4 Filter out groups of elements. 5 Sort the elements. 6 Get the projection of the elements’ attributes.

All of this somehow translates to the SQL SELECT statement syntax we started this discussion with:

SELECT COLUMNS 
FROM TABLES 
[WHERE CONDITIONS] 
[GROUP BY COLUMNS 
[HAVING CONDITIONS]
]   
[ORDER BY COLUMNS ASC|DESC]

References

• MySQL Manual

I was recently tasked with working on getting PHP 5.3 installed with Gearman on CentOS 5.5. I’ve learned quite a few of the pains of working with RPMs and have reminded myself why I don’t work with RHEL on a regular basis (for personal items anyway). I have had some success in getting everything working correctly and the following is the quick easy way to get this done on an x86_64 CentOS 5.5 install (although other RHELs should work as well.

Upgrade PHP

First, we need to upgrade PHP from the IUS Community Repository. Once you have the epel and ius repositories installed and working you simply:

yum remove php
yum install php53

If the second yum command complains simply remove all php packages listed form `rpm -qa | grep ^php’ and install the php53 equivalents.

Install Gearman

I recompiled the Fedora source RPMs (with a slightly modified spec file) to get Gearman to play nicely with the CentOS 5.5 environment. These RPMs are available in my repository. Simply install these RPMs (letting me know if there are any issues with them) and you should be ready to install the PHP Gearman Interface.

Install php-gearman

This is the easiest part of all once you have the requirements fulfilled. Simply pear install channel://pecl.php.net/gearman-0.7.0 and you’re finished.

Conclusion

If you must use RHEL this guide should help you get gearman running with PHP in a snap.

There is a new king of backups in town, holland. This little framework written in Python allows one to easily backup anything that might need to be converted to a more flat file style before being backed up. Right now there is support for mysql, sqlite, and postgresql but with a little finesse it could potentially support directories as well as databases. This would make not only mysql backups a breeze but LDAP as well.

Progress Update

I have added a preliminary set of ebuilds to my overlay (which could use some code review if anyone is interested) that allows holland to easily be installed on Gentoo systems. So easy in fact that all it takes is emerge holland.

It accepts a set of use flags to bring in the “providers” you want to be able to backup for and makes sure that those packages are installed on the system.

Examples

The holland ebuilds have three providers right now:

• mysql
• postgresql
• sqlite

You can install any of these three you want in any combination it doesn’t care. It will default to installing the mysql but can easily be told not to by placing -mysql in the use flags for holland. Diego Pettenò — Flameeyes mentioned to me that in EAPI 4 we’ll get the cool option of being able to specify one of a set of use flags must be set without forcing the choice but until then we have this slick solution.

There is also lvm support for snapshotting off the database directory before grabbing the database and a myriad of other features I haven’t had a chance to explore yet.

To perform a rudimentary backup after installing holland simply run holland bk. This will read the configurations in /etc/holland and backup the databases it finds.

Conclusion

The new kid on the block, holland, will make backups of complex databases and directories a breeze. Simply change that cronjob from using mysqldump to calling holland and you’re finished.

Backups, a subject always talked about but rarely put into practice. If you do happen to have a backup solution, excellent, you probably sleep better than our comrades without a recovery plan. I’ve been using bacula for my backup solution for over a year now and one thing I’ve never had enough experience with has been upgrading bacula. The upgrade process can be pretty hairy depending your distribution, level of investment, etc.

Bacula Updates

Recently bacula-5.0.2-r1 was marked as stable for the Gentoo distribution. Upon finishing the emerge (laugh if you like at my compilation of all packages), I attempted the restart of all bacula services to bring the new version live:

/etc/init.d/bacula-sd restart
/etc/init.d/bacula-fd restart
/etc/init.d/bacula-dir restart

All went well until I did the restart on the director (bacula-dir). At that point things took a nasty turn for the worse. The director didn’t want to start and there were no messages on the screen indicating why this might be the case.

Long story short: the database needed some schema changes to be applied before the director could start up and get running again. In order to determine this I needed to run: bacula -u root -g bacula -c /etc/bacula/bacula-dir.conf -fvm. Once I ran this I got some meaningful output that told me I needed to update the database a couple of versions. It’s important to know which versions you are dealing with as you have to run each update to the database individually.

First, a dump of all databases that are relevant is a good idea: mysqldump -A -p > backup.sql. Then, we can move onto updating the databases knowing full well that if something goes awry we simply import our backup and revert bacula to the old version.

The database update scripts were located in /usr/libexec/bacula/updatedb/ and when run in the correct order will get you back up and running in short order. When all is said and done utter the /etc/init.d/bacula-dir and your installation should whir to life once again.

Conclusion

When updating bacula don’t forget the catalog database may have changes that require it to be updated using the various bacula updatedb scripts. Backups should commence at their regularly scheduled time.

Bluetooth is a convenience that shouldn’t be underestimated. Bluetooth has invaded pretty much every peripheral device we’ve come to know and love: mice, keyboards, ad-hoc networks, etc. One of the most convenient aspects of bluetooth is the ability to browse filesystems through a simple ad-hoc network connection from a phone or other peripheral device.

Enter Blueman

Blueman is my current preferred bluetooth management utility but others do exist including (gnome-bluetooth and kbluetooth). I have found the configurability and freedom of blueman to give me a bit more flexibility than the other solutions.

The problem with blueman under KDE is that first and foremost blueman is a gnome application. Now this isn’t inherently bad but it makes interoperability a little trickier than if I used kbluetooth (which of course hooks directly into KDE). The first issue (and pretty much only issue so far) is that blueman expects you to use nautilus to browse files on a remote device. Again, not bad but I don’t have nautilus so it’s a little tricky to see those files.

Blueman Transfer Settings

What we see in the image above is that we can modify the obex ftp browser that is used by blueman. We’re going to change this to a custom script (shown below) that uses a FUSE obexfs and dolphin to achieve our desired behavior, browsing our bluetooth file with dolphin.

#!/bin/bash
# bluemount.sh

obexfs -b $1  ~/.bluemnt 
dolphin ~/.bluemnt --nofork
fusermount -u ~/.bluemnt

This script requires obexfs, fuse and of course dolphin to work properly. What the script does is mounts the bluetooth file system to a location that we can actually browse (I arbitrarily chose ~/.bluemnt and you can choose another directory if you like). The argument we get from blueman, $1, is the device id that obexfs expects in order to mount our filesystem (very convenient). Once the filesystem is mounted we simply tell dolphin to open that directory but stay in the foreground so we can properly unmount the device when we finish.

Conclusion

Integrating blueman with KDE can seem daunting but a few hooks and scripts allows the two to inter-operate with ease. Now we can simply open our device list and click the browse button to get dolphin to show our files on the bluetooth device in question.

Memcached is a simple key/value memory store that allows values from pretty much any application to be stored in memory for quick retrieval. Most languages have simple APIs that make this very easy from a programming standpoint. This also means that it’s not quite as simple to configure as APC (but nearly for modern applications).

Installation and Configuration

To install memcached I recommend using your choice of installation (mine being emerge) and then checking the configuration (again in the case of Gentoo) located at /etc/conf.d/memcached.

Update the file to listen on the interface you want, use the memory you want, etc and then start the daemon up. Now if you’re using memcached on the same server as your apache server most webapps will be able to just turn on memcached and connect and work but if you’re using memcached and apache on separate servers it’s a little more work.

WordPress and memcached

I’ve already touted the wordpress plugin: W3 Total Cache but unfortunately this plugin doesn’t allow you to easily configure memcached usage through the web interface. It defaults to using the memcached server located at 127.0.0.1:11211 which if we’re using separate servers is less than ideal. The file we need to modify with a simply sed (or by hand if you prefer knowing what’s going on) is %{DOCROOT}/wp-content/w3-total-cache-config.php.

We just need to change the memcached servers to point at our server’s location before enabling it in the interface. To easily accomplish this we can use sed:

sed -i -e 's/127.0.0.1:11211/<host>:<port>/g' %{DOCROOT}/wp-content/w3-total-cache-config.php

Mediawiki and memcached

The other application we can easily setup for memcached is mediawiki. Mediawiki wants us to modify its LocalSettings.php with the following additions:

## Shared memory settings 
$wgMainCacheType = CACHE_MEMCACHED; 
$wgParserCacheType = CACHE_MEMCACHED; 
$wgMessageCacheType = CACHE_MEMCACHED; 
$wgMemCachedServers = array("giskard.alunduil.com:11211"); 

$wgSessionsInMemcached = true; 

These settings simply turn on memcached (CACHE_MEMCACHED) for the various caching areas that mediawiki uses and specifies an array of memcached servers to store that caching information in.

If you do have more than one memcached server configured and available you can use the following syntax to include all of them with various weights:

$wgMemCachedServers = array(array("host:port", weight), array("host2:port2", weight));

Conclusion

Using memcached can greatly improve the performance of webapps or other applications that don’t need to present the most up to date information. This can reduce traffic to an overloaded database or configuration file or whatever other store you want to place a cache in front of.

We all know that backups are awesome … until we try to find the time to set them up or the space to store them on. We all know that without backups we may see that day when we boot up our computer and our data isn’t there for whatever reason. How can we simplify backups and more importantly initiate them client side?

rdiff-backup

The backup utility that I use to accomplish backing up roaming clients is rdiff-backup. This simple python wrapper for rsync simplifies keeping incremental backups and backup sets for a historical set of backups. By default rdiff-backup is pretty versatile and its documentation is fairly extensive.

What they don’t mention is how to automate these backups with an ssh key to a remote system and a cron job as a scheduler.

The cron job

The cron job is very very simple and highly adaptable:

/usr/bin/rdiff-backup --remote-schema 'ssh -i /home/alunduil/.ssh/backup_dsa %s rdiff-backup --server' --exclude-other-filesystems --print-statistics /home/alunduil daneel.alunduil.com::elijah-backup && /usr/bin/rdiff-backup --remote-schema 'ssh -i /home/alunduil/.ssh/backup_dsa %s rdiff-backup --server' --remove-older-than 7D --force daneel.alunduil.com::elijah-backup

Now let’s break this down so you can make it yours:

• /usr/bin/rdiff-backup – Our script of course.
• –remote-schema – The trick that makes it work. This actually allows you to specify the way ssh is called by rdiff-backup allowing a lot of control over how it authenticates and what happens on the server.
• –exclude-other-filesystems – Specifies to stay on the mountpoint it started on.
• –print-statistics – Prints some nice information about the backup when it finishes.
• /home/alunduil daneel.alunduil.com::elijah-backup – The source and destination of the backup.
• && – Just making sure we don’t delete old backups without having a good one (trust me you want it this way).
• –remove-older-than 7D –force – Force the removal of any backups that are older than one week.

Conclusion

Creating a backup of a roaming client should be easy and with rdiff-backup with cron it certainly is. You have complete control over when and where your backups reside and it can be set to run on boot or any other condition. This is ideal for hosts that don’t always have an internet connection or who have uptimes of less than 50%.

Making PHP run faster is usually pretty easy when you see some of the code that people can write (myself included) but what if we either don’t want to look at their code or don’t want to fix the code? What else can we do to improve the runtime and the load time of PHP web sites (this website included)?

We’ll cover how to use APC (Alternative PHP Cache) to help alleviate some of the issues of a slow web site. Just like last time we optimized MySQL and talked about optimizing Apache we’ll continue on the path to getting PHP applications as fast as we can (without touching a line of code).

Enter APC

APC is PEAR project and a PHP module that after installed and a restart of Apache is already doing some work to make life better. By default APC turns on op-code caching which saves on the compile and execution times of PHP. The configuration for this module is pretty straight forward but let’s look at a copy of the one I’m using:

; /etc/php/apache2-php5/ext-active/apc.ini (On Gentoo anyways ...)
extension=apc.so
apc.enabled="1"
apc.shm_segments="4"
apc.shm_size="128"
apc.num_files_hint="1024"
apc.ttl="7200"
apc.user_ttl="7200"
apc.gc_ttl="3600"
apc.cache_by_default="1"
;apc.filters=""
;apc.mmap_file_mask="/tmp/apcphp5.XXXXXX"
apc.slam_defense="0"
apc.file_update_protection="2"
apc.enable_cli="0"
apc.max_file_size="1M"
apc.stat="1"
apc.write_lock="1"
apc.report_autofilter="0"
apc.include_once_override="0"
apc.rfc1867="0"
apc.rfc1867_prefix="upload_"
apc.rfc1867_name="APC_UPLOAD_PROGRESS"
apc.rfc1867_freq="0"
apc.localcache="0"
apc.localcache.size="512"
apc.coredump_unmap="0"

Zooming In

These options are documented fairly thoroughly in the APC PHP Manual.

Most of these options can stay at their defaults and provide a pleasant experience but if we have the memory we should probably tweak these to get more out of them: * apc.shm_segments – The number of chunks to use from /dev/shm. * apc.shm_size – The size of aforementioned chunks.

These two parameters are the heart of APC and dictate the memory usage you’ll get out of it. If you take segments*size you’ll get the maximum amount of shm space used by APC for the cache. A limitation on shm_size is usually in place through the kernel and to determine what this is you can simply cat /proc/sys/kernel/shmmax (remember this command prints out B and APC expects MB).

Further Caching

APC also has an object cache available which can be used for just about anything but the application has to be modified to support this. If you’re using WordPress to host your site an excellent plugin for doing this is W3 Total Cache.

Conclusion

APC can help you get an edge out of your server but without careful tuning won’t get you more than the last inch of performance. Play with the memory settings until it isn’t over-utilizing memory (have a larger cache than your code base needs) or under-utilizing memory (having a smaller cache than your code base needs) but don’t forget you don’t want it to run into your swap space.

First things first …

A few common things to possibly turn on, install, or enable:

• APC (Another PHP Cache)
• Memcached

MySQL Optimization

The easiest way (and the quickest) to determine what can be done to optimize MySQL is to use a script called mysqltuner.pl. The really interesting thing about this script is that to get it you simply run the following:

wget mysqltuner.pl

After you’ve gotten this script run it with your perl interpreter:

perl mysqltuner.pl

It will prompt you for your username and password for mysql and then print out a nice report outlining how your mysql daemon has been running. Here’s an example of this output:

 >>  MySQLTuner 1.0.1 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password: 

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.90-log
[OK] Operating on 32-bit architecture with less than 2GB RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster 
[--] Data in MyISAM tables: 28M (Tables: 96)
[--] Data in InnoDB tables: 1M (Tables: 55)
[!!] Total fragmented tables: 2

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1h 39m 49s (24K q [4.163 qps], 354 conn, TX: 9M, RX: 34M)
[--] Reads / Writes: 60% / 40%
[--] Total buffers: 148.6M global + 960.0K per thread (100 max threads)
[OK] Maximum possible memory usage: 242.3M (11% of installed RAM)
[OK] Slow queries: 0% (0/24K)
[OK] Highest usage of available connections: 28% (28/100)
[OK] Key buffer size / total MyISAM indexes: 64.0K/6.3M
[OK] Key buffer hit rate: 99.6% (164K cached / 682 reads)
[OK] Query cache efficiency: 81.3% (14K cached / 17K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 463 sorts)
[!!] Joins performed without indexes: 42
[OK] Temporary tables created on disk: 12% (54 on disk / 417 total)
[OK] Thread cache hit rate: 70% (106 created / 354 connections)
[!!] Table cache hit rate: 2% (48 open / 2K opened)
[OK] Open file limit used: 9% (95/1K)
[OK] Table locks acquired immediately: 98% (7K immediate / 7K locks)
[!!] Connections aborted: 7%
[OK] InnoDB data size / buffer pool: 1.0M/4.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Adjust your join queries to always utilize indexes
    Increase table_cache gradually to avoid file descriptor limits
    Your applications are not closing MySQL connections properly
Variables to adjust:
    join_buffer_size (> 128.0K, or always use indexes with joins)
    table_cache (> 48)

The first thing to notice is that mysql should be running for 24 to 48 hours before you trust the results of this script the second thing to acknowledge is that it isn’t omniscient. Understanding how these parameters affect your memory footprint and your runtime efficiency are what we’re most interested in though.

Glossary of Parameters

The best source of my.cnf parameters is of course the MySQL documentation but I’ll clarify a few of the more pertinent items from the above output.

• Maximum Possible Memory – This is not the actual hard limit on your memory usage but a calculated theoretical maximum based on the parameters in your my.cnf and if this is over ~90% you may use your swap more than you want to. After making any changes I suggest you check this to make sure you haven’t over-allocated yourself.
• Highest Usage of Available Connections – This is the historical max connections used by mysql and if it’s at 100% this isn’t a guarantee that you need to increase max_connections but may just indicate that your connections spiked once. That being said I recommend following its advice if you have the memory for it.
• Query Cache Efficiency – The hit rate for the cache on your queries (I hope you have enabled). As with any hash table if you’re not hitting what’s in the top bucket you need to increase the number of buckets.
• Temporary Tables Created on Disk – This can be a finicky parameter to get right and is the first place I would recommend cutting if you don’t have the memory to run mysql like you would want, but if you do have the memory then up this as far as you can within reason.
• Thread Cache Hit Rate – Just like any other cache.
• Table Cache Hit Rate – Just like any other cache.

Fragmented Tables

If you noticed the fragmented tables along with the recommendation to run OPTIMIZE TABLE that’s not something that will typically slow mysql down noticeably with today’s disks but if you want to defragment them I recommend reading this article on the topic.

Apache Tweaking

The following parameters are usually in httpd.conf unless you run a distribution that organizes apache in an easier to work with manner (my preference of course is Gentoo which stores these parameters in: 00_mpm.conf).

The parameters for tweaking apache’s processes depend on which worker module you have in use. The following is the pertinent sections from my configuration:

# prefork MPM
# This is the default MPM if USE=-threads
#
# MinSpareServers: Minimum number of idle child server processes
# MaxSpareServers: Maximum number of idle child server processes
<IfModule mpm_prefork_module>
        StartServers            5
        MinSpareServers         5
        MaxSpareServers         10
        MaxClients                      50
        MaxRequestsPerChild     500
</IfModule>

# worker MPM
# This is the default MPM if USE=threads
#
# MinSpareThreads: Minimum number of idle threads available to handle request spikes
# MaxSpareThreads: Maximum number of idle threads
# ThreadsPerChild: Number of threads created by each child process
<IfModule mpm_worker_module>
        StartServers            2
        MinSpareThreads         15
        MaxSpareThreads         50
        ThreadsPerChild         25
        MaxClients                      150
        MaxRequestsPerChild     1000
</IfModule>

These parameters are pretty self explanatory but just for completeness’ sake I’ll do a small recap on these here:

• StartServers – The number of servers to have running and handling connections at first launch.
• MinSpareServers – The minimum number of servers to have running not currently handling connections.
• MaxSpareServers – The maximum number of servers to have running not currently handling connections.
• MaxClients – The maximum number of clients that can simultaneously connect to Apache.
• MaxRequestsPerChild – The maximum number of requests that a child will respond to before terminating.

Using these parameters we can control the amount of memory that Apache will consume at the cost of other things we may want to have like lots of connections or many sequential requests.

Conclusion

There are a lot of different things that can be done for a server that seems to be performing less than ideally and I’ve only covered a fraction of things that can happen. As always with this topic the situation will change based on your needs and how your server runs but at least now you may have a starting point for what to modify after you’ve troubleshooted every other thing that could go wrong.

I’m assuming for this quick guide that you already have a website installed and consequently apache.

emerge -av awstats

A quick breakdown on the use flags from gentookit’s equery:

• apache2 : Add Apache2 support
• geoip : Add geoip support for country and city lookup based on IPs
• vhosts : Adds support for installing web-based applications into a virtual-hosting environment

Configuration

Lots of configuration needs to occur for awstats to work correctly:

First, we need to setup a configuration file for the web site so we can update the statistics. cp /etc/awstats/awstats.model.conf /etc/awstats/awstats..conf

Where fqdn is the fully qualified domain name of your website you’ll be monitoriing. After you’ve copied the default configuration customize it for your particular website.

Second, you need to enable awstats in your apache vhost configuration:

CustomLog /var/www/localhost/log/apache/production.log combined

Alias /awstats/classes "/usr/share/webapps/awstats/6.9-r1/htdocs/classes/"
Alias /awstats/css "/usr/share/webapps/awstats/6.9-r1/htdocs/css/"
Alias /awstats/icons "/usr/share/webapps/awstats/6.9-r1/htdocs/icon/"
ScriptAlias /awstats/ "/usr/share/webapps/awstats/6.9-r1/hostroot/cgi-bin/"
ScriptAlias /awstats "/usr/share/webapps/awstats/6.9-r1/hostroot/cgi-bin/awstats.pl"
ScriptAlias /awstats.pl "/usr/share/webapps/awstats/6.9-r1/hostroot/cgi-bin/awstats.pl"

<Directory "/usr/share/webapps/awstats/6.9-r1/htdocs">
   Options None
   AllowOverride None
   <IfModule mod_access.c>
       Order allow,deny
       Allow from all
   </IfModule>
</Directory>

<Directory "/usr/share/webapps/awstats/6.9-r1/hostroot/cgi-bin">
    Options ExecCGI
    AllowOverride None
    <IfModule mod_access.c>
        Order allow,deny
        Allow from all
    </IfModule>
</Directory>

<Directory "/usr/share/webapps/awstats/6.9-r1/hostroot">
    Options None
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

<Directory "/usr/share/webapps/awstats/6.9-r1/htdocs/icon">
    Options None
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

And verify the logging output in /etc/apache2/modules.d/00_mod_log_config.conf:

<IfModule log_config_module>
    # The following directives define some format nicknames for use with
    # a CustomLog directive (see below).
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common

    LogFormat "%{Referer}i -> %U" referer
    LogFormat "%{User-Agent}i" agent
    LogFormat "%v %h %l %u %t \"%r\" %>s %b %T" script
    LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" VLOG=%{VLOG}e" vhost

    <IfModule logio_module>
        # You need to enable mod_logio.c to use %I and %O
        LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
        LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" vhostio
    </IfModule>

    # The location and format of the access logfile (Common Logfile Format).
    # If you do not define any access logfiles within a <VirtualHost>
    # container, they will be logged here.  Contrariwise, if you *do*
    # define per-<VirtualHost> access logfiles, transactions will be
    # logged therein and *not* in this file.
    CustomLog /var/log/apache2/access_log common

    # If you would like to have agent and referer logfiles,
    # uncomment the following directives.
    #CustomLog /var/log/apache2/referer_log referer
    #CustomLog /var/log/apache2/agent_logs agent

    # If you prefer a logfile with access, agent, and referer information
    # (Combined Logfile Format) you can use the following directive.
    #CustomLog /var/log/apache2/access_log combined
</IfModule>

And Lastly, you need to add a cron entry to update the statistics on a regular basis: # AWStats */15 * * * * perl /usr/share/webapps/awstats/6.9-r1/hostroot/cgi-bin/awstats.pl -config=www.alunduil.com -update > /dev/null

Everything should be running smoothly but give your installation some time to begin collecting statistics.