So does the 404 error mean the configuration error is with the RAL Squid
rather than the local site? I don't mind which backup site we use as
long as it works!
Cheers,
Ben
On 16/06/10 09:18, Christopher J.Walker wrote:
> Alastair Dewhurst wrote:
>> Hi
>>
>> The current state of the ATLAS frontier service is not ideal. The SAM
>> tests:
>> https://lcg-sam.cern.ch:8443/sam/sam.py?CE_atlas_disp_tests=CE-ATLAS-sft-Frontier-Squid&order=SiteName&funct=ShowSensorTests&disp_status=na&disp_status=ok&disp_status=info&disp_status=note&disp_status=warn&disp_status=error&disp_status=crit&disp_status=maint
>>
>> show several production sites getting a warning. This warning is
>> normally caused by the backup squid not being configured correctly.
>>
>
> QMUL (and RHUL) are warning because RHUL hasn't got around to
> configuring a squid after their shutdown.
>
> It's true that QMUL's squid wasn't working for them after I upgraded it
> - at Atlas's request. It's just a simple upgrade and will just work
> apparently - though I do wish I'd been told it moved the config files...
>
> In fact, that reminds me, which mailing list should I have been on to
> get told about that request. A concern I have about installing this sort
> of one off software is that it doesn't get the routine security updates
> that SL does.
>
>> To remind people: WNs should connect to the local squid (normally at
>> the site) which connects to the Frontier server at RAL. If the local
>> squid is down then the WN will try and connect to a backup squid which
>> is meant to be at a nearby site which will then try and connect to the
>> Frontier server. There is a similar backup process should the Frontier
>> server at RAL fail then all the squids will try and connect to the
>> frontier server at PIC.
>>
>> To ease this problem it has been suggested that the default backup for
>> Tier 2 sites is the squid at RAL (The Tier 1 not the Tier 2!). The
>> squid at the Tier 1 is the same installation as the Frontier server so
>> if the frontier services goes down so will the backup squid. This does
>> reduce the resilience of the setup slightly but I think this is worth
>> it given it should make things significantly simpler to maintain. It
>> does also means I will have to get the SAM test modified slightly. If
>> however there are sites that are happy with the current setup and
>> managing firewall access to their squid from other sites worker nodes
>> then please feel free to respond.
>>
>> Before committing any change to Tiersofatlas I would like sites to run
>> a test to make sure they can indeed successfully access the RAL squid.
>>
>> To do this:
>> Log into a WN
>> > wget http://frontier.cern.ch/dist/fnget.py
>> > export http_proxy=http://lcgft-atlas.gridpp.rl.ac.uk:3128
>> > python fnget.py
>> --url=http://lcgft-atlas.gridpp.rl.ac.uk:3128/frontierATLAS/frontier
>> --sql="SELECT TABLE_NAME FROM ALL_TABLES"
>> This should provide a big list of table names and not a python error!
>>
>
> You mean not like this...
>
> [walker@cn456 tmp]$ wget http://frontier.cern.ch/dist/fnget.py
> --2010-06-16 09:07:11-- http://frontier.cern.ch/dist/fnget.py
> Resolving frontier.cern.ch... 128.142.202.212
> Connecting to frontier.cern.ch|128.142.202.212|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 8406 (8.2K) [text/plain]
> Saving to: `fnget.py'
>
> 100%[======================================>] 8,406 --.-K/s in 0.02s
>
> 2010-06-16 09:07:11 (434 KB/s) - `fnget.py' saved [8406/8406]
>
> [walker@cn456 tmp]$ export
> http_proxy=http://lcgft-atlas.gridpp.rl.ac.uk:3128
> [walker@cn456 tmp]$ python fnget.py
> --url=http://lcgft-atlas.gridpp.rl.ac.uk:3128/frontierATLAS/frontier
> --sql="SELECT TABLE_NAME FROM ALL_TABLES"
> Using Frontier URL:
> http://lcgft-atlas.gridpp.rl.ac.uk:3128/frontierATLAS/frontier
> Query: SELECT TABLE_NAME FROM ALL_TABLES
> Decode results: True
> Refresh cache: False
>
> Frontier Request:
> http://lcgft-atlas.gridpp.rl.ac.uk:3128/frontierATLAS/frontier?type=frontier_request:1:DEFAULT&encoding=BLOBzip&p1=eNoLdvVxdQ5RCHF08nGN93P0dVVwC-L3VXD08YkHiwUDAJs3CTA_
>
>
> Query started: 06/16/10 09:07:25 BST
> Traceback (most recent call last):
> File "fnget.py", line 231, in ?
> result = urllib2.urlopen(request).read()
> File "/usr/lib64/python2.4/urllib2.py", line 130, in urlopen
> return _opener.open(url, data)
> File "/usr/lib64/python2.4/urllib2.py", line 364, in open
> response = meth(req, response)
> File "/usr/lib64/python2.4/urllib2.py", line 471, in http_response
> response = self.parent.error(
> File "/usr/lib64/python2.4/urllib2.py", line 402, in error
> return self._call_chain(*args)
> File "/usr/lib64/python2.4/urllib2.py", line 337, in _call_chain
> result = func(*args)
> File "/usr/lib64/python2.4/urllib2.py", line 480, in http_error_default
> raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
> urllib2.HTTPError: HTTP Error 404: Not Found
>
>> Could sites please reply with the results of the test and any comments
>> are also welcome.
>>
>>
--
Dr Ben Waugh Tel. +44 (0)20 7679 7223
Dept of Physics and Astronomy Internal: 37223
University College London
London WC1E 6BT
|