Re: 20010606: NMAP2 problem

Kevin,

Let me start with the gdradr problem....because that is the one I can help you
with:

1) Your directory is:
/usr1/nawips/metdat/images/radar/nids/ref0/KEAX/YYMMDD_HHMM

First off....You are using the 4 letter station ID. The default nexrad.tbl
station table is 3 letter ID's. So, it won't be able to find the locations.

Second, if you are storing be the NWS distribution office, instead of the actual
RADAR ID, you will have more problems. For example, the Denver area nexrad is:

SDUS55 KBOU DDHHNN
N0RFTG

The nexrad.tbl expects the station ID "FTG", and not KBOU. This is even a bigger
issue with: MXX BMX and HTX where 3 differnt radars are all distributed by
KBMX. So, that is one other thing to  be aware of.


2) My defaults expect files named:

        $RAD/FTG/N0R/N0R_YYYYMM_DDHH

the NEXRIII entry in datatype.tbl expresses the above as:
NEXRIII      $RAD/NIDS/%SITE%/%PROD%   %PROD%_YYYYMMDD_HHNN   CAT_NIL SCAT_NIL  
 10   2880     -1

The %SITE% template is replaced by the radar ID and the %PROD% is replaced by
the product identifier. So, at the least, given your naming above, you would
need: 
NEXRIII $RAD/nids/%PROD%/%SITE%     YYMMDD_HHNN etc.....

That should get you running with gdradr.


NEXT, NMAP etc.....

the defaults from NCEP expect the files named as I show above, with 4  digit
years and files named like ref0_YYYYMMDD_HHNN. I follow the way NCEP names their
files. You may have trouble using a different naming convention- I certainly
haven't tested naming files other than how they suggest.


Lastly, if you were hacked, that would explain a lot of the problems like
"too man open systems". The latest way I've seen RH exploited is by hackers
entering though "lpd". If you aren't serving a printer...better shut that off.
Shut down all services you aren't using.
You can compare MD5 checksums of your system executables with posted values
on the web. Typically, hackers replace "ps" and "top" so you can't see what they
are doing. You might even be showing bogus amounts of space available on your
system if they have replaced "df" and/or "du". You may be losing disk space
and not know it.

I've seen hackers add "ssh" deamons for loggin in, extra accounts, and huge
directories under /dev where they grab passwords. 


Anyhow, I believe that you can fix your gdradr and nmap2  by the above
suggestions.

I am the one and only GEMPAK support and workshop instructor. I would assume
that there will be plenty of sace in the workshop this year....but I haven't
seen any registration lists from Emily yet. We can seat 24 students this
year. In past years, we could only seat 16, so we usually have 3-5 more
registrants than we could handle.


Steve Chiswell
Unidata User Support




On Wed, 6 Jun 2001, Kevin Polston wrote:

