This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Unidata Support <address@hidden> >Organization: Unidata Program Center/UCAR >Keywords: 200311251543.hAPFh3EH027063 LDM request failure for workstation ETA Mark and Charles, I asked Mark: re: What is the output from a notifyme command run on the client pointing at the server? >notifyme -h 198.206.38.13 -f EXP -o 600 > >No output. Using the login information you gave me to omega, I ran notifyme to the upstream host and got: notifyme -vxl- -f EXP -o 50000 -h 198.206.38.13 Nov 25 22:03:01 notifyme[95050]: Starting Up: 198.206.38.13: 20031125080941.622 TS_ENDT {{EXP, ".*"}} Nov 25 22:03:01 notifyme[95050]: Connected to upstream LDM-5 Nov 25 22:03:51 notifyme[95050]: Connected to upstream LDM-5 ... This seems to indicate that: - you are able to connect to the LDM on 198.206.38.13 - you are allowed to request data using the EXP feed type - there is no data in the upstream machine's LDM queue At the same time, however, ldmping to the same host indicates that there is no LDM running on the upstream server, or more specifically, that there no LDM server on the upstream machine is accessible either through port 388 or through some other port controlled by the portmapper. One possibility is that the LDM was not installed on 198.206.38.13 with setuid root privilege. If this is the case, then it will not use port 388, rather, it will use a port assigned by the port mapper. Since the port mapper is considered to be a security hole, it is possible that 198.206.38.13 is either not running the port mapper, or access to the port mapper is not allowed through some sort of firewall configuration. The next question is for Charles Mcgill: Can you verify if your LDM was installed with setuid root privilege? This is done by doing a long list of ~ldm/bin/rpc.ldmd and ~ldm/bin/hupsyslog. Here is example output from Mark's machine at Lyndon State: ls -alt ~ldm/bin/rpc.ldmd -rwsr-xr-x 1 root udata 149308 Aug 19 19:30 bin/rpc.ldmd ls -alt ~ldm/bin/hupsyslog -rwsr-xr-x 1 root udata 5128 Aug 19 19:30 /software/ldm/bin/hupsyslog If either/both of this routines does not have the setuid root bit set, then you should have your system administrator ('root') do the following: <login> cd ~ldm/ldm-6.0.14/src make install_setuids If the source is not available, 'root' can accomplish the same thing with: cd ~ldm/bin chown root rpc.ldmd hupsyslog chmod u+srwx,g+rx,o+rx rpc.ldmd hupsyslog Some other things to check on the LDM installation on the upstream machine (198.206.38.13) are: 1) was /etc/syslogd.conf setup correctly and a HUP sent to syslogd 2) was the LDM entry added to /etc/rpc 3) was the LDM entry added to /etc/services Back to Mark's replies to my questions: re: request for output from ldmd.log file on client (downstream) > >Nov 25 15:45:57 omega 198.206.38.13[11917]: ERROR: requester6.c:459; >ldm_clnt.c:258: Couldn't connect to LDM 6 on 198.206.38.13 >Nov 25 15:46:27 omega 198.206.38.13[11917]: Desired product class: >20031125144340.597 TS_ENDT {{EXP, ".*_wseta"}} >Nov 25 15:48:42 omega 198.206.38.13[11917]: ERROR: requester6.c:459; >ldm_clnt.c:258: Couldn't connect to LDM 6 on 198.206.38.13 OK, this shows that Mark's LDM is not able to connect to an LDM-6 on 198.206.38.13. See comments above for possibilities. Tom