Bug 1220531 - Spacewalk proxy should not cache Debian repodata/Packages.gz for 365 days.
Summary: Spacewalk proxy should not cache Debian repodata/Packages.gz for 365 days.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Proxy Server
Version: 2.2
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Stephen Herr
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space24
TreeView+ depends on / blocked
 
Reported: 2015-05-11 19:29 UTC by David Holland
Modified: 2015-10-08 13:27 UTC (History)
1 user (show)

Fixed In Version: spacewalk-proxy-installer-2.4.3-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-08 13:27:08 UTC
Embargoed:


Attachments (Terms of Use)
default squid configuration change (648 bytes, patch)
2015-05-11 19:29 UTC, David Holland
no flags Details | Diff

Description David Holland 2015-05-11 19:29:46 UTC
Created attachment 1024316 [details]
default squid configuration change

Description of problem:

The default proxy/squid configuration caches repodata/Packages.gz for far too long.
I believe it is 365 days by default.

Version-Release number of selected component (if applicable):

2.2 (and 2.3) 

How reproducible:

Very.

Steps to Reproduce:

Install spacewalk proxy.
Register client through proxy

apt-cache update    # To prime the squid cache

<add additional packages to channels visible to client>
<wait a few minutes>

apt-cache update

Actual results:

<New packages are not visible.>

Expected results:

<New packages should be visible>

Additional info:
N/A

Also attached is a minor installer patch to fix the problem, and put the caching times on-par w/ the YUM XML repodata.

Comment 1 Stephen Herr 2015-05-11 20:17:04 UTC
Heh, thanks for the bug.

I'm not accepting the patch (which would create a new refresh rule for Packages.gz specifically) but instead I'll modify the existing repodata rule and delete the xml-specific portion. All repodata files should be treated the same way, regardless of if they're .xml, .xml.gz, .gz, .sqlite, or something else.

As you note this is a change in the installer, so only Proxies installed with an updated installer will get the fix automatically. People interested in fixing this on existing Proxies will have to change the line in /etc/squid/squid.conf manually:
For Proxy 2.3:
refresh_pattern /XMLRPC/GET-REQ/.*/repodata/.*$ 0 1% 1440 ignore-no-cache reload-into-ims refresh-ims
For Proxy 2.2 and older:
refresh_pattern /XMLRPC/GET-REQ/.*/repodata/.*$ 0 1% 525960

(and then restart squid)

Committing to Spacewalk master:
ee6051aa36eca7169c2e5f424c1c5b7933e8d98d

Comment 2 David Holland 2015-05-26 19:26:32 UTC
Thanks, though looping back around... 

Should the upper bound still be a 365 days (525960 minutes)?    
I was thinking something more along the lines of 30 minutes.

I've been trying to read the squid documentation, but it makes Mongo's head hurt, and I can't make much sense of it. 

We had a freshly stood up proxy server serving up stale repodata to a SuSE client for several hours via the original "repodata/.*\.xml.*$ 0 1% 525960" rules.

Cheers....

Comment 3 Stephen Herr 2015-05-26 20:01:40 UTC
I think you're probably right, and that for Proxy 2.2 and older the thing that would make the most sense is probably:
refresh_pattern /XMLRPC/GET-REQ/.*/repodata/.*$ 0 100% 30

or something. However I'm also not really a squid expert and the longer timeout is how it's "always been", apparently without too much trouble, so I don't know...

Future versions of Proxy will use the refresh-ims line which will make Proxy to an If-Modified-Since request upstream, so this will no longer be a problem then.

Comment 4 Jan Dobes 2015-10-08 13:27:08 UTC
Spacewalk 2.4 has been released.


Note You need to log in before you can comment on or make changes to this bug.