This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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.