20010926: [Fwd: [Fwd: Re: prolbem with point data reading (fwd)]]

>From: Tom Whittaker <address@hidden>
>Organization: SSEC
>Keywords: 200109261738.f8QHc7117319 McIDAS ADDE mcadde

Tom,

>Below is some correspondence from Rick Kohrs and Dave Santek regarding the
>running of the ADDE servers.  Perhaps I misunderstood what Jim told me
>yesterday (that ADDE servers could only be run from the ~mcidas account and
>that's why you had to move the source code into this account and compile).
>
>I had sent a note in response to one from Dave Santek about this, and put the
>"It would be a good idea..." at the bottom...you can read what they wrote.
>
>Was I wrong?

Here is the story on setting up the remote ADDE server.

1) 'root' runs the mcinetX.Y.sh script to setup /etc/inetd.conf and
   /etc/system entries.  mcinetX.Y.sh ascertains the home directories
   for the user specified on its command line and for 'mcidas'.
   Entries are written to /etc/inetd.conf that use the home directory
   information for these users.  Here is an example:

   <as root>
   sh mcinet7.8.sh install mcadde

   This says to setup the /etc/inetd.conf entry to run as the user 'mcadde'.
   It also will setup the '-H' flag using the home directory of 'mcadde'.
   Here is what these may look like if the home directory of 'mcidas'
   is /home/mcidas and the home directory of 'mcadde' is /home/mcadde:

mcserv  stream  tcp     nowait  mcadde  /home/mcidas/bin/mcservsh       
mcservsh        -H /home/mcadde
mccompress      stream  tcp     nowait  mcadde  /home/mcidas/bin/mcservsh       
mcservsh        -H /home/mcadde

2) the way ADDE works is as follows:

   a) an interrupt is received on a port like 500 or 503

   b) inetd uses the information in /etc/inetd.conf and /etc/services
      to determine what to start and as whom.  In our example
      /home/mcidas/bin/mcservsh is run as the user 'mcadde'.

      A comment here:  the copy mcservsh that is setup to be
      run is the one that lives in the ~mcidas/bin directory.  One
      can override this by setting McINST_ROOT before running
      mcinetX.Y.sh, but you wouldn't know this unless you read
      the source for mcinetX.Y.sh (at least, it is not mentioned
      in the 'Installing the McIDAS-X 7.8 ADDE Remote Server' of
      the McIDAS User's Guide).

   c) the copy of mcservsh that gets run by inetd internally defines
      the environment variable McINST_ROOT.  The value of this McINST_ROOT
      gets set when McIDAS is installed.

   d) mcservsh checks to see if there was an '-H' flag on its invocation
      command line.  If there was, the value of it is used to set the
      internal environment variable HOME.  Then, mcservsh checks to see
      if $HOME/.mcenv exists.  If it does, settings defined there are
      read in.  One might, at this point, assume that PATH could be
      set so that a particular distribution of McIDAS could be run,
      but this is not really the case.  This is the point where things
      get really confusing to the power users that are trying to do
      something out of the ordinary.

   e) the last thing that mcservsh does is exec $McINST_ROOT/bin/mcserv.
      Again, this will be the copy of mcserv that was installed with
      the version of McIDAS that was installed in the 'mcidas' account.

   f) mcserv takes it upon itself to PREpend the following directories
      on any existing PATH that is in effect:

      ~/bin:~/mcidas/bin:~mcidas/bin

      The PATH that might be existing is the one that the user could
      have setup in .mcenv.  This means that a user could have merrily
      setup PATH stuff in .mcenv _thinking_ that it would determine what
      version of McIDAS executables would be used from that point on.
      The problem is that it _won't_!  What will be used peferentially
      is the stuff in ~/bin, ~/mcidas/bin, and/or ~mcidas/bin.  This
      is counter intuitive to me!

      To reinforce the point, IF a different version of McIDAS was installed
      under the account that was setup to run the remote ADDE server
      (mcadde in this example), it would be used in preference to the
      copy installed in ~mcidas/bin.  In this case, we would be using
      mcservsh and mcserv from a different version of McIDAS than
      the servers that will eventually be run by mcserv.  The good
      news here is that mcservsh and mcserv have not changed in quite
      a few versions of McIDAS.  The bad news is that not all executables
      being used are from the same release.

   g) next, mcserv decides which server is supposed to be run and it
      then execs it.

   h) the primary ADDE server execed by mcserv might find that it needs
      to exec a secondary server

   i) and so on...

The key issue in dealing with the CIMSS setup was that Jim N. installed
7.801 executables somewhere different than ~mcidas/bin, and he thought
that the 7.801 executables were being used.  Don was running code
that was getting stuff back from the server mdksserv, and the information
coming back was bad.  The reason that it was bad was that the code being
run was the SSEC version of mdksserv, a version that did not have the
needed fix applied to it.

The solution to Jim's problem could be had in three different ways:

1) update his 7.7 McIDAS installation to the very latest 7.70x addendum
   (this would work 'cause the latest 7.70x addendum had the fix for
   mdksserv)

2) make a link from ~mcadde/bin to where his 7.801 binaries were installed

3) make a link from ~mcadde/mcidas/bin to where his 7.801 binaries
   were installed

Jim was under the impression _and I was also until I actually read the
source for mcserv.cp_ that one could change which version of McIDAS
would be used by changing the /etc/inetd.conf entries manually (and
sending a HUP to inetd).  This does not work.  After I learned this
some time ago, I figured that I should be able to change which version
of McIDAS binaries would be used by changing the PATH setting in
the ~mcadde/.mcenv file.  This also does not work.  The only way that
one could determine that a different version of McIDAS could be used
by the remote server is to read the source code for mcserv.cp.  Just
how many people will do this?

As to Dave's comment:

"The PATH variable for the mcadde account determines where to look for
the servers."

I do not think that this is the case given that mcserv prepends
PATH settings with ones it creates.

So, now you know the REST of the story :-)

>Dave Santek wrote:
>> 
>> Rick Kohrs wrote:
>> 
>> > > It would be a good idea to allow the ADDE servers to be run
>> > > out of some account other than ~mcidas...
>> > >
>> > > --
>> > > Tom Whittaker (address@hidden)
>> > > University of Wisconsin-Madison
>> > > Space Science and Engineering Center
>> > > Phone/VoiceMail: 608/262-2759
>> > > Fax: 608/262-5974
>> >
>> > Tom,
>> >
>> > You can run the servers from any directory you want.  The PATH variable
>> > for the mcadde account determines where to look for the servers.  Sym
>> > links are also a possibility.  You have to tell inetd an account, we use
>> > mcadde.  So we are limited in the flexibility due to unix.  I suppose
>> > for another test, you could have swap different inetd configurations
>> > (one for mcadde and another for mcaddetest).  You'll need root access to
>> > do this.
>> 
>> In   /etc/inetd.conf
>> 
>> dave
>> 
>> >
>> >
>> > Rick
>
>-- 
>Tom Whittaker (address@hidden)
>University of Wisconsin-Madison
>Space Science and Engineering Center
>Phone/VoiceMail: 608/262-2759
>Fax: 608/262-5974

Tom
--
+-----------------------------------------------------------------------------+
* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*
+-----------------------------------------------------------------------------+