Update accelerator DLSOURCE

1

Hi,

I have noticed that the update accelerator has not been getting any UPDCACHE results.
I have updated several computers and can see the files being downloaded and then when I do the next computer it just registers DLSOURCE and doesn’t get anything from the cached update accelerator system.

The cache files should be there as I am doing the same upgrades for each computer.

I have noticed this since the last 2 core updates 143 and 144. I don’t if that is related or not.

I have just noticed that the Microsoft files ARE coming from the cache. It looks like it is only affecting the Linux deb files.

Is anyone else seeing this behaviour?

Here is the Linux update log:
587809281 192.168.0.165/192.168.0.165 - Linux DLSOURCE http://au.archive.ubuntu.com/ubuntu/pool/universe/n/node-asap/node-asap_2.0.6-2_all.deb
1587809282 192.168.0.165/192.168.0.165 - Linux DLSOURCE http://au.archive.ubuntu.com/ubuntu/pool/universe/n/node-asn1/node-asn1_0.2.3-2_all.deb
1587809282 192.168.0.165/192.168.0.165 - Linux DLSOURCE http://au.archive.ubuntu.com/ubuntu/pool/universe/n/node-assert-plus/node-assert-plus_1.0.0-2_all.deb
1587809282 192.168.0.165/192.168.0.165 - Linux DLSOURCE http://au.archive.ubuntu.com/ubuntu/pool/universe/n/node-asynckit/node-asynckit_0.4.0-3_all.deb
1587809282 192.168.0.165/192.168.0.165 - Linux DLSOURCE http://au.archive.ubuntu.com/ubuntu/pool/universe/n/node-aws-sign2/node-aws-sign2_0.7.1-2_all.deb

Here is the Microsoft update log:
1587812209 192.168.0.60/192.168.0.60 - microsoft DLSOURCE http://11.au.download.windowsupdate.com/d/msdownload/update/software/defu/2020/04/am_delta_patch_1.313.2244.0_e3d60e9c14dc3d4b7a8939294af699a4369c6f76.exe
1587812209 192.168.0.60/192.168.0.60 - Microsoft UPDCACHE http://11.au.download.windowsupdate.com/d/msdownload/update/software/defu/2020/04/am_delta_patch_1.313.2244.0_e3d60e9c14dc3d4b7a8939294af699a4369c6f76.exe
1587812210 192.168.0.60/192.168.0.60 - microsoft UPDCACHE http://11.au.download.windowsupdate.com/d/msdownload/update/software/defu/2020/04/am_delta_patch_1.313.2244.0_e3d60e9c14dc3d4b7a8939294af699a4369c6f76.exe
1587812210 192.168.0.60/192.168.0.60 - Microsoft UPDCACHE http://11.au.download.windowsupdate.com/d/msdownload/update/software/defu/2020/04/am_delta_patch_1.313.2244.0_e3d60e9c14dc3d4b7a8939294af699a4369c6f76.exe

Basically the Microsoft files are working as designed but the Linux deb files are not working any more.

Thanks

2

First look at your logs shows, the debian files are different ( in filename ).

3

What do you mean different?
They end in .deb and I think they always did.

It used to work.

I can’t work out why it’s not working.

4

I am upgrading to Ubuntu 20.04 and usually I do one computer then when I do any others it is quicker because it pulls the files from the update accelerator.
This is not happening now.

I noticed because I used a lot of data in one day. Usually the data usage is small because the accelerator was working.

So I don’t know if Ubuntu has changed or ipfire has changed.

Has anyone else had this issue?

My ipfire is not an install from scratch it has been upgraded.

Thanks

5

OK There is definitely a problem. The date of the file is set to Jan 1 1970 that’s why it is downloaded every time as it is OUT OF DATE :grin:

Below is an example of directory files.

rw-rw-r-- 1 squid squid 11 Apr 26 13:24 access.log
-rw-rw-r-- 1 squid squid 11 Apr 26 13:24 checkup.log
-rw-rw-r-- 1 squid squid 70768 Jan 1 1970 netplan.io_0.99-0ubuntu2_amd64.deb
-rw-rw-r-- 1 squid squid 94 Apr 26 13:24 source.url
-rw-rw-r-- 1 squid squid 2 Apr 26 13:24 status

I built a new install of ipfire 144

I created a virtual 20.04 server and snap shoted it then did sudo apt install meld

I let the update accelerator download the files.

I restored the snap shot and redid the sudo apt install meld

The cache log showed DLSOURCE

Then I looked in the directories of the files and saw the 1970 date.

It used to work so something has changed.

I am NOT a programmer so hopefully someone will see this and know what has happened.

6

I have enabled debug and below is what I have seen:
020-04-26 14:56:55 [16577] [updxlrator] Vendor ID is linux
2020-04-26 14:56:55 [16577] [updxlrator] UUID is 1fe13c55-a869-6468-f8a8-382d023f37dc
2020-04-26 14:56:56 [16577] [updxlrator] Local filesize: 981380
2020-04-26 14:56:56 [16577] [updxlrator] Local timestamp: 0
2020-04-26 14:56:56 [16577] [updxlrator] Remote filesize: 0
2020-04-26 14:56:56 [16577] [updxlrator] Remote timestamp: 0
2020-04-26 14:56:56 [16577] [updxlrator] Free disk space: 226558730240
2020-04-26 14:56:56 [16577] [updxlrator] Disk usage: 25% (max. 95%)
2020-04-26 14:56:56 [16577] [updxlrator] Retrieving file from source (DLSOURCE) for 192.168.0.172/test.localdomain
2020-04-26 14:56:56 [16577] [updxlrator] Running command /var/ipfire/updatexlrator/bin/download linux http://au.archive.ubuntu.com/ubuntu/pool/main/n/net-snmp/libsnmp35_5.8+dfsg-2ubuntu2_amd64.deb 1 &
2020-04-26 14:56:57 [16577] [updxlrator] Processing URL http://au.archive.ubuntu.com/ubuntu/pool/main/s/sane-backends/libsane_1.0.29-0ubuntu5_amd64.deb

I suspect it is squid may be the issue.

Squid checks the http header for file size and file date and it is returning zero.

7

I have installed ipfire 130 and still have the same issue so it must be a LOCAL problem with my network. I will investigate more. There is something wrong here I think.

8

Something has changed since 13th April as the file dates before that date are correct.

9

OK I have worked out why I am getting file dates of 1 Jan 1970
The Ubuntu mirror that was set up was http://au.archive.ubuntu.com so I changed it to http://archive.ubuntu.com and then it worked.

The AU site must be doing something to the date in the header or something like that.

This problem was really annoying me but now it is fixed…for the moment anyway.

Hope this helps some one else.