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

20050902: a second look at sasquatch (cont.)

>From: Unidata Support <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200509021505.j82F56jo020896 IDD SCOOP

Hi again Gerry,

Earlier I wrote:

>At this point I am seeing some flags being set for the eventual make
>that seem to indicate that the build environment may not be quite
>correct.  I will need to discuss this with Steve Emmerson to see if I
>am misinterpreting something (I'll get back to you).

Steve and I went over what I was seeing.  The short story is that the
configure script in LDM-6.3.0 does not correctly determine the build
environment under 64-bit Linux (this is a problem with the 'getconf'
utilility distributed with those systems, not with 6.3.0's configure).
Since I wanted to downgrade the LDM on sasquatch to 6.3.0, and since we
want the LDM built to be as efficient as it can be under 64-bit Linux,
I was forced to do the following:

- modify the configure scripts in the ~ldm/ldm-6.3.0/src and
  ~ldm/ldm-6.3.0/src/rpc directories to overcome the 'getconf' problem
  I allude to above

- rebuild 6.3.0 from scratch:

<as 'ldm'>
cd ~ldm/ldm-6.3.0/src
make distclean

-- modify configure
-- modify rpc/configure

make install
sudo su
make install_setuids

cd ~ldm
ldmadmin stop && rm runtime && ln -s ldm-6.3.0 runtime && ldmadmin start

Let's let this setup run for awhile and evaluate where we stand
regarding the large, sawtooth latencies we are seeing on machines
feeding from sasquatch.

By the way, mesodata3 (and aef.tamu.edu) is still trying to feed from
sasquatch and being denied.  Is the lack of an allow line in
sasquatch's ~ldm/etc/ldmd.conf file by design or an oversight?  If it
is by design, you should remove the request in mesodata3's ldmd.conf
file and restart its LDM; if it is an oversight, an allow should be
added to the ldmd.conf file on sasquatch and its LDM should be
restarted.  Given that there are two .tamu.edu machines trying to
feed from sasquatch, I would guess that you really do mean to allow
access from machines in your domain (the machine can certainly handle
the connections).  If this is the case, I would recommend a general
allow for TAMU machines:

allow   ANY     \.tamu\.edu$

Also, there still is the issue of MADIS processing on sasquatch...


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.