Hello all.
As a final postscript to this issue. I tried downloading the file using
a server in our DMZ (direct net connection) and that worked.
I therefore contacted our network guys, explained the situation and they
are contacting the vendor who supplies our proxy.
While the vendor hasn't replied yet the download has started magically
working again so I am assuming they have fixed it and haven't gotten
back to us yet.
At least I hope that is the case, this suddenly stopped working and I
would be worried if it suddenly started working again, ah the joys of
having a non-deterministic network.
Thanks for all the help.
Regards,
Jeff
On 15/02/13 10:52, Stephen Frost wrote:
> * Jeffrey Jones (jjones@toppan-f.co.jp) wrote:
>> I downloaded http://yum.postgresql.org/9.2/redhat/rhel-6Server-x86_64/repodata/primary.sqlite.bz2
>> using wget on the afected computer and ran md5sum over it with the
>> following result:
>>
>> 9258bd5672cf7abb55a0d95ee2467afc primary.sqlite.bz2
> That's pretty cute. I get:
>
> sfrost@tamriel:/home/sfrost> md5sum primary.sqlite.bz2
> 168232945d791e55e56bb29757458157 primary.sqlite.bz2
>
> Which matches an md5sum run on the file on the server directly and the
> file timestamp indicates that it hasn't changed for ~2 days.
>
> Have you tried opening the file you end up receiving and inspecting it?
> Something is clearly off if you're getting a different md5sum.
>
>> I have downloaded it from a few separate computers and they all
>> return that same result.
> Can you try from a system that isn't attached to your corporate network?
>
>> I also extracted and looked at the sqlite file with sqliteman and
>> it worked without trouble. If there really was a problem then I
>> would have expected sqliteman to fail reading the file.
> Agreed, that's curious- perhaps there's a cacheing transparent proxy in
> the corporate network that's feeding you an older, but otherwise valid,
> file?
>
> Thanks,
>
> Stephen