20011213: setup of ldm-mcidas, LDM, XCD, and McIDAS at COFC (cont.)

>From: "James R. Frysinger" <address@hidden>
>Organization: College of Charleston
>Keywords: 200111061842.fA6Igt112242 LDM binary install

Jim,

re: sending chatter from cron-initiated scripts to /dev/null

>       Yep, that'll keep the chatter down on the wires! That /dev/null has 
>got to be one of the niftiest gadgets in *nix. I vaguely remember 
>something like it in Fortran IV back in the '60s. (Yep, I was there!)

Since the message is informational but not necessary, dumping the
output does not affect you.

re: X permissions

>       No, I had logged on as myself (jim) and had su'd to mcidas. That may 
>have been what unglued the X-windows permission. At any rate....

OK, so all you had to do was an 'xhost + <your machine name> from a
'jim' xterm.

re: recommended order of make, etc. when changing 'mcidas' group

>       I did the stuff below:

OK.

>       This worked like a champ. I hadn't done the 'make install.all' before 
>because I hadn't done 'make uninstall.all'.

A 'make install.all' actually does a 'make uninstall.all'.  My ordering was
for the 'make uninstall.all' to be done before changing the group to which
'mcidas' belonged.  This way you would own the files that had to
be removed at every step.

>Maybe I should have. Other 
>differences this time were that before I had su'd in as mcidas and had 
>done the build.

After the group stuff is all cleared up, this wouldn't be a problem as
long as the su was an 'su -' (inherit environment).

>Another, but I'm sure this was not the problem, was 
>that mcidas had been running with a gnome dtm. I changed it to KDE 
>since I had found that the gnome desktop hangs on logout for some 
>reason.

I have not seen this on any Linux box I run Gnome on, nor have I heard
this (that I can recall) from any Linux user).

>I use KDE for all my other stuff here anyway and had put gnome 
>in just to try it out.

So, did McIDAS work OK on KDE?  The reason I ask is that I ran into a
problem trying to run McIDAS under KDE in RedHat 7.1 on Dell machines
during my last workshop.  Gnome, on the other hand, worked flawlessly.

>       So, let's see what the next phase here is. As I see it, I should log 
>on as mcidas and install the distribution by doing
>       cd ~mcidas/mcidas7.8/src
>       make install.mcxall
>noting from my scan of makefile that install.mcxall does stuff beyond 
>what install.all does. (What a misnomer!)

Actually, an 'make install.all' installs everything:

install.all       : install.mcxall    install.xcdall

This rule in 'makefile' says that an 'install.all' is the combination of
an 'install.mcxall' and 'install.xcdall'.  If you run 'make install.all'
you have nothing left to install.

>Then I should skip the 
>section on uninstalling previous versions of mcidas since there aren't 
>any onboard.

If there is no existing installation, a 'make uninstall.all' is not
needed.  Again, the commentary in my previous email was to uninstall
everything before changing the group of 'mcidas'.  This would be
necessary since the McIDAS files might not have been previously
installed with write permission (which translates into delete) for
users not in the same group.  So, the idea was to clean up first; then
change the group of 'mcidas'; then change the file permissions to match
the new group; and then to rebuild and install.  All of this is
not needed for folks that don't change the group of 'mcidas' after
setting up the account and grabbing a distribution.

>       Next is to install ADDE.

You only have to install the ADDE remote server stuff if you are going
to allow remote machines to use yours as a McIDAS data server.  If
your machine is only to be used to view data off of other machines,
you co not have to do the ADDE installation.

>I should logon as root and cd to ~mcidas. 
>I've already done the 'grep mcserv /etc/services' and got
>       mcserv          500/tcp      # McIDAS ADDE port
>for an output, as before (~Nov 19). Then do
>       sh ./mcinet7.8.sh install mcadde
>since I don't have any previous versions of mcadde to remove.

If your Linux box uses inetd (used to be a given, now it is not), and if
you had previously installed the ADDE remote server stuff (entries in
/etc/services and /etc/inetd.conf), then you could either do nothing
(as things are already setup - unless you changed the home directory for
'mcidas' or 'mcadde') or you should uninstall and then reinstall
the ADDE stuff:

su - root
cd ~mcidas
sh ./mcinet7.8.sh uninstall mcadde
sh ./mcinet7.8.sh install mcadde

This makes things nice and neat.

>I suppose 
>the reason I have to do this as root is for the sake of permissions 
>that get assigned to the files, etc. that result.

/etc/services and /etc/inetd.conf are owned by root.  Other users should
_not_ have write permission _ever_.  This is why you have to be root.

