[GRLUG] Slightly OT, .. Bad URL redirect

[Grand Rapids Linux Users Group]

Are they both on the same network, with the same routing to the target host?

Try traceroute - do both end up at the same server through the same hops?

If you telnet to usam.com port 80 - and manually issue an http GET request,
do you get the same results?

On Mon, Jun 7, 2021 at 7:34 PM megadave at gmail.com <megadave at gmail.com>
wrote:

> If you manually do a DNS lookup from both the failing and non-failing
> machine, do you get the same IP address for the hostname?
>
> Maybe one has something in /etc/hosts that is giving an old/bad address?
>
> On Mon, Jun 7, 2021 at 6:58 PM Grand Rapids Linux Users Group <
> grlug at grlug.org> wrote:
>
>> Doing more testing with another system that is the same distro, version,
>> and application (i.e. both run Nagios):
>>
>>    Original machine                 Test machine
>>    ================                 ============
>>
>> lynx usam.com                   lynx usam.com
>>         <fails>                         <works!>
>>     ldd lynx                            <same library versions!!>
>>
>> curl usam.com                   curl usam.com
>>         <fails>                         <returns the redirect HTML>
>>     ldd curl                            <same libraries & vers!!>
>>
>> repositories    <exactly the same>
>> update status   <exactly the same>
>>
>> My original hypothesis that the problem could be traced to the last
>> letsencrypt update does not appear valid, as there are other sites with
>> newer certs that DO work properly.
>>
>> As there is no code difference between tools on these two machines, how
>> can the cause of this site failure be isolated?
>>
>>         Thanks!
>> --
>> grlug mailing list
>> grlug at grlug.org
>> https://shinobu.grlug.org/mailman/listinfo/grlug
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://shinobu.grlug.org/pipermail/grlug/attachments/20210607/6c2ce68f/attachment.html>