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

[McIDAS #AIN-927620]: diagnosing issue with ADDE server



Hi Robert,

re:
> I am having trouble trying to figure out (and where to look for clues) why
> I can't share out data via ADDE.  This is between 4 machines running McIDAS
> 2006 and Solaris 10 x86.  The machine I want to share data from (the server)
> is wxmcidas.csbf.nasa.gov.  I have ran the mcinet2006.sh script as root using
> user mcadde as usual, and also as usual the script won't restart inetd on
> Solaris 10.  I have to manually do svcadm stop inetd and then svcadm start 
> inetd.

The _real_ problem is that configuring remote ADDE access on Solaris 10 is not
supported in McIDAS v2006, and I don't know if it will be supported in v2007.
Basically, mcinet2006.sh understands how to configure inetd through inetd.conf
and xinetd through entries in the /etc/xinetd.d directory.  It does not know
how to generate the XML configuration needed by the svcadm utility on Solaris
10.

> After doing thisI go to my other machines and make DATALOC entries to that 
> machine
> but cannot access anything there.  This is both through a firewall and also 
> behind
> the firewall on a private network.  On the private network I am also 
> accessing data
> on the same machine (wxmcidas) using NFS for GEMPAK so access to the machine 
> is no
> issue.  I suspect that ADDE server is not running on wxmcidas.

We struggled with configuring ADDE on Solaris 10 also.  Quite frankly, we were 
told
what was needed by one of our users, Eirh-Yu Hsie of CU/CIRES/NOAA.  Here is a
snippit of a conversation that Hsie and I had regarding setting up ADDE access
on Solaris 10:

me to Hsie: How did you setup the Solaris 10 services on hail?

>I use Solaris 10 utility "inetconv" to convert inetd.conf line to xml
>file. Then use "svccfg" to import the xml file into smf service.

This should create the file:

/var/svc/manifest/network/mcidas-tcp.xml

After getting the inetd.conf definition into the needed XML file, the
service can be turned on/off using 'svcadm'.

Now, the problem we ran into was we were using an early version of
Solaris 10, in which the inetconv utility did not appear to function
correctly, and in which the parameters needed to be passed to 
~mcidas/bin/mcservsh
were not being passed.  It is possible that you may be running into
the same sort of problem (but this should not be the case if your
installation of Solaris 10 is fully patched.

So, the first question is if you knew of the need to convert the inetd.conf
entry created by mcidas2006.sh using inetconv?

If yes, have you looked at the XML file produced to see if it looks
OK?

If yes to both of the above, you can always edit ~mcidas/bin/mcservsh (a
Korn shell script) and put in something that will cause ASCII text to
be sent back to the requesting process.  For instance, set up your
client to do an uncompressed transfer and modify mcservsh on the server
to do an 'echo' of some phrase.  Then do a DSINFO I to the server
from the client and see what comes back.  It was by doing things like
this that I discovered that parameters were not being passed to mcservsh
by the inetd replacement service.

Please let me know the results of your testing.


> Thanks,
> Robert Mullenax
> CSBF Meteorology
> 
> 
> 
> 

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: AIN-927620
Department: Support McIDAS
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.