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

20010731: setting up McIDAS user accounts (cont.)

>From: "Wayne Bresky" <address@hidden>
>Organization: Cornell
>Keywords: 200107312125.f6VLPs113024 McIDAS DATALOC DSSERVE /etc/hosts

Wayne,

re: removing DSSERVE definitions for datasets you don't have
>I'll do as you suggest.

OK.

re: please check mcadde setup and permissions on ~mcidas/mcidas/data
>Here is output from /etc/passwd
>
>mcidas:x:502:1000::/usr/local/mcidas:/bin/csh
>mcadde:x:503:1000::/usr/local/mcidas:/bin/false
>
>and the permissions on the ~mcidas/mcidas/data directory:
>
>drwxrwxr-x    2 mcidas   Unidata      4096 Jul 26 16:19 data
>
>So, mcadde should be able to write to the directory.

These look good.

re: do you get the error with DSINFO
>The DSINFO command is failing as well.

>[wysocki@cloudcover wysocki]$ dsinfo.k POINT RTPTSRC
>    No Datasets found of Type: POINT in Group: RTPTSRC
>DSINFO -- done

OK, this is consitent at least.

re: what kind of security is in force on cloudcover
>Only ssh is turned on at this point.  I did not install any firewalls or TCP
>wrappers.
>
>[mcidas@cloudcover ~/mcidas]$ cat /etc/hosts.allow
>#
># hosts.allow   This file describes the names of the hosts which are
>#               allowed to use the local INET services, as decided
>#               by the '/usr/sbin/tcpd' server.
>#
>sshd:   ALL
>
>/etc/hosts.deny looks like:
>
>[mcidas@cloudcover ~/mcidas]$ cat /etc/hosts.deny
>#
># hosts.deny    This file describes the names of the hosts which are
>#               *not* allowed to use the local INET services, as decided
>#               by the '/usr/sbin/tcpd' server.
>#
># The portmap line is redundant, but it is left to remind you that
># the new secure portmap uses hosts.deny and hosts.allow.  In particular
># you should know that NFS uses portmap!
>ALL:ALL
>
>If this helps matters any.

Yes, it does.  This is saying that there will be _no_ allowed connections
other than through.  This _should_ mean that all ADDE transactions should
fail.  The mystery at this point is why things work for the user 'mcidas'.
The answer is below.

re: what are the MCCOMPRESS settings for 'mcidas' and 'mcadde'
>Both are TRUE:
>
>[mcidas@cloudcover ~/mcidas]$ echo $MCCOMPRESS
>TRUE
>
>[wysocki@cloudcover wysocki]$ echo $MCCOMPRESS
>TRUE

Very good.

re: how long does it take for the SFCLIST command to fail in the user
account
>
>Almost immediately.

This was a mystery to me until I found the real problem which I describe
below.

re: can you send me the contents of the ~mcidas/.mcenv file

># .mcenv - used by McADDE
>umask 002
>
>MCHOME=$HOME
>MCDATA=$HOME/workdata
>export MCHOME MCDATA
>
>MCPATH=$MCDATA:$HOME/data:$HOME/help:$HOME/util
>MCGUI=$HOME/bin
>MCTABLE_READ=$HOME/data/MCTABLE.TXT
>MCTABLE_WRITE=$HOME/data/MCTABLE.TXT
>XCD_disp_file=$MCDATA/DECOSTAT.DAT
>MCCOMPRESS=TRUE
>export MCPATH MCGUI MCTABLE_READ MCTABLE_WRITE XCD_disp_file MCCOMPRESS
>
>PATH=$HOME/bin:$PATH
>LD_LIBRARY_PATH=/usr/local/lib:/lib:/usr/lib
>export PATH LD_LIBRARY_PATH
>cd $MCDATA

OK, this is not terribly incorrect, but it is incorrect nonetheless.  I
have logged on and changed ~mcidas/.mcenv to read:

# .mcenv - used by McADDE
umask 002

MCHOME=$HOME
MCDATA=$HOME/workdata
export MCHOME MCDATA 

