Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] TracerouteSender 403 Forbidden Error

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] TracerouteSender 403 Forbidden Error


Chronological Thread 
  • From: "Uhl, George D. (GSFC-423.0)[ARTS]" <>
  • To: Andrew Lake <>
  • Cc: Mark Tinberg <>, "" <>
  • Subject: Re: [perfsonar-user] TracerouteSender 403 Forbidden Error
  • Date: Wed, 30 Apr 2014 20:10:54 +0000
  • Accept-language: en-US
Andy,

Of course! Looking at the mesh config file, besides read and write URL's
for traceroute only the read URL for bwctl and owamp on port 8085 use http.

Thanks,
George

On 4/30/14 3:40 PM, "Andrew Lake"
<>
wrote:

>Hi George,
>
>Glad you got it all squared away. My guess would be that i's because the
>port 8569 and 8570 traffic is not HTTP so it did not get grabbed by the
>proxy. The traceroute collector uses HTTP to register the data so that is
>probably why it was affected and the others were not.
>
>Thanks,
>Andy
>
>
>
>On Apr 30, 2014, at 3:35 PM, "Uhl, George D. (GSFC-423.0)[ARTS]"
><>
> wrote:
>
>>
>> My project network provider is running a webproxy and is using WCCP for
>> interception but only for ports 80 and 443 outbound. The service I was
>> using sent to my archive server on port 8086. It turns out I had a ENV
>> variable, http_proxy, set in the .bash_profile configuration file in my
>> home directory that pointed to the webproxy server on port 3218. This
>>was
>> forcing the redirect of the traffic I was sending to port 8086 over to
>>the
>> proxy. I soon as I commented it out and restarted the traceroute_master
>> daemon the traceroute results were sent to the MA.
>>
>> What's weird is that the other perfSONAR traffic that use URLs for
>>sending
>> OWAMP (port 8569) and BWCTL (port 8570) were not being redirected.
>>
>> Thanks,
>> George
>>
>>
>>
>> On 4/30/14 1:11 PM, "Uhl, George D. (GSFC-423.0)[ARTS]"
>> <>
>> wrote:
>>
>>> It looks like I'm getting a wccp interception that's redirecting me to
>>>a
>>> web proxy. This is an unannounced new free service offered to my
>>> perfSONAR host! The domain of the URL I'm trying to reach is not in
>>>the
>>> whitelist. I've requested to include eos.nasa.gov in the whitelist.
>>>I'm
>>> betting that my problem will go away after that.
>>>
>>> Thanks,
>>> -George
>>>
>>> curl -X GET --dump-header -
>>>
>>>"http://archive.eos.nasa.gov:8086/perfSONAR_PS/services/tracerouteCollec
>>>to
>>> r
>>> "
>>> HTTP/1.0 403 Forbidden
>>> Server: squid/2.6.STABLE21
>>> Date: Wed, 30 Apr 2014 14:08:30 GMT
>>> Content-Type: text/html
>>> Content-Length: 1206
>>> Expires: Wed, 30 Apr 2014 14:08:30 GMT
>>> X-Squid-Error: ERR_ACCESS_DENIED 0
>>> X-Cache: MISS from eoslpwr01.slopen.ecs.nasa.gov
>>> X-Cache-Lookup: NONE from eoslpwr01.slopen.ecs.nasa.gov:3128
>>> Via: 1.0 eoslpwr01.slopen.ecs.nasa.gov:3128 (squid/2.6.STABLE21)
>>> Proxy-Connection: close
>>>
>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
>>> "http://www.w3.org/TR/html4/loose.dtd";>
>>> <HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html;
>>> charset=iso-8859-1">
>>> <TITLE>ERROR: The requested URL could not be retrieved</TITLE>
>>> <STYLE
>>>
>>>type="text/css"><!--BODY{background-color:#ffffff;font-family:verdana,sa
>>>ns
>>> -
>>> serif}PRE{font-family:sans-serif}--></STYLE>
>>> </HEAD><BODY>
>>> <H1>ERROR</H1>
>>> <H2>The requested URL could not be retrieved</H2>
>>> <HR noshade size="1px">
>>> <P>
>>> While trying to retrieve the URL:
>>> <A
>>>
>>>HREF="http://archive.eos.nasa.gov:8086/perfSONAR_PS/services/tracerouteC
>>>ol
>>> l
>>>
>>>ector">http://archive.eos.nasa.gov:8086/perfSONAR_PS/services/traceroute
>>>Co
>>> l
>>> lector</A>
>>> <P>
>>> The following error was encountered:
>>> <UL>
>>> <LI>
>>> <STRONG>
>>> Access Denied.
>>> </STRONG>
>>> <P>
>>> Access control configuration prevents your request from
>>> being allowed at this time. Please contact your service provider if
>>> you feel this is incorrect.
>>> </UL>
>>> <P>Your cache administrator is <A
>>> HREF="mailto:"></A>.
>>>
>>>
>>> <BR clear="all">
>>> <HR noshade size="1px">
>>> <ADDRESS>
>>> Generated Wed, 30 Apr 2014 14:08:30 GMT by
>>>eoslpwr01.slopen.ecs.nasa.gov
>>> (squid/2.6.STABLE21)
>>> </ADDRESS>
>>> </BODY></HTML>
>>> [root@esdis-ps
>>> ~]#
>>>
>>>
>>>
>>>
>>> On 4/30/14 9:30 AM, "Andrew Lake"
>>> <>
>>> wrote:
>>>
>>>> Hi George,
>>>>
>>>> You can forcibly generate some traffic to 8086 by running something
>>>>like
>>>> the following:
>>>>
>>>> curl -X GET --dump-header -
>>>>
>>>>"http://archive.eos.nasa.gov:8086/perfSONAR_PS/services/tracerouteColle
>>>>ct
>>>> o
>>>> r"
>>>>
>>>> That's a GET instead of a post but it'd be interesting to see what it
>>>> does. If it reaches the collector you will see something like the
>>>> following:
>>>>
>>>> HTTP/1.1 200 success
>>>> Date: Wed, 30 Apr 2014 13:07:00 GMT
>>>> Server: libwww-perl-daemon/5.827
>>>> User-Agent: perfSONAR-PS/3.2
>>>> Content-Length: 825
>>>> Content-Type: text/xml
>>>>
>>>> <SOAP-ENV:Envelope
>>>> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
>>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>>>
>>>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>
>>>> <SOAP-ENV:Header/>
>>>> <SOAP-ENV:Body>
>>>> <nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
>>>> id="message.1967190" type="ErrorResponse"><nmwg:metadata
>>>>
>>>>id="metadata.16742872"><nmwg:eventType>error.common.transport</nmwg:eve
>>>>nt
>>>> T
>>>> ype></nmwg:metadata><nmwg:data metadataIdRef="metadata.16742872"
>>>> id="data.9803672"><nmwgr:datum
>>>> xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/";>Received message
>>>>with an
>>>> invalid HTTP request, are you using a web
>>>> browser?</nmwgr:datum></nmwg:data></nmwg:message> </SOAP-ENV:Body>
>>>> </SOAP-ENV:Envelope>
>>>>
>>>>
>>>> On Apr 29, 2014, at 5:06 PM, "Uhl, George D. (GSFC-423.0)[ARTS]"
>>>> <>
>>>> wrote:
>>>>
>>>>> Mark,
>>>>>
>>>>> Thanks for following up. I was running tcpdump on the traceroute
>>>>> source
>>>>> host so I used tcpdump to look for it attempting to communicate to
>>>>>the
>>>>> remote archive server on port 8086. I'm not seeing anything related
>>>>>to
>>>>> http or traceroute in audit.log.
>>>>>
>>>>> Thanks again,
>>>>> -George
>>>>>
>>>>> On 4/29/14 4:53 PM, "Mark Tinberg"
>>>>> <>
>>>>>wrote:
>>>>>
>>>>>>
>>>>>> On Apr 29, 2014, at 2:48 PM, Uhl, George D. (GSFC-423.0)[ARTS]
>>>>>> <>
>>>>>> wrote:
>>>>>>
>>>>>>> Could this have something to do with selinux being enabled on the
>>>>>>> host?
>>>>>>> I
>>>>>>> did a tcpdump on this host and never saw any traffic sent to the MA
>>>>>>> server
>>>>>>> on port 8086.
>>>>>>
>>>>>> tcpdump would see the traffic before any packet filtering or selinux
>>>>>> policy could affect it so if you aren¹t seeing it inbound then it¹s
>>>>>> not
>>>>>> getting to the machine at all and you can conclude the problem is
>>>>>>not
>>>>>> on
>>>>>> the local machine.
>>>>>>
>>>>>>> BTW, I'm prohibited from disabling selinux on this particular host.
>>>>>>
>>>>>> As a point of reference, SELinux logs to the audit subsystem and if
>>>>>> auditd is running those logs should end up in
>>>>>>/var/log/audit/audit.log
>>>>>> which should be root-only readable. There are a lot of things which
>>>>>> are
>>>>>> audited by default, look for AVC messages, they should tell you all
>>>>>> the
>>>>>> information about what was denied, if anything. For example, here
>>>>>>is
>>>>>> what happens when apache tries to access a users home directory when
>>>>>> httpd_enable_homedirs has not been enabled by setsebool.
>>>>>>
>>>>>> # grep AVC /var/log/audit/audit.log
>>>>>> type=AVC msg=audit(1398804336.495:232531): avc: denied { search }
>>>>>> for
>>>>>> pid=9160 comm="httpd" name=³test" dev=dm-0 ino=663252
>>>>>> scontext=unconfined_u:system_r:httpd_t:s0
>>>>>> tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir
>>>>>> type=AVC msg=audit(1398804336.498:232532): avc: denied { getattr }
>>>>>> for
>>>>>> pid=9160 comm="httpd" path="/home/test" dev=dm-0 ino=663252
>>>>>> scontext=unconfined_u:system_r:httpd_t:s0
>>>>>> tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir
>>>>>>
>>>>>>
>>>>>> ‹
>>>>>> Mark Tinberg, System Administrator
>>>>>> Division of Information Technology - Network Services
>>>>>> University of Wisconsin - Madison
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


Archive powered by MHonArc 2.6.16.

Top of Page