> Steve,
> 
> I really don't understand what is going on with the datatype.tbl. I decided 
> last
> night the heck with it and I reinstalled NAWIPS. That seemed to take care of 
> my
> problem regarding the satellite data but I still couldn't get the data 
> listing for
> the radar data. I went and double checked the datatype.tbl file and it seemed
> everything was set right. I am going to double check again this evening ( I 
> was in
> class all day so I haven't had a chance to look at it). My disk space is not
> full....far from it actually.  Up until a couple of weeks ago I thought 
> everythign
> was running fine but then I suspect I got hacked.....I can't say for 
> sure....but I
> think I was hacked.  Something came up where I needed to either log out or 
> reboot
> (I don't remember which) and when I logged back in (I was using KDE) I had a
> completely different looking desktop and several of the scripts I had were 
> gone.
> These were scripts to collect or display data. I still had most of the NAWIPS 
> stuff
> but it wasn't any good if I was not getting or able to get any data. I was 
> using RH
> 6.2 at that time. So I went out and installed RH7.1 and reinstalled NAWIPS. I 
> was
> getting everyhting re-configured and it seemed to be going relatively 
> smoothly.
> However.....I noticed if I left too many loops running in NMAP2 overnight the 
> next
> morning it was like the data somehow got messed up and I saw a message that 
> said
> "too many file systems open". That's when I ended up having to restart the 
> system
> and thats when I noticed that there was no datatype.tbl file.  I don't know 
> why
> that would happen.
> 
> So after reinstalling NAWIPS last night I was able to get the satellite data 
> to
> display in NMAP2 but the radar data still won't show up. And speaking of radar
> data...let me jump back to a problem I am still having with the gdradr 
> program.
> When I last e-mailed you about this I had assumed that I was creating the 
> radr.gem
> file correctly and that my problem was one of configuration. Well, now I am 
> not so
> sure that I am creating the radr.gem file properly at all. I had a friend of 
> mine
> from AWC check it out and we actually looked at the file and it didn't look 
> like it
> had the "right kind" of data. In other words....we didn't see any numbers in 
> the
> file at all. It's been about a week now and I don't remember exactly what was 
> there
> but it didn't look right. My directory structure that I have to save the 
> radar data
> (in this case the 0.5 reflectivity) is like this:
> 
> 
> /usr1/nawips/metdat/images/radar/nids/ref0/KEAX/YYMMDD_HHMM
> 
> KTWX
> 
> KSGF
> 
> etc, etc
> 
> I am wondering if the gdradr program is reading the proper directory. How can 
> I
> check and what would you suggest I do based on the way my directory structure 
> is
> set up. I did download a radr.gem file that you are creating and I was able to
> display it based on the configurations I had set up. So that made me think 
> even
> moreso that I wasn't properly creating the file.
> 
> Hopefully tomorrow I will be able to tell you I have figured out the problems 
> with
> displaying the data.......
> 
> Also, I have signed up for the GEMPAK workshop at the end of July. I am 
> hoping I
> will be able to attend. Will you be instructing or someone else? I am looking
> forward to coming....perhaps I can learn alot more about GEMPAK and NAWIPS 
> than I
> know now...and also have abetter understanding rather than going through this 
> by
> trial and error. Right now I feel I have enough knowledge to be dangerous (not
> necessarily a good thing!) so I am thinking that workshop would be a big help 
> for
> me.
> 
> Thanks and talk to you later.
> 
> KP
> 
> Steve Chiswell wrote:
> 
> > Kevin,
> >
> > If you have a datatype.tbl file that is 0 bytes, then this is something 
> > outside
> > of GEMPAK since no GEMPAK program ever tries to modify any table.
> > In fact, if you are running as a different user than your GEMPAK account
> > is installed under, then that should be impossible.
> >
> > Some reasons you could get a 0 length file are if you try to open the file
> > in your editor, and your disk space is full. Anything like that would
> > crater NMAP2. Of course, Garp has its own files, and never looks at
> > datatype.tbl. NMAP relies more on the GEMTBL/nmap/.... tables.
> >
> > I would suggest checking your system logs to see if there are disk full
> > messages.
> >
> > I haven't had problems with NMAP2 running all night. Presumably you
> > are running 5.6.C.1 and still at RH Linux 6.x? I am running here with RH 
> > 7.0 &
> > 7.1
> >
> > Steve Chiswell
> > Unidata User SUpport
> >
> > On Wed, 6 Jun 2001, Kevin Polston wrote:
> >
> > > Hey Steve,
> > >
> > > I have run into a problem that I don't know how to fix. I had several
> > > image loops running in NMAP2 last night (I left them run overnight).
> > > When I checked this morning I had a message that said "too many file
> > > systems open". I had seen this before......so I cleared everything and
> > > restarted NTL and opened NMAP2. Well, when I right-clicked to bring up
> > > the menus (image, obs, grids, etc).....there was nothing there. I have
> > > had this happen to. The datatype.tbl file was empty (ie it had 0
> > > bytes....nothing in it). I had a backup datatype.tbl file that I copied
> > > into the proper directory. Well, it looked like everything was fine. I
> > > clicked to bring up an image....and all the subdirectories were there.
> > > However, when I clicked on the last submenu (the one which will show the
> > > data links in the white window) nothing came up. This was for both
> > > satellite and radar. However....the other data sources were working fine
> > > (upper air, profiler, surface obs, gridded data). What's more...I was
> > > able to call up the imagery in NMAP and NSAT and GARP. I looked through
> > > the datatype.tbl file and I couldn't see anything that was wrong. What
> > > would you suggest to fix the problem.
> > >
> > > KP
> > >
> > >
> 
>