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

20031119: Unidata McIDAS-X Version 2003 under Fedora at NIU

>From: Gilbert Sebenste <address@hidden>
>Organization: NIU
>Keywords: 200311191905.hAJJ5lOb020725 McIDAS-X Fedora Linux

Gilbert,

>Now, let's throw in another bugaboo into the mix.
>
>Wanna have some fun?
>
>OK, let's go! Weather2.admin.niu.edu is now fully functional on Fedora 1, 
>running LDM 6.0.14 (compiled) and the old McIDAS...which is bombing left 
>and right because it can't find TCL/TK.

Since the Tcl/Tk that McIDAS uses is part of the distribution, and
since the location of the Tcl/Tk stuff gets "burned in" to the Tcl/Tk
executables, I would guess that something in the location of the HOME
directory for the user 'mcidas' changed.  If this is the case, the
easiest thing to do would be to rebuild the McIDAS distribution, a step
that won't take long:

<login as 'mcidas'>

-- verify that the environment variables specified in your shell-specific
   configuration file (e.g., .cshrc for C shell/Tcsh; .profile for the
   Bourne shell, .bash_profile for bash, etc.) are correct for how
   McIDAS is now setup.

cd mcidas2003/src
make clobber
make all VENDOR=-g77
make installall VENDOR=-g77

>The McIDAS decoders aren't liking Fedora one bit, either.

Probably for much the same reason as the Tcl/Tk failure.

>I'll do some more peeking this afternoon and see 
>if I can't fix the problem with single images not displaying on weather3. 

If I could export an X display back to my machine here at the UPC, I
would.  I tried this a few days ago, but it did not work.  I think our
system administrator turned off our ability to run remote X sessions
with displays back here.

>Specifically, look at /home/mcidas/workdata/CFDGONLY.BAT. It also chokes 
>on that.

We talked about this the other day.  You are referencing the ADDE
dataset RTGRIDS in CFDGONLY.BAT, and you have no DATALOC for that
dataset.  When there is no DATALOC for a dataset, McIDAS assumes that
it is locally defined.  You are are neither ingesting NOAAPORT GINI
images, nor do you have datasets setup to serve them.  So, the BATCH
file _should_ fail.

OK, I made a copy of CFDGONLY.BAT as CFDGONLY_1.BAT and edited it to
set the datsets as per my recommendation a few days ago.  I then ran
the BATCH file:

<as 'mcidas'>
cd ~mcidas/workdata
batch.k CFDGONLY_1.

and the display of images, saving to GIFs ran fine.  What didn't work
was the step of copying CFDG.GIF to /home/httpd/html/cfdg.gif.  I think
the reason for this failure is that permission is being asked to
overwrite files in /home/httpd/html.  Yup.  The images in
/home/httpd/html are owned by ldm, and their read/write permissions are
rw-r--r--:

ls -alt /home/httpd/html/cfdg*
-rw-rw-r--    1 mcidas   unidata     66061 Nov 19 13:40 
/home/httpd/html/cfdg.gif
-rw-r--r--    1 ldm      unidata    118337 Oct 28 14:19 
/home/httpd/html/cfdg5.gif
-rw-r--r--    1 ldm      unidata    122205 Oct 28 14:19 
/home/httpd/html/cfdg6.gif
-rw-r--r--    1 ldm      unidata     93017 Oct 28 14:19 
/home/httpd/html/cfdg7.gif
-rw-r--r--    1 ldm      unidata    103398 Oct 28 14:19 
/home/httpd/html/cfdg8.gif
-rw-r--r--    1 ldm      unidata     79113 Oct 28 14:19 
/home/httpd/html/cfdg2.gif
-rw-r--r--    1 ldm      unidata     95773 Oct 28 14:19 
/home/httpd/html/cfdg3.gif
-rw-r--r--    1 ldm      unidata     99824 Oct 28 14:19 
/home/httpd/html/cfdg4.gif
-rw-rw-r--    1 ldm      unidata      3554 Oct 28 14:19 
/home/httpd/html/cfdg.txt

Presumably you run the CFDGONLY.BAT BATCH file out of a cron job by the
user 'ldm' (hence the ownership of the GIFs (tm) by 'ldm').  This
doesn't, however, seem to jibe with the cron job I see for the user
'mcidas':

00,12,27,42,57 * * * * /home/mcidas/kickoff CFDGONLY.BAT

The solution for the BATCH files you run is simply:

- change references to RTGINI to either GINIEAST, GINIWEST, or GINICOMP
  as appropriate
  
Now, you could simply add a DATALOC for RTGINI:

DATALOC ADD RTGINI adde.ucar.edu

** BUT ** I want to get rid of that dataset definition, so things will
probably break in the future.  Might as well take care of the problem
the "right" way now.

>And, if all goes well, would you be up for a McIDAS (eeek) re-install on 
>weather3 IF Fedora works well later this week or next?

Are you thinking of wiping the disk, or of upgrading from the current
version of RedHat Linux to Fedora?  If you are updating, all that will
be needed is a rebuild as I outlined above:

<as 'mcidas'>
cd mcidas2003/src
make clobber
make all VENDOR=-g77
make install.all VENDOR=-g77

>I've been told I 
>should think of it as RedHat 10. Outside of a few new security quirks, it 
>has been running fine for me so far...

OK.

Tom