20040319: strange ADDE issue on newpsn (RH 9) (cont.)

>From: Robert Mullenax <address@hidden>
>Organization: NMSU/NSBF
>Keywords: 200403190340.i2J3enrV010796 McIDAS ADDE

Robert,

re: Linux firewall
>I selected No Firewall at install...and the guys there didn't reinstall
>one.
>
>It's very strange.

I logged onto your machine and took a quick look at /etc/hosts.allow,
/etc/hosts.deny, /etc/sysconfig/iptables (does not exist),
/etc/xinetd.d/mccompress, /etc/xinetd.d/mcserv, and /etc/xinetd.d/mcidas:
they all look fine!

Next, I did the quick-n-dirty test to see if the necessary McIDAS ports
are open:

% telnet newpsn.nsbf.nasa.gov 500
Trying...
Connected to newpsn.nsbf.nasa.gov.
Escape character is '^]'.

% telnet newpsn.nsbf.nasa.gov 503
Trying...
Connected to newpsn.nsbf.nasa.gov.
Escape character is '^]'.

% telnet newpsn.nsbf.nasa.gov 112 
Trying...
Connected to newpsn.nsbf.nasa.gov.
Escape character is '^]'.

All of these look fine.

I then pointed a McIDAS session at your ADDE server for the RTIMAGES
dataset and was able to get information from the server:

DSINFO I RTIMAGES

        Dataset Names of Type: IMAGE in Group: RTIMAGES

Name         NumPos   Content
------------ ------   --------------------------------------
ANTARCTIC       10    Antarctic IR Composite
EDFLOATER-I     10    Educational Floater
EDFLOATER-II    10    Educational Floater II
GE-IR           10    GOES-East North America IR
GE-IRTOPO       10    GOES-East IR/TOPO Composite
GE-VIS          10    GOES-East North America VIS
GE-VISTOPO      10    GOES-East VIS/TOPO Composite
GE-WV           10    GOES-East North America H2O
GEW-IR          10    GOES-East/West IR Composite
GEW-IRTOPO      10    GOES-East/West IR/TOPO Composite
GEW-VIS         10    GOES-East/West VIS Composite
GEW-VISTOPO     10    GOES-East/West VIS/TOPO Composite
GEW-WV          10    GOES-East/West H2O Composite
GW-IR           10    GOES-West Western US IR
GW-IRTOPO       10    GOES-West IR/TOPO Composite
GW-VIS          10    GOES-West Western US VIS
GW-VISTOPO      10    GOES-West VIS/TOPO Composite
GW-WV           10    GOES-West Western US H2O
MDR             10    Manually Digitized Radar
MDRTOPO         10    MDR/TOPO Composite
MOLL-IR         10    Mollweide Composite IR
MOLL-IRTOPO     10    Mollweide IR/TOPO Composite
MOLL-WV         10    Mollweide Composite H2O
RESFLOATER      10    Research Floater

DSINFO -- done
MGLIST RTIMAGES/GE-IR FORM=ALL
Image file directory listing for:RTIMAGES/GE-IR
 Pos Satellite/         Date       Time      Center      Res (km)   Image_Size
     sensor                                 Lat  Lon    Lat   Lon
 --- -------------  ------------  --------  ---- ----  ----- ----- ------------
   9  G-12 IMG      19 MAR 04079  21:15:00     0   72
    Band: 4  10.7 um Surface temp; longwave window      4.03  4.59  2600 x 1732
     proj:    0 created: 2004079 212526  memo: RT GVAR
     type:VISR     cal type:BRIT
     offsets:  data=    2816 navigation=  256 calibration=    0 auxiliary=    0
     doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
     valcod:          0 zcor:  0 avg-smp: N
     start yyddd: 2004079  start time:211514  start scan:  384
     lcor: 2677  ecor:  9033  bytes per pixel: 1  ss: 78
     Resolution Factors (base=1):   Line=    4.0   Element=    8.0
IMGLIST: done


So, access from outside of your domain by machines in the unidata.ucar.edu
domain is OK.  I tried access using no compression, 'compress' compression,
and 'gzip' compression.  All three access methods worked with no problems.

Is it possible that you have an /etc/hosts entry for newpsn on the
machines on which you are experiencing failure (so that the IP address
being used is not correct)?

Along the same lines of thinking, is it possible that the IP address
for newpsn changed at some point after you had been accessing the
remote server from external machines?

ADDE caches the IP number for a machine specified in a DATALOC
invocation when DATALOC is run.  If the IP address changes, you will
then have a cached IP value that is incorrect.  The procedure to
correct the IP address is to rerun the DATALOC ADD command, or to run
DATALOC HOST.  DATALOC HOST forces a hostname/IP address lookup and
updates the table that contains the cached values:

~/mcidas/data/MCTABLE.TXT for the non-mcidas user
~mcidas/data/ADDESITE.TXT for the mcidas user when setup according to
 Unidata recommendations

If your problem is not a cached IP address that is no longer valid, the
next step is to get on a machine that is unable to access newpsn and
run McIDAS commands from it while pointing at newspn and while
monitoring processing on newspn.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.