20011227: SSEC McIDAS not able to get data from Unidata McIDAS 7.804 ADDE server built with gcc/g77 (cont.)

>From: Robert Mullenax <address@hidden>
>Organization: NMSU/NSBF/Universal Weather
>Keywords: 200112271446.fBREkPN17596 McIDAS-X 7.804 ADDE gcc/g77

Robert,

re: are you logged onto SSEC McIDAS-X session that is unable to get
info back from Unidata McIDAS-X ADDE server

>I guess I am not sure what you mean.  I logged on to the SSEC McIDAS
>machines and then changed my dataloc so that RTWXTEXT pointed
>at the Unidata gcc/g77 box.

Your comment makes me think that the answer to the LOGON question is
no.  LOGON is a McIDAS command that allows you to tell your session who
you are via a user ID and project number.  ADDE servers can be setup to
limit access to datasets to specific client IP address and/or user IDs
and project numbers.  This checking occurs at the 'mcserv' lever
meaning that checks are made before the appropriate ADDE server is
exec'd from mcserv.

re: what happens when using the Unidata 7.804 gcc/g77 build to access
datasets hosted on a workstation running the SSEC distribution

>This works fine.  If I go to impactwx12 (the gcc/g77 Unidata box)
>and do dataloc.k ADD RTWXTEXT weather.univ-wea.com (this is our 4800
>running SSEC XCD) it works fine.  I can get data, dsinfo works
>fine..etc...but I still can't go the other way.

OK.  The clues are getting to sound more and more like access to
datasets is being denied on the machine running Unidata 7.804 gcc/g77
at some level well before an actual data server is run.  To me this
leaves one of two possibilities:

o there are TCP wrappers setup on the workstation running the Unidata
  McIDAS ADDE server code built with the gcc/g77 combination

o something like a user ID and/or project number is set to a strange
  value when it comes from an SSEC session and so it is getting rejected
  on the Unidata McIDAS-X 7.804 gcc/g77 server

Do you have TCP wrappers setup to deny any machines on the workstation
running the Unidata 7.804 release built with gcc/g77?

If not, can you do a quick rebuild of -X using gcc/f2c/mcfc to see if
the problem can be isolated to code built using gcc/g77?  (Please try
another test before going to this extreme; read this entire email
before rebuilding code).)

The test wit code built with gcc/f2c/mcfc would be most interesting.
If the ADDE servers built with gcc/f2c/mcfc do allow the SSEC machine
to requst data (DSINFO, IMGLIST, etc.) then there is obviously
something amiss with a Fortran routine being called from the
server(s).  The hard thing to grasp here is the fact that machines
running Unidata McIDAS can access the server that the machines running
SSEC McIDAS can not.

Here is another test that I would like you to run:

Try getting data from one of our Solaris x86 machines running my 7.804
release built with gcc/g77:

DATALOC ADD RTIMAGES adde.unidata.ucar.edu
DSINFO IMAGE RTIMAGES
IMGLIST RTIMAGES/GE-IR

Please run this test both from your machine(s) running SSEC McIDAS and
from your machine(s) running Unidata McIDAS.

We use TCP wrappers on this machine to limit access by host IP, but I
have set it to be wide open for the testing I propose.  If you can
access our machine from your workstations running SSEC McIDAS, then the
problem has to be (or, I sure hope it is) with the setup on your box
running Unidata McIDAS 7.804 built with gcc/g77.

re: difference when doing an IMGLIST group/descriptor TRACE=1 from your
workstation running SSEC McIDAS and from your workstation running
Unidata McIDAS

>When I do the imglist with TRACE from my ws it works fine and produces
>a trce file on impactwx12.

OK, this is exactly what should happen.

>When I go to an SSEC machine and do dataloc.k
>ADD RTNEXRAD IMPACTWX12.UNIV-WEA.COM, and then run the imglist.k with
>TRACE..I get nothing back and no trce file is made on impactwx12.

The fact that a trace file does not get created is what is leading me
to believe that _somehow_ the machine running the Unidata 7.804 server
built with gcc/g77 is denying access to the machine running SSEC McIDAS
that is making requests.  The denial must be coming before any servers
get called otherwise a trace file would be created.

