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

20040608: mcidas upgrade ..



>From:  "=?ISO-8859-1?Q?Marianne=20K=F6nig?=" <address@hidden>
>Organization:  UCAR/Unidata
>Keywords:  200406081246.i58CkctK029884 McIDAS accounting ADDE

Hi Marianne,

>It is NOT Thursday, you are not supposed to be skiing, hiking, sailing or
>Godknowswhat.

You are right. I am in the middle of putting together the Unidata
release of McIDAS v2004 :-(

>So it is time to bother you with a few questions:
>
>With the 2004 upgrade I saw that they went from "normal" RedHat to RedHat
>Enterprise, do you yet have any experience whether the 2004 stuff would
>build on RedHat 7.x or 9.0 or whatever?

I have verified that it builds fine under Fedora Core 1.  This is
the free follow-on to RedHat 9, so I have no doubt that it will build
fine under Redhat 7.x, 8.0, and 9.0.

>And:
>
>Together with Volker, we are trying to get this remote access running,
>which in principle I should know how to do that (the showstopper at the
>moment is the upgrade and RedHat version).

I would not worry about the RedHat version supported by SSEC.  My
experience is that the build should work with all current/semi-current
versions of Linux.  One reminder: a few of my users have run into
problems using Slackware 9.0, SuSE 9.0, and Mandrake 9.2 (one was in my
office yesterday afternoon).  The problem on those platforms had
nothing to do with McIDAS.  The problem is with the 'make' that is sent
with the systems.  One user found an updated 'make' for Slackware 9.0
and was able to build with no problems after installing it.

>However, what I am wondering about, when we configure this remote ADDE
>server, how can we make the access secure - like handing out username
>and password? 

There are two ways that you can control access, one in McIDAS and one
in the OS.

For the OS, what we do is:

- run mcinet200x.sh to setup the remote ADDE server stuff (as 'root')
- modify the /etc/hosts.allow file (as 'root') and specify which
  IP addresses will be allowed access to the machine

The McIDAS access control requires that you setup accounting and
then create a file of allowed IP addresses and logins.

As a start, I would setup control through the OS.  The reason for this
is that you then control access by machine, not user.

>Would that work with the mcidas LOGON command? Volker mentioned you know all 
>that.

If you setup the McIDAS accounting, then you will essentially force
the client user to LOGON to their workstation specifying a USER
and PROJECT number that you have allowed through the accounting setup.

>:)

Neither procedure is hard to setup, and they can be used together.

>We have got sun and 30C.
>Could get a nice look on the Venus passage today.

That's right, I almost forgot about the Venus passage.  I am glad you
reminded me!

I will scope out the details of setting up accounting access in
ADDE today or tomorrow, so I can better respond with details on
** Thursday ** ;-)

>Marianne
>Dr. Marianne Koenig
>EUMETSAT
>Postfach 10 05 55
>D-64205 Darmstadt
>phone (49)-6151 - 807-344
>mobile phone 0171 714 5095
>email address@hidden

Cheers,

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/*
+-----------------------------------------------------------------------------+


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.