>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 ./configure make make install sudo su make install_setuids exit 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... Cheers, Tom -- 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.
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.