[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[IDD #MGQ-784340]: COD machine REQUESTing LDM/IDD feed(s) from lead.unidata.ucar.edu

Hi Mike,

re: REQUEST that is being blocked is due to no reverse DNS

> Copy that.  Well it's nice to know my imglist checks weren't throwing up
> the flags.

Not at all.

In case you didn't already know, you can also get GOES-16 imagery via
ADDE from:

atm.ucar.edu

And, we will be adding the data and serving to:

adde.ucar.edu (after it is upgraded to a Linux machine)
adde.ssec.wisc.edu


re: lead's IP address is 128.117.149.100

> Heh, you say that, but we have a whole section in our ldmd.conf full of
> IPs.  Most are allows, not requests, but either way I just checked for that
> IP and couldn't find one that matched.  But knowing the IP to look for
> really helps.

Our blanket ALLOWs are by name, not IP/IP mask.

re: ancient, commented out lines in your LDM configuration file(s)

> Talk about ancient, that section of IPs I mentioned... no joke, here's the
> header comment:
> "#For 10/7/97 outage."
> Referring to, I believe, a DNS outage of sorts, which would explain having
> IPs all over the place.  But yeah, I really need to do some house cleaning.

:-)  The LDM and IDD have been active since 1994!

re: perhaps the REQUEST is an old one setup by Victor?

> So he didn't have any machine "off to the side" or anything.  While he
> would make edits to LDM(s), anything he did would be included in places I'm
> already looking.

OK.

re:

> A few notes on this.  Victor was trying to get 15-minute HRRR data at one
> point, and actually looks like it's still coming in.  But he was very
> selective about it, only requesting two specific products and not the whole
> ".*" show, so we wouldn't have seen a noticeable bandwidth hit from just
> that.  I see those requests are still active though, and we're still
> getting data:
> 
> request FSL2 "^GRIB2\.FSL\.*Minute\.REFC" hrrr.unidata.ucar.edu
> request FSL2 "^GRIB2\.FSL\.*Minute\.UPHL.5000m" hrrr.unidata.ucar.edu

Ah Ha!  hrrr.unidata.ucar.edu is another name for lead.unidata.ucar.edu!

re:
> Given that, `nslookup hrrr.unidata.ucar.edu` results in 128.117.149.11, so
> not the same as the one you gave me for lead.

Actually, it is, but not so as it is obvious (that would be too easy :-)

re:
> Now this is all taking place on Atlas.cod.edu, where we were processing
> that data.  And like I said we're still getting data there, so those
> requests seem to be going through.  But something else I'll say, we
> recently replaced that server and we still have the old one running
> parallel just in case we needed to revert.  The plan was to take it offline
> next week so LDM is still running on that too right now.  I just took a
> look through those logs, and now I see a bunch of these (that don't exist
> on the other servers):
> 
> hrrr.unidata.ucar.edu[2852] NOTE error.c:236:err_log() Upstream LDM didn't
> reply to FEEDME request; RPC: Unable to receive; errno = Connection reset
> by peer

That's because the machine making the REQUEST does not have reverse DNS
(IP -> name).  If it did, and if the name resolved to a '.edu', the
feed REQUESTs would be honored.

re:
> I also see the same thing for idd.unidata.ucar.edu there.  Interesting.
> 
> We actually stopped using that (FSL2 15-minute HRRR) data a while back, so
> there's no need for those requests anymore.  I just turned them off
> everywhere I believe they exist, and if you stop seeing those hits then
> maybe that was it.

I am sure that was it as I no longer am seeing the 'Denying connection'
messages from 192.203.137.253.  Success!

re: cutting down on needless logging
> Understood, and we certainly want to accommodate you.

Thanks!

re:
> Here's what I'm thinking:  If disabling those HRRR requests did it then
> great.  So let me know if you're still seeing those requests or not.  But
> assuming that won't work, I'll next reach out to a few other people here,
> including our IT Network Services guy.  He's conveniently out of the office
> today, but I'm hoping we'll be able to trace back what's trying to radio
> the lead server in short time.

We're good now.  Now I need to track down the owners of the other
two machines making REQUESTs.  Those will be much harder I fear as
one is from what looks to be a private company in Denver (but that
just might be the ISP), and the other one appears to be coming from
Cairo, Egypt!

re:
> It's good to know it's not critical so I don't have to hit any panic
> buttons, but I'd like to get this straightened out too.  Sorry for the
> inconvenience.

Again, no worries.  I wouldn't even have know about it if it were not
for the problems we experienced on lead earlier in the week.

All's well that ends well!

Thanks for the help!!

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: MGQ-784340
Department: Support IDD
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.