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

[IDD #WPE-643227]: (No Subject)

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 #WPE-643227]: (No Subject)
  • Date: Tue, 18 Apr 2006 14:18:17 -0600
Hi Yoshihiro,

re:
> Do you have any good news regarding the atm.geo.nsf.gov
> status (as by your e-mail of last 14)?

Unfortunately, no.  We registered a service call with the company that
maintains the hardware yesterday, and they are apparently waiting for
a part (CPU).

> Since I do not have a good connection from here
> (University of Aveiro - Portugal)to the failover computers
> ( which are in Brasil) I would like to know if you (or
> Jeff Weber - as by e-mail sent me on january, 2005) can
> assign me a failover computer from usa.

We intend that idd.unidata.ucar.edu be used as a general failover for
all IDD users.  (We have already allowed access to the same data you
were getting from idd.geo.nsf.gov.)

Just in case you did not see the note I sent out about a month ago,
we are asking all sites to change their ~ldm/etc/ldmd.conf request lines
from 'atm.geo.nsf.gov' to 'idd.geo.nsf.gov'.  At present, idd.geo.nsf.gov
is simply an alias for atm.geo.nsf.gov.  In the not too distant future
(end of May or beginning of June) idd.geo.nsf.gov will be a different
machine.

> Since I have a firewall problem in the University, the
> computer department request me a ip number (of external
> computer) in order to have  assigned the special port. So
> that I could not set the  idd.unidata.ucar.edu YET as you
> reccomended, to solve the actual problem.

OK, I think I understand.  One complicating factor in using
idd.unidata.ucar.edu is that it is actually a cluster of machines,
not a single one.  The IP addresses for the pieces of the cluster
are, in fact:

idd.unidata.ucar.edu  -> 128.117.140.3
uni1.unidata.ucar.edu -> 128.117.140.111
uni2.unidata.ucar.edu -> 128.117.140.112
uni4.unidata.ucar.edu -> 128.117.140.114

The feed request goes to idd.unidata.ucar.edu which, in turn
relays it to one of the real data servers, uni[124]. The data,
however, will come back from any one of uni[124], so all of
these IPs will need to be coded into your firewall.

I am sending off a request to the administrator of a different
toplevel CONDUIT (Pete Pokrandt <address@hidden>, University
of Wisconsin) asking to have you allowed to feed CONDUIT from
him.  Even though the allow has not been made yet, please 
configure your LDM to use f5.aos.wisc.edu (144.92.131.244) as a
failover for your CONDUIT feed.

> As an additional information : Actually we are using all
> gfs forecast to rum the noaa satellite data retrieval and
> to rum MM5 and WRF models. So that it is very important
> for us to have the gfs data

OK.

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