>From: "Luis A. Lopez" <address@hidden> >Organization: UPRM >Keywords: 200404011627.i31GRGCT021091 IDD DNS name lookup Hi Luis, >I already verified with nslookup our server, now it respond both ways, >by hostname and by ip address, but it seems that this ip address was >registered long time ago in one of our other campus with the name >heat.upr.clu.edu, I'll contact the dns administrator of the other >campus, so they can remove the ip from their tables. OK, sounds good. >LDM daemon is also running with the modification to the ldmd.conf file >that you suggested. I see that atm.geo.nsf.gov is feeding data to heat.UPR.CLU.EDU. Apr 02 17:56:37 atm.geo.nsf.gov heat(feed): topo: heat.UPR.CLU.EDU UNIWISC Apr 02 17:57:59 atm.geo.nsf.gov heat(feed): topo: heat.UPR.CLU.EDU UNIWISC The indication of the name of the machine that is being fed should change when the DNS entry is updated. What I do not see, however, is real time statistics from 'heat'. The reporting of realtime statistics is done through the program 'rtstats' which is run out of an 'exec' action in the LDM machine's ~ldm/etc/ldmd.conf file. Here is what this entry should look like on your machine: exec "rtstats -h rtstats.unidata.ucar.edu" If you have this entry in your ldmd.conf file (and it is not commented out), then it should be sending us real time statistics. Since we are not getting those stats, I have to assume that your ldmd.conf file: - doesn't have the rtstats line - the line is commented out - there is a DNS problem that is preventing the IP address of rtstats.unidata.ucar.edu from being evaluated >The ldm dameon should be running as root or with ldm user??. The LDM should always be run out of the 'ldm' account. It should never be run as 'root'. If you are running LDM as 'root', you will need to stop it, and then go into the ~ldm directory and recursively change ownership of files so that they are owned by 'ldm'. This is true for _all_ files except ~ldm/bin/rpc.ldmd and ~ldm/bin/hupsyslog. Two routines in the LDM package have setuid root permission: rpc.ldmd and hupsyslog. rpc.ldmd needs setuid root to be able to use a port less than 1024 (the LDM uses port 388). The effective user of rpc.ldmd, however, is set to the user that initially runs it after the port access is established. hupsyslog has setuid root permission so that it can send a HUP signal to the syslogd daemon (that is all that it does). The HUPping of syslogd is needed so that the LDM log file (~ldm/logs/ldmd.log) can be rotated (renamed to ldmd.log.1 and a new one created that syslogd writes into). >Do you have any example of how to tell mcidas to read this images (mcidas >and ldm)?, I need to know where you are in the process of getting things setup. First, have you installed the ldm-mcidas decoders needed to process the imagery you are ingesting using the LDM? If no, here is a quick ABC for what to do: Even though building the ldm-mcidas decoders from source is possible, the easiest thing for you to do is use a binary distribution of the ldm-mcidas decoders. You can get the binary distribution of ldm-mcidas decoders for Sun Solaris SPARC using anonymous FTP from our FTP server, ftp.unidata.ucar.edu: <login as 'ldm'> cd ~ldm mkdir ldm-mcidas mkdir decoders <add ~ldm/decoders to the PATH of the user 'ldm' (e.g., in .cshrc, etc.)> cd ldm-mcidas ftp ftp.unidata.ucar.edu <user> anonymous <pass> address@hidden cd pub/binary/sunos_5.8-sparc binary get ldm-mcidas-2003.tar.Z quit zcat ldm-mcidas-2003.tar.Z | tar xvf - Then do the following: - copy the decoders you need/want from the ~ldm/ldm-mcidas/ldm-mcidas-2003/bin directory to ~ldm/decoders - copy the files SATANNOT and SATBAND from the ~ldm/ldm-mcidas/ldm-mcidas-2003/etc directory to ~ldm/etc - integrate the decoding actions you need from those contained in: http://my.unidata.ucar.edu/content/software/mcidas/mcidd/ldm-mcidas-pqact.conf.all into your ~ldm/etc/pqact.conf file. You will be looking for the MCIDAS stream actions and the NIMAGE stream actions. At some point, you will also want to ingest the radar data for San Juan, so you should go ahead and add the FNEXRAD actions, and later some actions for the NNEXRAD feed. Let's deal with that later... I pointed you to the online example copy of ldm-mcidas decoders (the URL above) since the ones in the binary ldm-mcidas distribution are not as uptodate as they should be. By the way, the complete set of instructions for getting a binary ldm-mcidas distribution; installing it; and configuring it can be found in our LDM-MCIDAS web pages: http://my.unidata.ucar.edu/content/software/mcidas/mcidd/index.htlm Please let me know if you would like guidance in setting your pqact.conf entries. The next step after getting ingestion and decoding working is setting up data scouring. The LDM can bring over a lot of data in a hurry, so your disk can easily get filled unless you are have setup data scouring. If you are only going to be looking at satellite imagery in McIDAS, then the scouring method you choose will depend on the method you use to store the data after it is decoded. We should talk about your options so you understand the possibilities. The next step after decoding the data is configuring McIDAS to be able to access it. Let's tackle this step after the ingest and decoding are working. >excuse me by this dummy question, but I'm new installing this >software, and I'm not the end user for both of them, me neither know >anything about climatology science :-). No worries. If you want, I could logon to your machine and do a lot of the setup in a few minutes. I would need the login info for the users 'ldm' and 'mcidas' to be effective. >Again thanks a lot for your time. have a nice weekend. Cheers, Tom -- NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publically 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.