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.
Hi Marck, re: > ok ldmadmin watch works now. Excellent! re: > but we have no luck with the log files still. OK. > can you ssh into the system? I SSHed to your machine right after receiving this email. Here is what I found: - for some reason, the runtime link in the HOME directory of 'ldm' was missing I recreated it as follows: <as 'ldm'> cd ~ldm ln -s ldm-6.11.6 runtime Now, the ~/bin directory is found, and that is important since that is how the LDM executables are found - next, I verified that setuid root permission was set for the 'ldmd' and 'hupsyslog' LDM routines Very good. This told me that the reason that logging might not be working was because the SELINUX setup had not been changed. - I changed the SELINUX setup to allow LDM logging: <as 'root'> -- edit /etc/selinux/config and: change: SELINUX=enforcing to: SELINUX=disabled This change will become effective the next time the machine is rebooted. I forced SELINUX to change out of 'enforcing' mode to 'permissive' mode as follows: <as 'root'> # setenforce 0 I verified the change with: # sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: disabled Policy version: 24 Policy from config file: targeted This will change to: SELinux status: disabled after a reboot. - the final thing to be done at this point was to setup a boot-time script that will start the LDM upon reboot I did this by copying the reboot script that we use into the /etc/init.d directory and making sure that the read/write/execute permissions were correctly set. I exercised the script to make sure that it worked by running the following: <as 'root'> cd /etc/init.d ./ldmd stop -- verified that the LDM which had been running was stopped, OK ./ldmd start -- verified that the LDM was successfully started and was running as 'ldm' ** NOT ** as 'root' (this is _important_) - the next thing I found was that the clock on your machine was not being synchronized via ntpd It is very important that the system clock be kept accurate through the use of ntpd. I forced your clock to synchronize and then setup ntpd to run as follows: <as 'root'> [root@dma etc]# ntpdate timeserver.unidata.ucar.edu 29 Oct 17:14:35 ntpdate[6173]: step time server 128.117.140.2 offset 174.832285 sec [root@dma etc]# chkconfig ntpdate on [root@dma etc]# service ntpdate start ntpdate: Synchronizing with time server: [ OK ] - the next thing I did was to hardware a fully-qualified hostname into the LDM registry file so that real-time stats reported by your machine would show up nicely on our real-time stats pages Your machine was known as dma.ldm; I changed it to dma.ldm.meteo.aw. Here is how you navigate our website to find the real-time statistics pages: Unidata HomePage http://www.unidata.ucar.edu Data -> IDD Operational Status http://www.unidata.ucar.edu/projects/idd/rtstats/ Statistics by Host http://www.unidata.ucar.edu/cgi-bin/rtstats/siteindex If all goes well, your machine should show up in the listing on the past page as: aw.meteo.ldm.dma If it doesn't show up, it likely means that something is blocking the real-time stats messages from getting back to our real-time statistics machine, rtstats.unidata.ucar.edu. We can worry about this later if needed. - the change I made was solely as a convenience: I made two links in the HOME directory of 'ldm': <as 'ldm'> cd ~ldm ln -s var/data data ln -s var/logs logs This change is more for us old timers who are used to the LDM logs being available in ~ldm/logs, and the data directory structure to be accessible in ~ldm/data. As I end this email, I can report that the LDM appears to be nicely setup on your machine. The next step in this process is to figure out what you want to do with the IDS|DDPLUS products that are now flowing to your machine. The other thing that you _will_ want to do _soon_ is change the passwords for the 'ldm' and 'root' accounts on your machine! Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: VRK-635010 Department: Support IDD Priority: Normal Status: Closed