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

20011210: McIDAS vis-a-via Solaris 7/8 (cont.)

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

Jim,

>I'm dazzled. After all this work to get MCIDAS and MCGUI running from 
>here at home, I went downtown and did a couple of administrative items: 
>adding that line to the crontab and removing user ldmcidas (from the 
>aborted build from source).
>
>Then, full of hubris and anxious to show mcidas off to my colleague, I 
>tried to launch mcidas locally. The response was "permission denied". 
>Turns out that the material inserted into the .cshrc file does _not_ 
>incorporate mcidas type directories into my path.

???

>Just now, back at 
>home, I launched mcidas via ssh and it launched OK, but echo $PATH 
>shows that my non-mcidas path is unaltered; because the last directory 
>in my path statement is 'dot' (.), my 'mcidas' command was trying to 
>launch my [user]mcidas directory!

I need to see the full contents of the .cshrc to really understand
this comment.

>Wasn't there something about a 
>special shell for remote users in that installation (I _very_ vaguely 
>recall)?

The ADDE remote user 'mcadde' should have /bin/false as its shell.  The
reason for this is that one should _not_ be able to login as this
user.  A regular user can specify whatever shell s/he wants (C, Bourne,
Korn, tcshc, bash, etc.).

>At any rate, the conditional block for c-shell doesn't work. 
>But ssh'ing in (to the same account!) and then launching mcidas works! 
>Go figure.

I have _got_ to see this.

>While down on the campus, I manually inserted the path to the mcidas 
>executable in my path statement and sourced .cshrc. That brought up the 
>roaming red bar but nothing else. I then added the following to my 
>.cshrc and sourced it again:

>   setenv MCDATA /export/home/frysingj/mcidas/data
>   setenv MCPATH "/export/home/mcidas/data;/export/home/mcidas/help"

MCPATH is incorrect.  The first MCPATH directory must be the user's
MCDATA directory.  The MCPATH for the user 'frysingj' should look
like:

setenv MCDATA /export/home/frysingj/mcidas/data
setenv MCPATH ${MCDATA}:/export/home/mcidas/data:/export/home/mcidas/help

Note colons instead of semi-colons and the lack of quotes.  I am not sure
what will happen to McIDAS with this kind of MCPATH specification.

>   setenv MCGUI /export/home/mcidas/bin
>   setenv MCTABLE_READ 
>"/export/home/frysingj/mcidas/data/MCTABLE.TXT;/export/home/mcidas/ADDESITE.TX
> T"
>   setenv MCTABLE_WRITE /export/home/frysingj/mcidas/data/MCTABLE.TXT

These look OK.

>That let me launch McIDAS but it played dumb. Here's what I got in the 
>text window:
>
>titlebar:      McIDAS???:frysingj@weather
>
>       McIDAS-X VersionUNKNOWN
>SKED SKEDFILE
>Scheduler starting on file SKEDFILE
>SKED: SCHEDULE FILE 'SCHEDFILE' INITIALIZED'
>mcimage: couldn't get enough colors; using private color map
>                 :To run GUI you must start McIDAS with fewer colors
>                 :   so that it doesn't require a private color map
>open: No such file or directory
>apparent-state: unit 10 mounted 
>/export/home/frysingj/.mctmp/2002/MCRGB.TXT
>lately writing direct unformatted external IO
>LOGON in progress...
>VERSION.TXT file is not available
>LOGON to MCIDAS-X completed
>On my terminal screen I got:
>   weather[1] mcidas
>   weather[2] open: No such file or directory apparent state: unit 10 
>named /export/home/frysingj/.mctmp/1802/MCRGB.TXT lately writing direct 
>unformatted external IO open: No such file or directory apparent state: 
>unit 10 named /export/home/frysingj/.mctmp/1802/MCRGB.TXT lately 
>writing direct unformatted external IO
>[with no prompt returning until ^c was used.]

I am sure that this is caused by the bad MCPATH specification.  The main
reason is that the first directory in MCPATH must be one that the user
can write to.  Your MCPATH has the /export/home/mcidas/data directory
as its first, and you (any user other than 'mcidas', 'mcadde', and 'ldm')
should _not_ be allowed write permission in this directory.  Given this,
files that should get created for the McIDAS session are not created
and all hell breaks loose as you see.

>       The windows were very dark but I could see well enough to type in 
>MCGUI which launched the MCGUI window. All the colors in that and in 
>the text window reverted to normal.

This sounds like your X session is running in 8-bit mode and you are
out of colors (are things like Netscape running, etc. ?)

>Unlike what I saw at home, though, 
>the image list was empty (for example) whereas at home I see the 
>GINIdatatypes and many others listed. By the way, the MCGUI window said 
>it was version 7.800 on the window portion, but not in the title bar.

Again caused by the bad MCPATH.

>       I restored my ,cshrc to what it was before playing around with 
>revising the path and before setting environmental variables outside 
>the conditional block. If you want to see it, it is at
>   /export/home/frysingj/.cshrcEXPTL
>
>       I'm so bummed out that I'm going to grade papers all evening.

OK.  I will take a look tomorrow.

Since you are sturggling at this point, is there any possibility that
I could get the login as you (frysingj) and 'ldm' so I could fix
the things that are slightly out of wack?  This would get you back
on track quickly and better prepare you for confiuring general user
accounts for McIDAS.

>Jim
>
>>From address@hidden Mon Dec 10 17:43:17 2001
>
>Tom, it looks like our messages passed each other in the pipe. Perhaps 
>the item below is _very_ significant. My account
>   /export/home/frysingj
>does not have a .mcidasrc file!

The key comment in a previous email I sent was to start McIDAS as:

mcidas config

the first time and to make sure to specify the automatic startup of
MCGUI and to save defaults in the defaults file (which is ~/.mcidasrc).
When .mcidasrc does not exist, this will create it.

>       I thought I had read somewhere in one of the various sets of 
>directions that .mcidasrc was no longer being used and that something 
>else stored user preferences.

It is read each time McIDAS starts if it exists.  If it doesn't exist,
defaults are applied for each configurable option.

Again, logins as you and the LDM user would allow me to do a couple
of things that would get you past the current roadblock.

Tom