MCPATH=${MCDATA}:MC$HOME/data:$MCHOME/help
MCGUI=$MCHOME/bin
MCTABLE_READ='$MCHOME/mcidas/data/MCTABLE.TXT'
MCTABLE_WRITE='$MCHOME/mcidas/data/MCTABLE.TXT'
export MCPATH MCGUI MCTABLE_READ MCTABLE_WRITE

PATH=$HOME/bin:$PATH
LD_LIBRARY_PATH=/usr/local/lib:/lib:/usr/lib
export PATH LD_LIBRARY_PATH
cd $MCDATA

The important changes are:

o curly braces around MCDATA in the MCPATH definition
o setting MCTABLE_READ and MCTABLE_WRITE to files in ~mcidas/mcidas/data
  (_not_ ~mcidas/data) that DO NOT AND WILL NEVER EXIST

After making the change, I still got the failure from the user account.
I then took a look at the contents of ~<user>/mcidas/data/MCTABLE.TXT
and ~mcidas/data/ADDESITE.TXT:

[mcidas@cloudcover ~/workdata]$ cat ../data/ADDESITE.TXT
HOST_VORTICITY.CIT.CORNELL.EDU=132.236.186.25
ADDE_ROUTE_CIMSS=CLOUDCOVER.CIT.CORNELL.EDU
ADDE_ROUTE_RTGRIDS=CLOUDCOVER.CIT.CORNELL.EDU
ADDE_ROUTE_RTIMAGES=CLOUDCOVER.CIT.CORNELL.EDU
ADDE_ROUTE_RTNIDS=CLOUDCOVER.CIT.CORNELL.EDU
ADDE_ROUTE_RTNEXRAD=CLOUDCOVER.CIT.CORNELL.EDU
ADDE_ROUTE_RTNOWRAD=CLOUDCOVER.CIT.CORNELL.EDU
ADDE_ROUTE_RTPTSRC=CLOUDCOVER.CIT.CORNELL.EDU
ADDE_ROUTE_RTWXTEXT=CLOUDCOVER.CIT.CORNELL.EDU
HOST_CLOUDCOVER.CIT.CORNELL.EDU=127.0.0.1
ADDE_ROUTE_TOPO=CLOUDCOVER.CIT.CORNELL.EDU
HOST_ADDE.UCAR.EDU=128.117.13.119
ADDE_ROUTE_BLIZZARD=ADDE.UCAR.EDU
ADDE_ROUTE_MYDATA=LOCAL-DATA

Here is where I see the problem.  Notice that cloudcover.cit.cornell.edu
is defined to have the IP address of 'localhost', 127.0.0.1.  This tells
me that your settings in /etc/hosts for localhost are incorrect:

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       cloudcover.cit.cornell.edu      cloudcover      
localhost.localdomain   localhost

This should read:

127.0.0.1       localhost       loopback
132.236.186.64  cloudcover.cit.cornell.edu      cloudcover

I got the IP number for cloudcover by doing an nslookup:

/home/mcidas% nslookup cloudcover.cit.cornell.edu
Server:  laraine.unidata.ucar.edu
Address:  128.117.140.62

Non-authoritative answer:
Name:    cloudcover.cit.cornell.edu
Address:  132.236.186.64

Identifying the IP address as 127.0.0.1 -- localhost -- is forcing the
McIDAS ADDE actions in the 'mcidas' account to act as if they were
all LOCAL-DATA.  Given this, it is not suprising that things work in
the 'mcidas' account but not in any other.  The reason is that the
'mcidas' account has all of the datasets defined (by virtue of a
BATCH LSSERVE.BAT invocation that you have made in the setup process).
If you were to go and define all of the datasets in the <user> account,
things would work there also.  This is not, however, using the ADDE
remote server setup.

In order to get the ADDE remote server setup working, you need to:

o correct your /etc/hosts file contents for cloudcover.cit.cornell.edu
o add an allow in /etc/hosts.allow of the form:

mcservsh: ALL