>       The notes talk about linux differences from unix and talk about inetd 
>being replaced by xinetd in RH 7.x and above. Well, SuSE linux distro 
>has both inetd (and inetd.conf) and xinetd (and xinetd.conf) in /etc. 

Ouch.  You are in new, uncharted waters here!

>The xinetd.conf file contains _sections_ that look like the "service" 
>files the note says to install in /etc/xinetd.d (a directory which SuSE 
>doesn't have).

The setup in RH 7.x is for a /etc/xinetd.conf configuration file what
has an entry that points to/looks in an /etc/xinetd.d directory
for configuration stuff.  The main difference in the setups is that
one creates files for each service definition in /etc/xinetd.d in
RH 7.x while /etc/inetd.conf has lines that define services.  Debian
Linux still uses the inetd approach.  As far as I knew, RH was the only
distribution that had moved to use of xinetd.  From what I read and
my limited experience, the xinetd approach is much more configurable.

>The simple minded approach then would be to paste those 
>prescribed file contents into xinetd.conf as additional sections. 

Not in RH 7.x.  /etc/xinetd.conf looks like:

#
# 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 last line (includedir) tells xinetd to look in /etc/xinetd.d for
configuration files.  I guess one could put configuration sections
in xinetd.conf, but I have never done this, so I can't say for sure.

>However, inetd.conf is not to be forgotten. It contains lines in the 
>format (read as one line)
>   <service_name> <sock_type> <proto> <flags> <user> <server_path> 
><args>
>and here are the (5) active lines currently in that file:
>
>   ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd
>
>   telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
>
>   uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l
>
>   mcserv  stream  tcp     nowait  mcadde  /home/mcidas/bin/mcservsh    
>   mcservsh -H /home/mcidas
>
>   mccompress      stream  tcp     nowait  mcadde  
>/home/mcidas/bin/mcservsh       mcservsh -H /home/mcidas

The fact that /etc/inetd.conf is there seems to say that your system is
using inetd, not xinetd.

>       I think the last two lines were from my November installation and I 
>think I decided to try just ignoring the RedHat note since I still had 
>an inetd.

Yes, this would be from your previous installation of the ADDE remote server
stuff.

>Of course, I never got as far as seeing if ADDE here worked. 

And you typically wouldn't need to especially if your machine is not
going to host any datasets.

>What do you think? Belt and suspenders?

I would take the practical approach: do you want your home machine to
be able to host datasets that will be accessed from other machines or
to other accounts on the same machine?  If no, don't bother with the
ADDE remote installation stuff.  If yes, you have to figure out
what exactly is being used, inetd or xinetd.  I am betting on inetd,
and if I am right, your installation of the ADDE remote server stuff
is finished.

>Or would they just get tangled 
>up. I guess I could add those sections to xinetd.conf and then comment 
>them out (or remove them) if things get wedged.

I would first try out the inetd setup:

o make sure that ~mcidas has a properly configured .mcenv file
o make sure that the 'mcidas' account has setup the TOPO
  dataset.  To see what you setup, run:

  DSSERVE LIST

  If you don't see TOPO defined there, run:

  BATCH TOPOADDE.BAT

o point your session to look for TOPO from the ADDE remote server on
  your machine:

  DATALOC ADD TOPO <your full machine name or IP address>

o see if you can list out the contents of TOPO using the remote ADDE
  server:

  DSINFO IMAGE TOPO

  If this hangs, the ADDE remote serving is not working.  This may or
  may not be due to system use of inted vs xinetd.  Since I have
  no experience on systems with both, I can't offer you any sage words
  of advice.

>By the way, a 'ps -e' 
>shows inetd running but 'ps -eafx | grep xinetd' does, with about a 
>zillion services running on that pid.

Ouch!  I don't know what this means.  Perhaps inetd "stuff" gets run
by xinetd on SuSe!?

>Of course, if I add those 
>sections to xinetd.conf, I would then do
>       ps -eafx | grep xinetd
>       kill -USR1 <pid_of_xinetd>

Do a 'man xinetd' first and see what it has to say.

>       After that should come, I suppose, the next section of steps:
>   1.Configuring the mcidas Account

I thought you had already done this.  The recommended order of installation
is to setup the mcidas account first.

>   2.Configuring User Accounts

Yup.

>   3.Configuring McIDAS-X Sessions with .mcidasrc

Run 'mcidas config' so that .mcidasrc is created.  You can then read
through the web pages and .mcidasrc itself to see all of the things
that could be mucked with (lots).  Just remember that the GUI
startup of Unidata McIDAS only uses a subset of what can be done
in .mcidasrc.  If you make significant changes in .mcidasrc, ones that
are not configurable through the GUI startup, then you will need to
start McIDAS using 'mcidasx', not mcidas.

>   4.Registering MD File Schemas
>but we can make that the topic of conversation of the next exchange.

Only needed if you are going to be ingesting and decoding data.  If
this machine is going to be a client only, you can stop at 3.

Tom

>From address@hidden Sat Dec 15 17:08:39 2001

Tom,

Pop the top on a cold bottle of Vernor's Ginger Ale.

McIDAS is running not only at the College of Charleston, on 'weather', 
but also on my machine at home for user jim. I can pull up data from 
weather.cofc.edu and display it here faster than I can display it 
locally while sitting on 'weather'! The extra time to get the data via 
the wire is more than compensated for by my processing time here at 
home, as compared to our SunSPARC. Now I can do some studies of sea 
breeze propogation speeds, conditions, and storm-severities! What this 
tells me is that the machine running LDM and ADDE doesn't need to be 
all that swift. User machines are where the speed counts. I think I'll 
pour myself a second ginger ale.

Let me take this opportunity to clean up some hanging questions and 
perhaps to provide you with some useful data.

re: xhost

> >     No, I had logged on as myself (jim) and had su'd to mcidas. That
> > may have been what unglued the X-windows permission. At any
> > rate....
>
> OK, so all you had to do was an 'xhost + <your machine name> from a
> 'jim' xterm.

        I did that and it didn't work. But I did some experimenting and 
eventually made it work. Let me elaborate. I have already sent you a 
copy of the bash equivalents of the setenv statements one enters to 
test the mcidas installation as mcidas. In that set, there was a 
statement
   export DISPLAY=0.0
and I kept getting refused permission to use it. It had worked when 
mcidas and jim were in group users but not when in group weather. I 
tried various arguments for xhosts that were suggested by the man page 
but the only one that ran was the one you suggested
   xhost + metric.metricmethods.com
Yet, I still could not launch mcidas and have it display. I got the 
following complaint:
   Xlib: connection to "0:0.0" refused by server
   Xlib: Client is not authorized to connect to Server
   Error: Can't open display: 0:0
   mcidas@metric:~ > Xlib: connection to "0:0.0" refused by server
   Xlib: Client is not authorized to connect to Server
   Error: Can't open display: 0:0
which includes the normal (and expected) warning statement. The warning 
statement of course told me that the program launched but the two 
complaints were obviously related to attempts to open the two windows. 
Then, I tried changing the DISPLAY value with
'   export DISPLAY=:0
and things changed. I got
   mcidas@metric:~/data > mcidas
   Error in startup script: can't read "readlist": no such variable
    while executing
   "return $readlist"
    (procedure "fileToList" line 35)
    invoked from within
   "fileToList $mcrcfile"
    (procedure "readMcidasrc" line 105)
    invoked from within
   "readMcidasrc "$home/.mcidasrc""
    (file "/home/mcidas/bin/mcidas" line 598)
I tried 
   mcidas@metric:~/data > mcidas config
as well and got the same results. However, I was successful with
   mcidas@metric:~ > mcidasx
and was able to do all the configuration that was needed. The only 
glitch occurred later, on my old friend
   BATCH "LOCDATA.BAT
which produced the errors I saw last month. Yep, BOB had suffered a 
bifocal attack and had skipped the line about configuring LOCDATA.BAT. 
I went back and did that and everything from that point on worked. No 
ginger ale for BOB.

        I configure the account for user jim and successfully launched with 
the command
   mcidas config
and then after that with just 'mcidas'. Then I sat there and had a lot 
of fun for a couple of hours just enjoying my installation.

re adde:

> >     Next is to install ADDE.
>
> You only have to install the ADDE remote server stuff if you are
> going to allow remote machines to use yours as a McIDAS data server. 
> If your machine is only to be used to view data off of other
> machines, you co not have to do the ADDE installation.

        I went ahead and did that just to see if it would work on my SuSE 
distribution. After all, we might get some PC boxes and downtown and it 
would be nice to know information. I had absolutely no problems doing 
the ADDE installation _without_ using the special linux steps.

re inetd/xinetd:

        The question was does SuSE linux come with inetd or xinetd and which 
does/can it use? The answer is yes. SuSE linux comes with both inetd 
and xinetd. In /etc/rc.config, there are two switches:
   START_INETD:"yes"
   START_XINETD:"no"
One is marked "yes" and one is marked "no"; do not mark both of them 
the same way! The user gets to decide which one to use and this can be 
changed with SuSE's YAST2 (system administration tool). I have mine set 
as above; I use inetd instead of xinetd. In other words, I did:
   su - root
   cd ~mcidas
   sh ./mcinet7.8.sh uninstall mcadde
   sh ./mcinet7.8.sh install mcadde

Should a SuSE linux user decide to use xinetd, then note the following:
> >The xinetd.conf file contains _sections_ that look like the
> > "service" files the note says to install in /etc/xinetd.d (a
> > directory which SuSE doesn't have).
Here's a small section from that file (in my case, an unused file):
 [preamble]
 # If you want to enable one of the following services, you only have to
 # comment it out. After that, send SIGUSR1 to xinetd to force a
 # reload of it's configuration
 #

 #       disabled        = ftp
         disabled        = rstatd
 #       disabled        = telnet
         disabled        = shell
 #       disabled        = login
         disabled        = finger
         disabled        = pop3
         disabled        = comsat
         disabled        = ntalk
         disabled        = talk
         disabled        = discard
         disabled        = chargen
         disabled        = daytime
         disabled        = time
         disabled        = echo
         disabled        = daytime
         disabled        = time
         disabled        = smtp
         disabled        = ident

 }

 ##
 ## Now the definitions of the different services
 ##
 ##

 service ftp
 {
 #
 # Because we use wu.ftpd, we set instances to UNLIMITED.
 # wu.ftpd manages the amount of users himself.
 #
         socket_type     = stream
         protocol        = tcp
         wait            = no
         user            = root
         server          = /usr/sbin/in.ftpd
 #       server_args     = -a
         instances       = UNLIMITED
 } 
 


 service telnet
 {
         socket_type     = stream
         protocol        = tcp
         wait            = no
         user            = root
         server          = /usr/sbin/in.telnetd
         server_args     = -n
 #       only_from       = localhost
         no_access       =
 }


 service shell
 {
         socket_type     = stream
         protocol        = tcp
         wait            = no
         user            = root
         server          = /usr/sbin/in.rshd
         server_args     = -L
 }
 [etc.]
So, you can see that SuSE's xinetd uses one file (/etc/xinetd.conf) 
with a section for each service in contrast to Red Hat's directory 
/etc/xinet.d containing individual files that are read by its 
/etc/xinetd.conf file. Of course, SuSE users that elect to use inetd 
instead of xinetd can use the standard ADDE installation technique. I 
hope this information helps you folks in writing something to help SuSE 
users in the installation process.

        I did the following and it worked fine:
> o make sure that ~mcidas has a properly configured .mcenv file
> o make sure that the 'mcidas' account has setup the TOPO
>   dataset.  To see what you setup, run:
>
>   DSSERVE LIST
>
>   If you don't see TOPO defined there, run:
>
>   BATCH TOPOADDE.BAT
>
> o point your session to look for TOPO from the ADDE remote server on
>   your machine:
>
>   DATALOC ADD TOPO <your full machine name or IP address>
>
> o see if you can list out the contents of TOPO using the remote ADDE
>   server:
>
>   DSINFO IMAGE TOPO
>
>   If this hangs, the ADDE remote serving is not working.  This may or
>   may not be due to system use of inted vs xinetd.  Since I have
>   no experience on systems with both, I can't offer you any sage
> words of advice.

re KDE:

> >I use KDE for all my other stuff here anyway and had put gnome 
> >in just to try it out.
>
>
> So, did McIDAS work OK on KDE?  The reason I ask is that I ran into a
> problem trying to run McIDAS under KDE in RedHat 7.1 on Dell machines
> during my last workshop.  Gnome, on the other hand, worked flawlessly.

        Yep!!!! It works mighty fine! BTW, I am using SuSE distro 7.2 with 
kernel 2.4.4 and KDE 2.1.2.

        Time for me to go cook supper before the natives stage an uprising. 
I've still got time for another Vernor's before we sit down. And my 
grades are all in.

        I'm sure that I'll still be coming up with some questions, Tom, but 
you've gotten me through the hard part on two different platforms. Many 
thanks!

Jim

-- 
James R. Frysinger                  University/College of Charleston
10 Captiva Row                      Dept. of Physics and Astronomy
Charleston, SC 29407                66 George Street
843.225.0805                        Charleston, SC 29424
http://www.cofc.edu/~frysingj       address@hidden
Cert. Adv. Metrication Specialist   843.953.7644