InCommon metadata support

[Alex Stuart <>]

Brent,

I can't help with finding the root cause, but I will ask why you're
using that VBscript workaround rather than the Shibboleth SP's own
mechanism for dealing with intermittency at the transport layer? The
SP's MetadataProvider element allows for a backingFilePath attribute.

(see
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMetadataProvider
and
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPReloadableXMLFile)

Your email seems to indicate you have set this, but also that you
populate the location using VBscript.

We've occasionally seen problems where the backing file hasn't been
writeable by the shib process, so I suggest that you check the
permissions on the backing file, and just use Shibboleth to manage the
intermittency.

Alex


On 03/02/2016 21:28, Brent Wygant wrote:
> Hello,
> 
>  
> 
> We are running Shibboleth SP version 2.4.3. The application is
> configured to download (cURL) the IdP metadata file from the URL
> http://md.incommon.org/InCommon/InCommon-metadata.xml. This is where the
> problem comes in. Once or twice per day, we see the following error in
> the logs that indicate a problem with connecting a socket >>
> 
> ERROR XMLTooling.ParserPool : fatal error on line 0, column 0, message:
> unable to connect socket for URL
> 'http://md.incommon.org/InCommon/InCommon-metadata.xml'
> 
> ERROR OpenSAML.MetadataProvider.XML : error while loading resource
> (http://md.incommon.org/InCommon/InCommon-metadata.xml): XML error(s)
> during parsing, check log for specifics
> 
>  
> 
> We see a similar error whether the reload timer expires (currently set
> to 7200 seconds), or the Shibboleth 2 Daemon service is restarted. This
> error is sporadic in that sometimes the application can connect to the
> remote resource to compare and validate that no changes have been made,
> and sometimes it can actually connect and successfully download the XML
> file.
> 
>  
> 
> We currently have a workaround in place that cURLs the XML file to the
> cache and backup location configured in the application, so the failed
> connection will result in loading a current file. It is a VBscript that
> copies the file and restarts the Shibboleth 2 Daemon service. This
> workaround is not ideal and we’d like help to get to the root of the
> problem as to why the Shibboleth app can’t connect to the remote XML
> resource.
> 
>  
> 
> Has anyone come across a similar problem that can provide some input
> and/or guidance?
> 
>  
> 
> Thank you for your time!
> 
>  
> 
> - Brent
> 
>  
> 
> *Brent Wygant*
> SumTotal, a Skillsoft Company | phone: 614.781.9209 | mobile: 614.915.5102
> Deployment Lead | Cloud Operations
> 
>  
> <mailto:>|
> www.sumtotalsystems.com <http://www.sumtotalsystems.com.com/>__
> 
> <http://www.sumtotalsystems.com/>                 
> 
> Description: cid:
> <https://www.linkedin.com/company/sumtotal-systems>  Description:
> Description: Description: cid:
> <https://twitter.com/sumtotalsystems>  Description:
> cid:
> <http://blog.sumtotalsystems.com/>  Description:
> cid:
> <https://www.facebook.com/SumTotal.Systems>    
> 
>  
> 

-- 
Alex Stuart
Team Leader - Federated Access Management
EDINA, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.