[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:
> That sure looks like our IP, and yes I'd be a good person to contact.

OK, good.  I didn't want to bother needlessly :-)

re:
> The
> one machine we have that I know is accessing lead.unidata.ucar.edu is our
> GOES16 server.  I routinely use imglist to check for updated data on
> RTGOESR, and if it is new then we use imgremap to crop a subset (of each
> ABI band) to a local Area file.  From there we use the data to make
> full-resolution GOES-16 imagery for areas in Canada.

I see the connections via McIDAS ADDE.  The connection I wrote about is
from an LDM that does not have reverse DNS that is REQUESTing an LDM
feed from lead.unidata.ucar.edu.  The feed REQUEST is being denied
because we have no rule to ALLOW that IP address.

re:
> But that's all using McIDAS commands, you mentioned LDM.  I'm not sure I
> know off the top of my head about that....  I grepped ~/etc/* on each
> server of ours I could think of, and I couldn't find any references to
> lead.unidata.ucar.edu in pqacts or ldmd.conf files, or anything under
> ~/etc.

lead's IP address is 128.117.149.100.  Someone may have implemented a
REQUEST by IP, but that is not typical.

re:
> We do request from idd.unidata.ucar.edu, and I saw results from
> iddb, hrrr & rtstats (as well as for imogene.unidata.ucar.edu, but those
> are commented / turned off and before my time).  But I couldn't find
> anything requesting from lead.

The REQUEST to imogene must be ancient as imogene was decommissioned a LONG
time ago :-)

re:
> If the above McIDAS commands aren't what you were looking for, then I alone
> don't have an answer.  But I agree that looks like our IP, so I can reach
> out to a couple other people and see if they have an idea.

OK, thanks.  Is there a possibility that the COD machine that Victor G used
while he was there was setup to run an LDM, and that he tried to get a 
feed from lead.unidata.ucar.edu?  My hunch is that the feed most likely
to have been wanted is FSL2 as that contains HRRR model output from
NOAA/GSD.  I have to say, however, that the FSL2 feed is VERY high
volume, so if there really is a REQUEST for it, and if it had been
honored, then a LOT of COD's bandwidth would be used.

re:
> Might I ask what prompted the question?

Sure.  We had an event on lead a couple of days ago where the 1-minute
load average went to 280, and the machine because unreachable.  After
the load average got down to around 80, I could get in, and do some
poking around to figure out what happened.  One of the things I do
is look at the LDM log file (typically ~ldm/logs/ldmd.log) to see if
there are any indications of problems, and when I did that I noticed
feed REQUESTs being denied for three different machines, and one of
those is apparently at COD and its LDM is still trying to REQUEST
a feed from lead.  Getting rid of the REQUEST would cut down on logging,
so it is desired, but it is not critical (but it _is_ desired) :-)

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.