>Just
>to test, I pointed the SSEC machine RTNEXRAD group (we use NEXRAD here
>according to SSEC's standard) at psnldm, NSBF's SPARC running Unidata
>7.803 with SC5.0. and it works fine and a trce file is created on 
>psnldm.

OK, but this could simply mean that psnldm is not denying service to
the workstation on which you were requesting data.

>Here is a snippet trce file created on impactwx12 when I point my
>workstation
>at it..it worked fine.  If you need the whole thing I can send it.

The trace output looks like what I would have expected from a
transaction that worked, so it provides no information useful to the
debugging of the problem you are seeing.  I was hoping that a trace
file would hagve been created when doing the request from a machine
running SSEC McIDAS.  If it had, we would have information about what
went wrong.

>ADIRSERV   1:RTNEXRAD N0R 0 0 AUX=YES TRACE=1 ID=HGX BAND=ALL X^M
>ADIRSERV   1:MASK is^M
>ADIRSERV   1:RTNEXRAD N0R 0 0 AUX=YES TRACE=1 ID=HGX BAND=ALL X
>"NNEXRAD.CFG^M
>nexradir: |RTNEXRAD N0R 0 0 AUX=YES TRACE=1 ID=HGX BAND=ALL X
>"NNEXRAD.CFG|^M
>nexradir:: starting up^M
>nexradir:: dataset descriptor: N0R^M
>nexradir:: configuration file name: NNEXRAD.CFG^M
>GetConfigInfo:: INFO= specified^M
>nexradir:: data directory: /WX/data/ldm/gempak/nexrad/NIDS/\ID/\TYPE^M
>nexradir:: file name mask: \TYPE_*^M
>nexradir:: info file name:^M
>nexradir:: allowed IP mask: *^M
>AllowedAccess:: IP mask does not restrict access^M

This last line shows that you did not limit access to this dataset on
the basis of IP (IP mask: *), so the denial for the other machine is
not coming at this level.

...

So, we leave this with:

1) please do the access tests to the Unidata ADDE server:
   adde.unidata.ucar.edu

   If this works with no problems from both flavors of McIDAS at your
   site, then the problem is specific to your Solaris x86 box,
   configuration like TCP wrappers, or some other thing for which I
   currently have no theory.  At this point:

2) a rebuild using gcc/f2c/mcfc on your Unidata McIDAS-X 7.804 x86 box,
   and a rerun of your tests would be most interesting.

If access from your workstation running SSEC McIDAS fails to our
server, then I will our server at all levels and request that you rerun
tests so I can see exactly where service is being denied.

Tom

>From address@hidden Fri Dec 28 11:44:46 2001
>Subject: RE: 20011227: SSEC McIDAS not able to get data from Unidata McIDAS 
>7.804 ADDE server built with gcc/g77 (cont.)

Tom,

I am off today taking down Xmas decorations, but in short
I am not running TCP Wrappers.  I will perform the tests
tonight and let you know.

Thanks for the help,
Robert

>From address@hidden Fri Dec 28 19:30:37 2001
>Subject: RE: 20011227: SSEC McIDAS not able to get data from Unidata McIDAS 
>7.804 ADDE server built with gcc/g77 (cont.)
 
Tom, 

All of the tests to adde.unidata.ucar.edu worked fine from
two SSEC boxes and from the Solaris x86 gcc/g77 box.

I don't have TCP Wrappers installed but we do have a firewall
that is always running amuck..affecting internal users
as well.  Plus we have a complicated network layout.

I will ask our senior sys admin to look into that aspect..
I never thought about that.  The firewall could
be denying that route.

I will go ahead and build it with f2c as well.

Thanks for your help,
Robert

>From address@hidden Fri Feb  8 09:22:16 2002
>Subject: RE:  20011227: SSEC McIDAS not able to get data from Unidata McID
>       AS 7.804 ADDE server built with gcc/g77 (cont.)

Tom,

I finally found the answer as to why I could not talk via ADDE from an
SSEC McIDAS box to the PC running gcc/g77 Unidata version.   As it
turns out I had used that PC to test a package that Dave Santek had
sent us that will install the SDI card drivers in case we have a
complete hard drive failure on our SDI boxes (almost happened).  When I
did that it changed the mcserv entry in /etc/inetd.conf to point at
/home/mcidas which does not exist now.  I reinstalled mcinet after
uninstalling it and every thing works fine now.  The weird thing is
that my workstation should have not been able to talk to the PC
either..but it could..

Anyway the gcc/g77 version is humming right along, and performance
seems fine.

As you know Sun has solved my OS dilemma..with yesterday's announcement
that was the final nail in the coffin for Solaris Intel, and probably
means they will never have a low-end SPARC that is competetive in
performance.  So I am going to dual boot my Ultra 5 at home with SuSE
SPARC Linux and start boning up.

I still may play around with FreeBSD, but the fact that it is not
supported by GEMPAK is a problem...I haven't asked Steve if he plans to
support it, though.

We have to replace our old Solaris PC at NSBF and right now I don't
know what to do.  I still don't think Linux is stable enough with the
LDM, plus I hate to change OSes on those guys.  OTH the only affordable
SPARC is the Blade 100 which is barely faster than the 4 year old PII
400.  I guess Solaris 8 Intel will have to be the choice, with the
realization that it will have to be replaced.


Robert Mullenax
Weather Systems Administrator
Universal Weather and Aviation