I previously reported apt-cache-report was not working. In this post I will set about fixing it.
What I discoved is the apt-cacher log format has changed. Old log:
# gzip -dc /var/log/apt-cacher/access.log.6.gz | head -1New log:
Thu Oct 30 22:01:39 2008|192.168.1.12|MISS|189|security.ubuntu.com_ubuntu_dists_hardy-security_Release.gpg
# head -1 /var/log/apt-cacher/access.logSo the new format has an extra column (second column, I have no idea what it is) and rearranged a little. I started in changing /usr/share/apt-cacher/apt-cacher-report.pl to compensate for this. Not that it still needed to be able to parse the old logs, so some logic was involved to distinguish.
Tue Mar 10 01:45:59 2009|19924|127.0.0.1|EXPIRED|189|archive.ubuntu.com_ubuntu_dists_intrepid-updates_Release.gpg
# cd /usr/share/apt-cacher/
# cp apt-cacher-report.pl apt-cacher-report.pl.orig
# vi apt-cacher-report.pl
# diff -c apt-cacher-report.pl.orig apt-cacher-report.pl
*** apt-cacher-report.pl.orig 2009-03-13 15:35:14.000000000 -0500
--- apt-cacher-report.pl 2009-03-13 17:04:45.000000000 -0500
***************
*** 109,121 ****
{
#$logfile_line =~ s/ /\+/g;
@line = split /\|/, $logfile_line;
! $req_date = $line[0];
! # $req_ip = $line[1];
! $req_result = $line[2];
! $req_bytes = 0;
! $req_bytes = $line[3] if $line[3] =~ /^[0-9]+$/;
! # $req_object = $line[4];
!
$lastrecord = $req_date;
if(!$firstrecord) {
$firstrecord = $req_date;
--- 109,133 ----
{
#$logfile_line =~ s/ /\+/g;
@line = split /\|/, $logfile_line;
! if (scalar(@line) == 5)
! {
! # 5 columns == old format
! $req_date = $line[0];
! # $req_ip = $line[1];
! $req_result = $line[2];
! $req_bytes = 0;
! $req_bytes = $line[3] if $line[3] =~ /^[0-9]+$/;
! # $req_object = $line[4];
! } else {
! # Assume new 6 column format
! $req_date = $line[0];
! # I don't know what $line[1] is
! # $req_ip = $line[2];
! $req_result = $line[3];
! $req_bytes = 0;
! $req_bytes = $line[4] if $line[4] =~ /^[0-9]+$/;
! # $req_object = $line[5];
! }
$lastrecord = $req_date;
if(!$firstrecord) {
$firstrecord = $req_date;
Now to test things, by rerunning apt-cacher:
# /etc/cron.daily/apt-cacherAnd then I browsed to http://localhost:3142/report/ and now I see an updated report:
...this takes a while (~5 min)...
summary
Item | Value |
---|---|
Report generated | 2009-03-13 17:04:50 |
Administrator | root@localhost |
First request | Thu Oct 30 22:01:39 2008 |
Last request | Fri Mar 13 16:46:42 2009 |
Total requests | 37119 |
Total traffic | 11.487 GB |
cache efficiency
Cache hits | Cache misses | Total | |
---|---|---|---|
Requests | 24007 (64.67%) | 13112 (35.32%) | 37119 |
Transfers | 8.018 GB (69.8%) | 3.468 GB (30.19%) | 11.487 GB |
If anyone knows where I should submit this patch to, please drop me a comment.
5 comments:
This is an awesome fix! I was wondering why my report was showing 0 cache hits when I could clearly see disk activity on the apt-cacher host.
Thank you!
I have a problem in that I can no longer browse to the apt-cacher reports and I have no idea how to go about finding out what's wrong. Any idea where I could post my problem and get a response?
"http://localhost:3142/report/ and now I see an updated report:"
OH NO! actually I CAN get the reports at localhost but not from my desktop elsewhere on the lan. "http://crunch20:3142/report" gives me a page load error. Same result using the ip instead of the hostname.
@Skip Da Shu: Sounds like a networking or firewall issue. I don't have any better suggestion that http://ubuntuforums.org/
Great work. Thanks for taking the time post your fix.
Post a Comment