Actually, the ALL could be changed to be a mask for those machines at
Cornell that you want to allow access to.  This would probably look
something like:

mcservsh: 132.236.186

(i.e., all machines whose IP addresses begin with 132.236.186).

For now, and so I can exercise your remote ADDE server setup remotely,
please make this:

mcservsh: ALL

After making the change to /etc/hosts.allow, you need to send a USR1
signal to xinetd:

/home/mcidas% ps -eafx | grep xinetd
  588 ?        S      0:01 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
19200 pts/8    S      0:00              \_ grep xinetd TERM=xterm HOME=/home/mci

kill -USR1 588

This must be done, of course, as 'root'.

Now, after you have made the change to /etc/hosts, you will need to rerun
BATCH LOCDATA.BAT in each of the 'user" and 'mcidas' accounts.  To verify
that things get updated correctly after running this BATCH invocation
you should check the 

HOST_CLOUDCOVER.CIT.CORNELL.EDU=

line in ~mcidas/data/ADDESITE.TXT ('mcidas' account) and
~<user>/mcidas/data/MCTABLE.TXT ('user' account) and make sure that
they look like:

HOST_CLOUDCOVER.CIT.CORNELL.EDU=132.236.186.64

Once this is done, and after you have told cloudcover to allow McIDAS
ADDE transactions (the mcservsh: ALL entry in /etc/hosts.allow followed
by a USR1 signal being sent to xinetd), you should be able to run
McIDAS from user accounts.

>From address@hidden Wed Aug  1 09:46:01 2001
>Subject: Re: 20010801: McIDAS remote ADDE server setup (cont.)

>Thanks again for your time and patience.  I await your email.

No worries.  The problem in /etc/hosts was a first for me, so I learned
something :-)

Please let me know when you have made the changes so I can exercise the
remote ADDE server interface on your machine.  After we are convinced that
things are working well, you can shut off access to the outside world
IF you don't want to participate in the blooming network of cooperating
ADDE server sites in the Unidata community (hint, hint ;-).

Tom

>From address@hidden Wed Aug  1 13:03:51 2001

Wayne,

Oops, one more thing.  I just noticed that the mcserv and mccompress
files in /etc/xinetd.d list the HOME directory of the user 'mcidas'
as /home/mcidas:

        server          = /home/mcidas/bin/mcservsh
        server_args     = -H /home/mcidas

Since you setup your 'mcidas' account with a HOME of /usr/local/mcidas,
you should change these entries in /etc/xinetd.d/mcserv and
/etc/xinetd.d/mccompress to be:

        server          = /usr/local/mcidas/bin/mcservsh
        server_args     = -H /usr/local/mcidas

After making the changes (as 'root'), you will need to send the USR1
signal to xinetd.

Given this typo, and given that the entries in /etc/hosts.allow are
supposed to be for things being controlled by TCP wrappers, the
mcservsh: ALL entry in /etc/hosts.allow _might_ not be necessary.  I
would, however, keep it in there so you can use TCP wrappers to
control ADDE access to your machine in the future.

Oh, and another thing.  Since this is a Linux machine running a kernel
newer than 2.0.36, users will have trouble accessing sounding data
through the remote ADDE interface.  This is a know bug that is intimage
to Linux kernels greater than 2.0.?.

Give this, it may be wise to setup LOCAL-DATA access for each user to
define the RTPTSRC dataset.  In order to make this easier for you, I just
created the RTPTSRC.BAT BATCH file in the ~mcidas/data directory.  You
can run 'BATCH RTPTSRC.BAT' in each user's account to setup the RTPTSRC
dataset.  This coupled with the REDIRECTions that you have already put
in place should make all of the data in RTPTSRC available as LOCAL-DATA
to the user.  Things like soundings, hodographs, and RAOB cross
sections should then be reliable for the user.

Tom

>From address@hidden Wed Aug  1 17:22:44 2001
>Subject: Re: 20010801: 20010801: McIDAS remote ADDE server setup (cont.)

Tom,

The SFCLIST command now works for both the user and mcidas.  Thank you so
much!

Wayne