At 13:36 2002-03-20 +0000, Nancy McGough did say:
Maybe the person who did not see the problem was accessing a
local cached copy of the site?
I just now cleared my cache (disk and memory), and there's no difference -
procmail comes up as expected. As it turns out, it isn't browser cache
that is at the root of this anyway (telnet works as well, and there's NO
cache or proxy going on there).
I shelled to a remote system (which is in Norway, I'm in California), and
performed a dig. I did the same locally on one of my servers as well.
As I mentioned yesterday - www.procmail.org is cname to www.gac.edu.
here, www.gac.edu is cname to lunen.gac.edu (138.236.128.17), but from my
remote server, the dig results in a cname to zeme.gac.edu
(138.236.128.37). i.e. externally to the procmail site, the gac.edu site
has changed, and with it, the server IT is cnamed to, which in turn affects
procmail.org.
So, it would seem that the fix might be for Philip to change the CNAME to
the specific gac.edu server (that being lunen.gac.edu), or even to set it
as an A record instead (though I'd check with the gac.edu personnel to
ensure that they're not about to pull the plug on the old server). I've
resent a separate copy of this message to him in the hopes that he'll spot it.
DNS is coming up as ns1-ns3.gac.edu for mine which works, and several
disparate named servers where it doesn't (though two of the three have the
same IPs as my set). My TTLs are at about 2d3h20m, whereas the remote
server sees 2d even. (i.e. I have DNS from a valid lookup, then something
was changed, and a fresh lookup comes up bad).
You can work around the problem easily enough: in your hosts file (either
in /etc/hosts on unix, or in /windows/hosts (whatever specific windows path
your installation of windows uses), and add:
138.236.128.17 www.procmail.org
then hit the site (possibly close your web browser entirely before doing so
in case your browser caches hostname resolutions).
$ nslookup
> server ns1.gac.edu
> set type=soa
> www.procmail.org
Server: ns1.gac.edu
Address: 138.236.128.18
www.procmail.org canonical name = www.gac.edu
www.gac.edu canonical name = zeme.gac.edu
gac.edu
origin = solen.gac.edu
mail addr = hostmaster.gac.edu
serial = 200203191
refresh = 3600 (1H)
retry = 3600 (1H)
expire = 10800 (3H)
minimum ttl = 3600 (1H)
Note that the serial changed yesterday (or the day before, depending on
where you are). The same thing applies to www.gac.edu. Somebody probably
came through and did some "housecleaning" in DNS. Those of you who don't
refer to the procmail site frequently enough didn't have the pre-change DNS
data - you got the fresh resolution of www.gac.edu.
You could confirm the actual procmail host by using telnet:
$ telnet 138.236.128.17 80
GET / HTTP/1.0
host: www.procmail.org
(followed by one blank line). You'll receive the raw HTML of the procmail
homepage, which will scroll by, but the final paragraph starts with "Bug
reports should be sent to". When you see that working, you can then do the
above hosts file change, and hit it normally until the DNS issue is
resolved, when you can undo the procmail host tweak.
Note that neither procmail.org _mail_ or _ftp_ is affected -- just the website.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail