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

20020614: ADDE setup on new machine (cont.)

>From: "Fingerhut, William A" <address@hidden>
>Organization: Lyndon State
>Keywords: 200206052016.g55KGcJ09679 McIDAS-X ADDE

Bill,

>We may be gaining on this problem, but it is still not right.
>We did upgrade Red Hat Linux from 7.2 to 7.3.

>We tried your suggestion:
>> have your system administrator add the following line to
>/etc/hosts.allow:
>> mcservsh:    155.42              <- limits ADDE traffic to 155.42
>subnet
>
>I think this helped, but I can't say for sure. The issue is that we did
>not test ADDE after every change that was made. I was out a couple of
>days and Steven was plugging away.

OK.

>BTW, this denies you access, which seems counter-productive. So I just
>asked Steven to open access to everyone. Then, if you want to test our
>setup you will be able.

The entry in hosts.allow was a response to the previous question
about security.  You can limit access to your local domain, choke
it down to specific machines, or open it to the world.  To open
it to the world, the hosts.allow entry would be:

mcservsh:       ALL

>This morning, when I tested the port - telnet foxfire 500 - I do get a
>different response, and I believe it is a good sign ...
>
>Trying 155.42.21.12...
>Connected to foxfire.lsc.vsc.edu.
>Escape character is '^]'.
>/home/mcidas/bin/mcservsh: setenv: command not found
>/home/mcidas/bin/mcservsh: setenv: command not found
>/home/mcidas/bin/mcservsh: setenv: command not found
>/home/mcidas/bin/mcservsh: setenv: command not found
>/home/mcidas/bin/mcservsh: setenv: command not found
>/home/mcidas/bin/mcservsh: setenv: command not found
>/home/mcidas/bin/mcservsh: setenv: command not found
>/home/mcidas/bin/mcservsh: setenv: command not found
>Connection closed by foreign host.

This is progress.  It says that something is getting started upon
a connection to port 500.  All of the 'command not found' messages
are not good, but that should be easy to figure out.

>We thought this indicated that the port was cofigured correctly, and
>proceeded to scrutinize the mcaddde account?

Scrutinize:

o the entry in /etc/passwd for the HOME for 'mcadde'; this should be 
  the same directory as for the user 'mcidas'.  Also, 'mcadde' and
  'mcidas' should be in the same group

o the entries in ~mcidas/.mcenv; this is a file that follows Bourne/Korn
  shell script syntax

>The instructions say that mcadde should have not login.

Right.

>Steven noted
>that there are several ways to do so.

The easiest is to set the default shell for 'mcadde' to /bin/false.

>He had set the default shell in
>/etc/passwd to ... sbin/NOLOGIN.

I have never heard of this.  I always use /bin/false.

>We thought this might not be right
>since the default shell would be sh which does not support setenv,
>which would produce the error messages above?

The 'mcadde' account should not accept logins.  Where the setenv
messages are coming from above I can not say.

>So we changed the default
>shell in /etc/passwd to csh and Steven disabled login "some other
>way".

This is _not_ the way to solve the problem.  Again, the 'mcadde'
account should not be a login account.

>We still got the same error messages. Then I looked on cirrus to see
>how mcadde logins were handled. There, the default shell in /etc/passwd
>was .../false . So, what is the best way to disable mcadde logins?

The default shell for the 'mcadde' should be /bin/false.

>We thought that maybe mcservsh was starting in the wrong shell. The
>first line is #!/bin/sh and sh does not support setenv. But there are
>no setenv's in this script. mcservsh appears to execute .mcenv so we
>looked there. It has 8 setenv's and there are 8 setenv error messages!

This is your problem.  .mcenv should be in Bourne/Korn shell syntax.
The fact that your .mcenv has setenvs in it tells me that the file
was setup incorrectly.  The online docuemntation for how to setup
.mcenv is in:

Prepare the mcidas and mcadde Accounts
http://www.unidata.ucar.edu/packages/mcidas/780/mcx/mcxacct.html

The appropriate section of that document says:

5. Define needed environment variables in the file /home/mcidas/.mcenv. Note
   that the definitions in this file use Korn Shell syntax. 

   mcadde_env.ksh contains the Bourne/Korn-shell environment variable
   definitions: 

# Bourne/Korn shell '.mcenv' environment variable definitions for the user
# 'mcadde'

# umask
umask 002

# MCHOME
MCHOME=/home/mcidas

# McIDAS environment variables
MCDATA=$MCHOME/workdata
MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/help
MCGUI=$MCHOME/bin
MCTABLE_READ="$MCHOME/mcidas/data/MCTABLE.TXT"
MCTABLE_WRITE="$MCHOME/mcidas/data/MCTABLE.TXT"

# Turn on ADDE logging
ADDE_LOGGING=YES

# Define the PATH
PATH=${MCGUI}:$PATH

# Export the environment variables above
export MCPATH MCTABLE_READ MCTABLE_WRITE ADDE_LOGGING PATH

# CD to the MCDATA directory
cd $MCDATA


>Also, .mcenv does not identify a shell on the first line, e.g.
>#!/bin/csh, and the parent shell uses sh.

.mcenv is read from ~mcidas/bin/mcservsh which is a Bourne shell script.
Its entries are, therefore, expected to be in Bourne shell syntax.

>We thought we were on to something, but putting  #!/bin/csh on the first
>line of .mcenv did not fix the problem. 

The solution is to replace your .mcenv with the example from the web
page.

>BTW, we don't see how .mcenv can do the setenv's ?

It can't/shouldn't.  The entries in .mcenv are incorrect.

>I did look into your suggestion:

re: another process called mcserv
>Yep, there was a mcserv in /usr/share/.../pam.d . We renamed it and did
>not see any changes.

Your problem now is just one of incorrect entries in .mcenv.

re: entries in /etc/xinetd.d/mcserv and /etc/xinetd.d/mccompress

>These look similar to me, but I don't if that's good enough. Here they
>are:
># mcservsh (port 500)
>service mcserv
>{
>       disable = no
>        log_type        = SYSLOG authpriv debug
>        flags           = REUSE
>        socket_type     = stream
>        protocol        = tcp
>        wait            = no
>        port            = 500
>        user            = mcadde
>        server          = /home/mcidas/bin/mcservsh
>        server_args     = -H /home/mcidas
>        log_on_success  += USERID HOST DURATION
>        log_on_failure  += USERID HOST RECORD
>}
>
># mccompress (port 503)
>service mccompress
>{
>       disable = no
>        log_type        = SYSLOG authpriv debug
>        flags           = REUSE
>        socket_type     = stream
>        protocol        = tcp
>        wait            = no
>        user            = mcadde
>        port            = 503
>        server          = /home/mcidas/bin/mcservsh
>        server_args     = -H /home/mcidas
>        log_on_success  += USERID HOST DURATION
>        log_on_failure  += USERID HOST
>}

These look OK.

>We checked syslog for errors and saw none. We checked secure.log
>(authpriv forwarding) and saw several successes. There were several
>durations of over 10 seconds. The telnet command had to be control c'd,
>so maybe that explains the durations?

Yes.

>So, I've logged on as 3 different users; gone through the same commands;
>and gotten the same results:
>DATALOC ADD RTIMAGES FOXFIRE
>IMGLIST RTIMAGES/GE-IR.ALL
>stdin: not in compressed format
>
>When logged onto foxfire as mcidas;
>DATALOC ADD RTIMAGES LOCAL-DATA                (default setting)
>IMGLIST RTIMAGES/GE-IR.ALL
>--works fine--
>
>I don't mind following your instructions, and I don't mind you poking
>around.
>If you have time to solve this one, it would be greatly appreciated.

I think you are one step away from everything working.  The step is
to replace your ~mcidas/.mcenv file with the entries listed above and
in the online documentation.  It looks like someone took the definitions
designed for the user 'mcidas' C shell file, .cshrc, and put them in
the .mcenv file, and this is incorrect.

Tom

>From address@hidden Fri Jun 14 14:10:01 2002

Tom,

It works !!!
Thanks so much.

I caused the problem by trying to do everything in csh. After using csh
and
.cshrc for mcidas, I did the "same thing" for mcadde. Can't do that :-(

Have a good weekend, Bill