Difference: OldInstallSquid (58 vs. 59)

Revision 592016-11-23 - DaveDykstra

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Installing a Frontier squid cache server

Line: 10 to 10
  Note to users of EGI's UMD repository: the same package is also available in UMD so it might be easier for you to get it from there.
Deleted:
<
<
If you have any problems with the software or installation, or would like to suggest an improvement to the documentation, please submit a support request to the Frontier Application Development JIRA.

For rapid response to configuration questions, send e-mail to cms-frontier-support@cern.ch or atlas-frontier-support@cern.ch. Most questions can also be answered on the user's mailing list frontier-talk@cern.ch.

 After completing a squid installation and configuration, CMS users should follow these further instructions for CMS squids. All WLCG users should register their squids with the WLCG.

Here is what is on this page:

Added:
>
>

Support

If you have any problems with the software or installation, or would like to suggest an improvement to the documentation, please submit a support request to the Frontier Application Development JIRA.

For rapid response to configuration questions, send e-mail to cms-frontier-support@cern.ch or atlas-frontier-support@cern.ch if you are in CMS or ATLAS, respectively. If you're not on either of the projects, send your questions to wlcg-squidmon-support@cern.ch. Most questions can also be answered on the user's mailing list frontier-talk@cern.ch.

 

Why use frontier-squid instead of regular squid?

The most important feature of frontier-squid is that it correctly supports the HTTP standard headers Last-Modified and If-Modified-Since better than other distributions of squid. The Frontier distributed database caching system, which is used by the LHC projects ATLAS and CMS, depends on proper working of this feature, so that is the main reason why that project maintains this squid distribution. Older versions of squid2 (including the one distributed with Red Hat EL 5) and all versions of squid3 (including the one on Red Hat EL 6) prior to squid3.5 (which is now in pre-release) do not correctly support this feature, as documented in the infamous squid bug #7. Also, the frontier-squid package contains a couple of related patches that are not in any standard squid distribution. Details are in the beginning paragraph of the MyOwnSquid twiki page. Although this package expressly supports If-Modified-Since, it also works well with applications that do not require If-Modified-Since including CVMFS. The collapsed_forwarding feature is also missing from most versions of squid, and it is important for the most common grid applications that use squid and is included in the frontier-squid package.

Line: 176 to 178
  The functionality and performance of your squid should be monitored from CERN using SNMP. The monitoring site is http://wlcg-squid-monitor.cern.ch/.
Changed:
<
<
To enable this, your site should open incoming firewall(s) to allow UDP requests to port 3401 from 128.142.0.0/16, 188.184.128.0/17, and 188.185.128.0/17. If you run multiple squid processes, each one will need to be separately monitored. They listen on increasing port numbers, the first one on port 3401, the second on 3402, etc. When that is ready, register the squid with WLCG to start the monitoring.
>
>
To enable this, your site should open incoming firewall(s) to allow UDP requests to port 3401 from 128.142.0.0/16, 188.184.128.0/17, and 188.185.128.0/17. When that is ready, register the squid with WLCG to start the monitoring. If you run multiple squid processes, each one will need to be separately monitored. They listen on increasing port numbers, the first one on port 3401, the second on 3402, etc. In order to monitor the extra ports, an exception has to be configured on the wlcg-squid-monitor.cern.ch machine, so please contact the squid support team to have that done.
  Note: some sites are tempted to not allow requests from the whole range of IP addresses listed above, but we do not recommend that because the monitoring IP addresses can and will change without warning. Opening the whole CERN range of addresses has been cleared by security experts on the OSG and CMS security teams, because the information that can be collected is not sensitive information. If your site security experts still won't allow it, the next best thing you can do is to allow the aliases wlcgsquidmon1.cern.ch and wlcgsquidmon2.cern.ch. Most firewalls do not automatically refresh DNS entries, so you will also have to be willing to do that manually whenever the values of the aliases change.
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback