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

20010607: MCPATH definitions for users other than 'mcidas'

>From: Chris Herbster <address@hidden>
>Organization: Embry-Riddle Aeronautical Univ.
>Keywords: 200102131816.f1DIGsL18220 McIDAS MCPATH MCGUI

Chris,

>Perhaps a subject change relating to $MCPATH is appropriate?

Yup.

re: .cshrc contents versus contents of .mcenv
>Opps - I guess I confused the stuff that should go in the .cshrc with
>.mcenv.  "Mcidas", the user, does invoke tcsh as the shell .... 

In this case, you would add the earlier configuration stuff to the
.cshrc file and the Bourne/Korn shell stuff to the .mcenv file making
sure that they both define things in the same way (i.e., MCPATH values
(not syntax) in .cshrc matches MCPATH in .mcenv, etc.).

re: check http://www.unidata.ucar.edu/packages/mcidas/770/mcx/mcxacct.html
>Thanks - I must have been asleep at the wheel when I did this
>installation.  (-:

No problem.

>I have another problem, this is not new as I discovered it shortly after
>sending this past message out.

OK, ready...

>When "Joe User" (actually in this case a generic lab user named "opwx")
>tries to run mcidas, this is what they get:
>
>[opwx@thermal ~]$ mcidas
>[opwx@thermal ~]$ ERROR: MCPATH contains no writeable directory
>ERROR: current directory is not writable
> 
>[opwx@thermal ~]$      
>[opwx@thermal ~]$ echo $MCPATH
>/wxhome/mcidas/workdata:/wxhome/mcidas/data:/wxhome/mcidas/help               
>
>This seems to be consistent with the instructions.

Actually, it is not.  The user 'mcidas' account is setup differently
from all other users accounts.  This was done to reinforce the difference
between 'mcidas' -- which should be thought of as 'root' for McIDAS stuff --
and all other users.

The MCPATH for the user 'mcidas' would look like:

/home/mcidas/workdata:/home/mcidas/data:/home/mcidas/help

The HOME for your 'mcidas' user is /wxhome/mcidas, so the MCPATH for
your 'mcidas' user would be:

/wxhome/mcidas/workdata:/wxhome/mcidas/data:/wxhome/mcidas/help

The MCPATH for all other users should look like:

/home/user/mcidas/data:/home/mcidas/data:/home/mcidas/help

Assuming that the HOME directory for your 'opwx' user is /wxhome/opwx, the
MCPATH for 'opwx' would be:

/wxhome/opwx/mcidas/data:/wxhome/mcidas/data:/wxhome/mcidas/help

Note that you must make sure to create the mcidas/data subdirectory for
the user 'opwx' and also make sure that this directory is readable and
writable by the user 'opwx'.  Once this change is made, you will not
see the error that you list above.

>This same behavior is seen in other user's accounts too.

The same comment applies to other users.  The MCPATH is generically:

MCPATH=~user/mcidas/data:~mcidas/data:~mcidas/help

(the ~user and ~mcidas should be replaced with the actual HOME directories
for the users 'user' and 'mcidas', respectively).

>I didn't notice this problem as my user id (herbster) that I had been
>testing with is an auxiliary member of the group "data" that mcidas is
>part of (along with ldm and gempak).

The reason you did not see the problem is that by virtue of you being
in the same group as 'mcidas' and 'ldm', you will have read/write
permission to the ~mcidas/workdata (and ~mcidas/data and ~mcidas/help)
directory.  You should change your account setup to match the example
above and that detailed in:

Configuring Unidata McIDAS-X Accounts
http://www.unidata.ucar.edu/packages/mcidas/770/mcx/config_mcx.html
  Configuring User Accounts
  http://www.unidata.ucar.edu/packages/mcidas/770/mcx/config_users.html

The thing that may not have jumped out at you from the last page is
the distinction between the MCHOME and HOME environment variables.

>With group write permissions being the default for these accounts I
>certainly don't want the average user to be in this group.
>I've tried to find the answer to this online, but no luck so far.

You are correct, you do not want the average user to have write
capabilities in the directories owned by the user 'mcidas'.  This is
why I made the following comment in:

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

 ...

2. If the mcidas and mcadde accounts are not in the same group as the
user running the Unidata LDM, have the system administrator put them in
the same group. This group should be different than the one that
general users are in.

 ...

The operative comment is the last sentence: mcidas, mcadde, and ldm
should be in the same group AND this group should be different that the
one that general users are in.

re: example BATCH file
><... snip ... stuff on how to view the images - Thanks!!>

Did it all work as advertised?  I wrote this from home where I was not
running McIDAS, so I couldn't test it.

re: do you want to run the ADDE remote server
>Actually this is where I'd like to be headed.  Thermal is our LDM
>ingestor/data server.  We have a couple of other machines that will
>eventually be running the mcidas package and my understanding is that
>ADDE give better performance than NSF mounts.

Yes, exactly.  Also, when one gets used to accessing stuff from remote
servers (like using Netscape, for example), the data possibilities 
explode!

>Actually, while getting setup, it might be nice to configure things for
>another ADDE server(s).  That way we could have good data access while I
>nibble away on the in-house configuration.
>
>Any suggestions on which server to point to?

Yes.  My records show that you recently (May 23) grabbed a McIDAS
distribution that has all of the recent mods included.  Given this, you
now have a GUI widget that you can use to setup dataset access to a
list of ADDE servers at cooperating sites.  Access to this widget is
provided in two places:

Fkey Menu:

F8 Menu Administration ==> F5 ADDE Dataset Locations

MCGUI:

The stange looking icon just to the right of the capital Z (zoom); this
icon has two PCs that are interconnected with arrows.

When you pop open the GUI widget, you will see what machines are
currently available for the various datasets listed (left click on the
down arrow in the entry/button combination widget).  For instance, the
servers that are available for the dataset GINICOMP are currently:

STRATUS.AL.NOAA.GOV
PAPAGAYO.UNL.EDU
CACIMBO.GGY.UGA.EDU
SNOW.PLYMOUTH.EDU
ADDE.UCAR.EDU
LOCAL-DATA

The same set of machines are available for most of the other datasets,
but you will find varying numbers of radars at different sites.  This
is a result of what those sites are getting by IDD.

Please note that the Fkey Menu is basically ADDEized (except for grid
cross sections).  MCGUI, on the other hand, only provides ADDE access
to certain functions under Display ==> Observations:

Meteorograms
Thermodynamic Diagrams/Hodographs
------
Profiler Time-Height
------
Fronts
Weather Watch Boxes

As I mentioned in my previous email, the 7.8 MCGUI will be completely
ADDEized.  At this point, the Fkey menu should fall in disuse and so
will be no longer be updated.

><snip stuff on sample script - Thanks again!>

You are welcome.

re; Please let me know if you run into any snags.

>Here I am again!  (-:

McIDAS is a tough one to get to love, but I can tell you that being
able to sit at your desktop and access data from servers from all over
the world will make the pain worthwhile.  In the future, you will see
the list of cooperating ADDE server sites grow and grow.  You will also
see the number and variety of data served by those sites increase as
people "publish" their local holdings.  My job is to do a good enough
job on the MCGUI to make this access as painless as possible.

>Thanks Tom!

You are welcome.  Talk to you later...

Tom