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

[IDD #ASB-634362]: Re: [gembud] 20120926: Unidata services no longer available from NSF cise-nsf.gov machines

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.

  • Subject: [IDD #ASB-634362]: Re: [gembud] 20120926: Unidata services no longer available from NSF cise-nsf.gov machines
  • Date: Thu, 27 Sep 2012 09:12:38 -0600
Hi Donna,

re:
> Tom, maybe you mentioned this in a previous email. I want to double
> check that I have the "replacement" addresses to use instead of the
> *cise-nsf.gov ones. Do you have that handy? (It's probably in some OLD
> email!)

You (TAMU) have nothing to worry about.  Gerry implemented multiple connections
for each IDD feed being ingested into the TAMU IDD cluster.  Turning off the
REQUESTs to idd.cise-nsf.gov should have _no_ impact on data ingestion at
TAMU.

re:
> Former Unidata machine at NSF      Headnode
> --------------------------------+---------------------------------------------
> adde.cise-nsf.gov
> atm.cise-nsf.gov
> idd.cise-nsf.gov
> ingest.cise-nsf.gov
> thredds.cise-nsf.gov
> 
> They may all be the same. I just feel "behind the curve".

As you guessed, a number of these machine names refer to the same physical 
machines.
adde.cise-nsf.gov, atm.cise-nsf.gov, and thredds.cise-nsf.gov all refer to the
same motherlode clone that has been hosted at the NSF for a number of years.
idd.cise-nsf.gov and ingest.cise-nsf.gov both refer to the IDD cluster that
has also been hosted at the NSF for years.

re:
> Thank you very much,

No worries.  Again, TAMU will not even notice the disappearance of our
machines at the NSF.

By the way, interacting with the TAMU listserv via address@hidden
is kind of painful.  It seems that every message that is sent to this address
generates a message from the listserv infrastructure that informs us that
we need to go to a web page to verify that it is not spam.  Is there some
secret handshake that can be implemented to avoid this clumsy way of
interacting?

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: ASB-634362
Department: Support IDD
Priority: Normal
Status: Closed