richardlehane / siegfried

signature-based file format identification
http://www.itforarchivists.com/siegfried
Apache License 2.0
217 stars 30 forks source link

sf -update fails to download signatures file #170

Closed sviscapi closed 2 years ago

sviscapi commented 2 years ago

Dear @richardlehane ,

I get the following error message when trying to update the signatures file:

C:\Users\myuser\Downloads\siegfried_1-9-1_win64\win64>sf.exe -update 2021/11/22 10:14:47 [FATAL] failed to update signature file, Get https://www.itforarchivists.com/siegfried/update: dial tcp 104.21.89.244:443: connectex: Aucune connexion n’a pu être établie car l’ordinateur cible l’a expressément refusée.

The part in French can roughly be translated to: no connection could be established because the target computer has expressly refused.

What am I doing wrong ?

Has this anything to do with https://github.com/digital-preservation/droid/issues/657 and https://github.com/digital-preservation/droid/issues/658 ?

The workaround (https://github.com/richardlehane/siegfried/wiki/Getting-started#installing-the-latest-signature-file) worked fine though.

Best regards,

Samuel, for Conseil Départemental de l'Hérault (France) herault.fr

richardlehane commented 2 years ago

thanks Samuel - I'm not sure what's going on here. The URLs are both working today (https://www.itforarchivists.com/siegfried/latest and https://www.itforarchivists.com/siegfried/update). I'll see if I can reproduce!

sviscapi commented 2 years ago

Hmm, it seems to be working when using a mobile connection:

C:\Users\myuser\Downloads\siegfried_1-9-1_win64\win64>sf.exe -update ... downloading latest signature file ... ... writing C:\Users\myuser\siegfried\default.sig ... Your signature file has been updated

The issue could actually be on our end (maybe some proxy got in the way).

Best regards,

Samuel

richardlehane commented 2 years ago

thanks for following up & yes some kind of proxy issue was what I was thinking too!

sviscapi commented 2 years ago

I plugged the computer back on Ethernet and got the same error message. Definitely some kind of proxy related problem on our end.

I'll ask the IT to allow SSL connections to itforarchivists.com.

Sorry for the noise, I was barking up the wrong tree :)

Best regards,

Samuel

richardlehane commented 2 years ago

No problem, thanks Samuel

sviscapi commented 2 years ago

Dear @richardlehane ,

Could you please re-open this issue ? I've got some news about our proxy.

Best regards,

Samuel, for Conseil Départemental de l'Hérault (France)

sviscapi commented 2 years ago

Dear @richardlehane ,

Thanks for reopening this issue.

So we are indeed using a proxy. The problem is that the "sf" command doesn't use the proxy configuration set in Windows, and tries to access the Web directly.

Is that something you could work on ? As a last resort, we could also tell our proxy (via the proxy.pak file) to ignore requests to https://www.itforarchivists.com/siegfried/update.

Best regards,

Samuel, for Conseil Départemental de l'Hérault (France)

richardlehane commented 2 years ago

Hi Samuel I checked the relevant code this evening & sf will pick up your proxy, but only if it is available as an environment variable (either HTTP_PROXY or HTTPS_PROXY).

You could test this by running set HTTP_PROXY=http://someip:someport (if you don't know the IP and port you can check with an online tool e.g. http://www.whatismyproxy.com/) before running sf -update.

sviscapi commented 2 years ago

Hi Richard,

I confirm the "set HTTP_PROXY=http://someip:someport" command does the trick :)

Cheers, Samuel