20011127: 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,

re: root privilege
>Yes, I have root priviledges; my colleague has shared the password 
>with me. In fact, I am essentially serving as the sysadmin for that 
>particular computer under his tuteledge. He maintains a cluster of 
>computers linked by NFS mounts.

OK, good.  So you can finish off the LDM installation.

>I took another look at the directions for LDM prerequisites yesterday 
>and I see that it calls for downloading and installing the source code 
>rather than downloading the binary if one's installation organization 
>is non-standard. Ours seems to fall into that category.

Yes and no.  A binary installation can be configured to match
your setup.  The biggest things are making the HOME directory of
'ldm' look like /usr/local/ldm; the ~ldm/data directory a link
to /export/home/mcdata/ldm; and ~ldm/logs a link to
/export/home/mcdata/ldm/logs; etc.

>So I downloaded 
>the source code tarball, but have not done a make on it. What I did do 
>was to get partway through the preinstallation prerequisites sheet 
>again. We pull time off a local computer which is NTP-based, but that 
>should work satisfactorily.

Agreed.

>Later, if we need to, I can configure and 
>initialize the ntpd on 'weather' similar to my xntpd here at home.

It doesn't matter how you make sure the clock is correct.  It just
matters that it is correct!

>Then I went back to recheck myself on the prerequisite list; some of 
>this had already been done by me on Nov 21, even though I'm using the 
>near-past tense here. The lines that are to be added to /etc/cservices 
>were added to our /etc/inet/services, reflecting our local installation 
>set up. I also modified /etc/rpc and /etc/syslog.conf per the 
>instructions. I went ahead and created an /export/home/ldm directory in 
>lieu of a /usr/local/ldm directory. I also created a symbolic link to 
>that in /usr/local.

Good.

>I then configured the ldm user account as per the 
>instructions, using /export/home/ldm as the value for LDHOME. I also 
>set the umask as 002; I seem to remember a note from somewhere in the 
>mcidas instructions to do that for the ldm account,

You are remembering correctly.

>though I don't see 
>it here. You might want to check my ldm .cshrc. I think I have the 
>directory structure of the ldm user account set up properly.

OK.  Things are going well.

>Now, here's where I'm a little less confident. Rather than setting up 
>the /var/data/.... directories indicated, I set up 
>/export/home/mcdata/ldm and /export/home/mcdata/ldm/logs.

/var/data is used as an example only.  Your setup is OK.

>I was tempted 
>to leave off that layer of the ldm subdirectory since you said that ldm 
>data no longer needs to be segregated from mcidas data.

Not exactly.  I said that the McIDAS-XCD data does not need to be kept
separate from the data files created by ldm-mcidas decoders.  This
is not the same as saying that McIDAS data doesn't need to be kept
separate from ldm data.

>Then I would 
>have made the log path read something like /export/home/mcdata/ldm-log. 

What about:

~ldm/data <-> /export/home/mcdata/ldm/data       (link)
~ldm/logs <-> /export/home/mcdata/ldm/logs       (link)

>I chickened out for fear of getting too far from a standard 
>installation. What are your thoughts on that?

Be brave :-).

>I then checked to make sure that I had fininshed the prerequisite 
>sheet instructions with the etc, decoders, & util directories under 
>/export/home/ldm and establishing the links as indicated. Again, you 
>may wish to check those.

I took a quick look yesterday and did not see anything that raised
any red flags.

>So, I think I'm ready to do the make on the source code. Do you 
>concur? (Or should I go back and do the binary installation again, 
>instead of making from source?)

I think that the binary installation will work fine for you.  Hmm...
this got me thinking.  To check executableness (not a word, but you
get my meaning) of binaries, do an 'ldd':

cd ~ldm/bin
ldd pqact
 etc.

If all shared libraries can be found, you will be OK.  If not,
you will probably need to build from source.

re: The LDM only needs to be installed/configured on the ingest machine.

>Great! So, all users need is McIDAS-X, which will handle all their 
>ADDE calls to 'weather', else they could scp the data from there.

Instead of making users scp data from weather, I would make the 
file system containing data files available to other machines by NFS.

>Most 
>of these machines will not be NFSed to weather; we're keeping a rather 
>tight network here and not putting all the faculty's accounts in the 
>NFS mount list.

Understood, but if you install GEMPAK, you _will_ need to NFS mount
the data.

>I didn't get to the material below yesterday. I'll try that out while 
>I'm waiting for your go-ahead on making ldm source. (Instead I 
>entertained myself by finishing up a proposed revision to an IEEE 
>metric standard in preparation for this coming meeting.)

OK.  Talk to you later...

>regards,
>Jim
>
>TO DO:
>> >I can dig around and see if I still have the links we used last
>> > January for feeds.
>>
>> OK.  Our records indicate that you had the following setup:
>>
>> primary feed site:  pluto.met.fsu.edu
>> failover feed site: cirp.met.utah.edu
>>
>> This information is accessible online:
>>
>> Unidata HomePage:
>> http://www.unidata.ucar.edu
>>   Software
>>   http://www.unidata.ucar.edu/Software.html
>>     IDD
>>     http://www.unidata.ucar.edu/projects/idd/index.html
>>       Current Operational Status
>>       http://www.unidata.ucar.edu/projects/idd/iddgeneral.html#status
>>         IDD Site Contact List
>>         http://www.unidata.ucar.edu/projects/idd/sitelist.html
>>
>> >Don't know if they are still open to us or not, though. We
>> >have not changed our fully qualified hostname so they might still
>> >work!
>>
>> They should still work.  You can test this quickly and easily from
>> your LDM account:
>>
>> notifyme -vxl- -o 3600 -h pluto.met.fsu.edu
>>
>> - and/or -
>>
>> notifyme -vxl- -o 3600 -h cirp.met.utah.edu
>>
>> If you are still allowed to request data from these sites, then the
>> notifyme invocations will work.  If not, you will get a 'Connection
>> refused' message.
>....
>
>-- 
>James R. Frysinger                  University/College of Charleston
>10 Captiva Row                      Dept. of Physics and Astronomy
>Charleston, SC 29407                66 George Street
>843.225.0805                        Charleston, SC 29424
>http://www.cofc.edu/~frysingj       address@hidden
>Cert. Adv. Metrication Specialist   843.953.7644

Tom