[McIDAS #KFS-793806]: Trouble Installing the McIDAS-X 2005 ADDE Remote Server

Hi Adrianna,

re:
> We are working in getting the Universidad Bolivar connected to Unidata. We
> already installed Mcidas-X, but we got a problem while we were trying to
> install the McIDAS-X 2005 ADDE Remote Server. We hope that you can help us.

> The standard output of the command "uname -a" is:
> 
> SunOS xica 5.10 Generic sun4u sparc SUNW,Sun-Fire-V440

Sun Solaris 5.10 is not officially supported in McIDAS v2005.  However, it does
run under 5.10, and it is possible to run the remote server under 5.10, but the
standard ADDE Remote Server setup does not work... as you have found out.

> When we do the step 4 of the installation guide: "sh ./mcinet2005.sh install
> mcadde", we get the following message:
> 
> bash-3.00# ./mcinet2005.sh install mcadde
> mcinet2005: /etc/services: mcidas already set up
> mcinet2005: /etc/inetd.conf: mcidas already set up
> mcinet2005: telling inetd to reread its configuration
> mcinet2005: waiting for inetd to reread its configuration
> mcinet2005: WARNING: inetd not listening
> Try running the script again in a few minutes.

> Can you tell us what might be wrong?,

This failure is an reflection of the fact that the installation/setup
script for the remote ADDE server does not work under Solaris 5.10.

> We thank you in advanced any feedback you can give us,

In order to get the remote server setup under Solaris 5.10, you
will need to do some steps by hand:

<as 'root'>
- use Solaris 10 utility "inetconv" to convert inetd.conf line to xml

The Solaris 5.10 man page for inetconv explains:

DESCRIPTION
     The inetconv utility converts a file containing  records  of
     inetd.conf(4) into smf(5) service manifests, and then import
     those manifests into the smf repository. Once the inetd.conf
     file  has  been converted, the only way to change aspects of
     an inet service is to use the inetadm(1M) utility.

     There is a one-to-one correspondence between a service  line
     in  the  input  file and the manifest generated. By default,
     the manifests are named using the following template:

     <svcname>-<proto>.xml

     The <svcname> token is replaced by the  service's  name  and
     the  <proto>  token by the service's protocol. Any slash (/)
     characters that exist in the source  line  for  the  service
     name or protocol are replaced with underscores (_).

     The service line is recorded as a property of the  converted
     service.

     During the conversion process, if a service line is found to
     be malformed or to be for an internal inetd service, no man-
     ifest is generated and that service line is skipped.

     The input file is left untouched by the conversion process.

After you use inetconv to convert the entry that the mcinet2005.sh script
put into your /etc/inetd.conf file, you should verify that the service
has been correctly added.  You can do this in two ways:

- verify that the XML encoded manifest file was created in 
/var/svc/manifest/network
  and named mcidas-tcp.xml

- use the 'svcs' command to list out the service status

On a Solaris x86 5.10 system we run McIDAS on here in Unidata, 'svcs | grep 
mcidas' yields
the following output:

  % svcs | grep mcidas
  online         Apr_11   svc:/network/mcidas/tcp:default

The contents of our same machine's McIDAS manifest file is:

<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM 
'/usr/share/lib/xml/dtd/service_bundle.dtd.1'><!--
    Service manifest for the mcidas service.

    Generated by inetconv(1M) from inetd.conf(4).
-->

<service_bundle type='manifest' name='inetconv:mcidas'>

<service
        name='network/mcidas-tcp'
        type='service'
        version='1'>

        <create_default_instance enabled='true'/>

        <restarter>
                <service_fmri value='svc:/network/inetd:default' />
        </restarter>

        <!--
            Set a timeout of 0 to signify to inetd that we don't want to
            timeout this service, since the forked process is the one that
            does the service's work. This is the case for most/all legacy
            inetd services; for services written to take advantage of SMF
            capabilities, the start method should fork off a process to
            handle the request and return a success code.
        -->

        <dependency name='net-physical'
                grouping='require_all'
                restart_on='none'
                type='service'>
                <service_fmri value='svc:/network/physical' />
        </dependency>

        <exec_method
                type='method'
                name='inetd_start'
                exec='/home/mcidas/bin/mcservsh -H /home/mcidas'
                timeout_seconds='0'>
                <method_context>
                        <method_credential user='mcidas' group='mcadde' />
                </method_context>
        </exec_method>

        <!--
            Use inetd's built-in kill support to disable services.
        -->
        <exec_method
                type='method'
                name='inetd_disable'
                exec=':kill'
                timeout_seconds='0'>
        </exec_method>

        <!--
            This property group is used to record information about
            how this manifest was created.  It is an implementation
            detail which should not be modified or deleted.
        -->
        <property_group name='inetconv' type='framework'>
                <propval name='converted' type='boolean' value='true' />
                <propval name='version' type='integer' value='1' />
                <propval name='source_line' type='astring' value=
'mcidas stream tcp nowait mcadde /home/mcidas/bin/mcservsh mcservsh -H 
/home/mcidas'
                />
        </property_group>

        <property_group name='inetd' type='framework'>
                <propval name='name' type='astring' value='mcidas' />
                <propval name='endpoint_type' type='astring' value='stream' />
                <propval name='proto' type='astring' value='tcp' />
                <propval name='wait' type='boolean' value='false' />
                <propval name='isrpc' type='boolean' value='false' />
        </property_group>

        <stability value='External' />

        <template>
                <common_name>
                        <loctext xml:lang='C'>
mcidas
                        </loctext>
                </common_name>
        </template>
</service>

</service_bundle>


The other thing you will need to be concerned about is that port 112 access be
opened on this machine through any firewalls (all remote access to the ADDE 
server
will be done using port 112).

Please keep me informed about your configuration results.



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: KFS-793806
Department: Support McIDAS
Priority: Normal
Status: Closed