20021022: Setting up LDM for McIDAS-XCD (cont.)

>From: Richard Massa <address@hidden>
>Organization: UC Davis
>Keywords: 200210150109.g9F19F112387 McIDAS-XCD LDM

Richard,

re: using 'chmod g+rw'
>No, that's why I used it in this case, it would only grand g+rw permissions to
>something that didn't have it, it wouldn't take others away.  That syntax is
>sometimes more useful than octal permissions because of this feature, IMHO.

I agree.

re: missing files
>Strange I'm seeing these files in the ~mcidas/bin directory...  Is that where
>they are supposed to be?  

I would have _never_ looked in ~mcidas/bin!!!!!

OK, so I just looked in ~ldm/decoders/xcd_run and see what is going on.
You defined MCPATH to be:

MCPATH=$MCHOME/bin:${MCDATA}:$MCHOME/data:$MCHOME/help

It should be defined as

MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/help.

The MCPATH variable is a list of directories that McIDAS searches when
looking for data and ancillary data files, not executables.  The
correct construct for the environment variable defines in the copy
of xcd_run used by the LDM is:

MCHOME=/home/mcidas
MCDATA=$MCHOME/workdata
MCLOG=$MCDATA/XCD_START.LOG
MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/help

I just made this change and stopped the LDM:

<as 'ldm'>
ldmadmin stop

I then moved all of the misplaced files from ~mcidas/bin to ~mcidas/workdata:

<as 'mcidas'>
cd ~mcidas/bin
mv DECOSTAT.DAT GRIBDEC.PRO DCLSTIDX.PTR *.IDM *.ERR ALLOC.WWW ~mcidas/workdata

After all of that, I restarted the LDM:

<as 'ldm'>
ldmadmin start

Now, everything looks good.  Yahoo!

The very last bit of cleaning up I did was delete the McIDAS string MCDATA:

<as 'mcidas'>
cd workdata
td.k MCDATA

This is not used in any of the Unidata McIDAS installation/configuration,
so I figured that it would be better to delete it so its existence won't
be misconstrued.

Now that XCD decoding is apparently working correctly, I would like to
move onto a different topic.

I noticed that your Slackware system uses xinetd instead of inetd.  This
matches the move of RedHat from inetd to xinetd.  What is different about
your setup, however, is in the specification of xinetd configuration.

On RedHat 7.x, 8.x, one typically configures xinetd by adding files to
the /etc/xinetd.d directory.  The file /etc/xinetd.conf references those
files as follows (listing taken from a system running RedHat 7.1 Linux):

% cd /etc
% cat xinetd.conf
#
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/

defaults
{
        instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success          = HOST PID
        log_on_failure          = HOST
        cps                     = 25 30
}

includedir /etc/xinetd.d

The entries in /etc/xinetd.d look like:

% ls xinetd.d
amanda       daytime-udp    imap          klogin         rlogin        telnet
amandaidx    echo           imap.rpmnew   krb5-telnet    rsh           tftp
amidxtape    echo-udp       imaps         kshell         rsync         time
chargen      eklogin        ipop2         linuxconf-web  servers       time-udp
chargen-udp  finger         ipop2.rpmnew  ntalk          services      wu-ftpd
comsat       finger.rpmnew  ipop3         pop3s          swat.rpmsave
daytime      gssftp         ipop3.rpmnew  rexec          talk

Did you setup your /etc/xinetd.conf file the way it stands now, or was
this done by the mcinet2002.sh script?

Also, I took a look in your /etc/services file and see that there are
conflicts for ports 112, 500, and 503.  The standard entry for port
112 _is correct_.  The McIDAS mcinet2002.sh script should not redefine
this as mcidasz.

Even so, you (as 'root') should comment out these entries:

mcidas          112/tcp    #McIDAS Data Transmission Protocol
mcidas          112/udp    #McIDAS Data Transmission Protocol

Next, SSEC adopted the use of ports 500 and 503 even though they had
not registered these ports for their use.  Given this, there is a
conflict for both of these in your services file:

isakmp          500/tcp
isakmp          500/udp

intrinsa        503/tcp
intrinsa        503/udp

In order for McIDAS ADDE to work properly, you need to comment out these
entries also.

You should leave the entries that mcinet2002.sh added:

mcidasz         112/tcp # McIDAS ADDE zcompress port
mcserv          500/tcp # McIDAS ADDE port
mccompress      503/tcp # McIDAS ADDE compression port

These are needed by ADDE.

After making changes to /etc/services, you will need to send a HUP signal
to the xinetd process so that it rereads the file.

Tom

>From address@hidden Tue Oct 22 17:13:01 2002

re: addition of $MCHOME/bin to beginning of MCPATH in xcd_run
>Ack... silly me...  I did that because I saw error messages indicating that it
>couldn't find some executables which were in the ~mcidas/bin directory...  It
>didn't fix the problem, but I never changed it back...  I'm so sorry for 
>wasting so much of your time.

re: Slackware's use of xinetd
>I actually use xinetd because I like it better... slackware 8.1 by default uses
>inetd.

re: Did you setup your /etc/xinetd.conf file the way it stands now, or was
>Yes I did.  I don't like redhat's silly directory thing, it makes it a lot more
>annoying to tune things by hand (but by now with my mcidas problems I probably 
>have you convinced that I shouldn't be tuning things by hand :))

re: > this done by the mcinet2002.sh script?

>I ran the mcinet2002.sh script, and I think it added the entries to inetd, 
>which I then converted to the xinetd format and stuck in my xinetd.conf file.

>That reminded me of a pitfall that I ran into when setting up mcidas.  There's
>a program also named mcserv that is the midnight commander server, and somehow
>the mcservsh script or the mcidas environment setup that I have set up
>executed that program (previously located in /usr/bin) instead of mcidas's
>mcserv, causing programs like dataloc to complain about bad options to mcserv.
>I banged my head on this for a while...  it might be useful to add to your
>errata file if you have one...

re: conflict for ports 112, 500, and 503 in /etc/services

>Hmm... I should have checked that...  I think I copied it from an old setup
>on the old (broken) mcidas server when things weren't working right...

re: After making changes to /etc/services, you will need to send a HUP signal
to the xinetd process so that it rereads the file.

>Done...  Thanks for your help...