20000416: McIDAS ADDE server access to Plymouth State GINI imagery (cont.)

>From: Gilbert Sebenste <address@hidden>
>Organization: NIU
>Keywords: 200004160431.WAA05472 McIDAS-X 7.60 GINI ADDE access

Gilbert,

(As you can see, I am clearing out some old email that has needed
attention :-)

re: requesting access to Plymouth state directly from Jim Koermer
>That's what I figured, and again Jim, muchas gracias!!!

Yes, this is very nice of Jim to do.

re: additional sites that might be running NOAAPORT ingest systems
>The only site I know that is getting it is Duke Power. Unfortunately,
>while I suspect Mike Dross would be happy to do it, he's commercial.

I did think of Mike, but a decided to not contact him for that same
reason, Duke power really should have no interest in feeding Unidata
sites.  Another possibility that I am following up on is the University
of Georgia.

>We *DO* have 3 ADDE servers out there right now for the UNIDATA community
>to use:
>
>1) Plymouth;
>2) UNIDATA;
>3) NASA.

NASA has not made their server generally available to the Unidata community
(yet).  I have been having discussions with Anthony Guillory in which
I am trying to convince him to convince others at Marshall that this
would be a "good thing".

>So, we're on our way!

Well, there a LOT of sites running McIDAS remote ADDE servers.  In fact,
there are at least 25 sites running the remote server setup I send out
with Unidata McIDAS.  We are well on our way to creating a cooperating
net of sites that can act as each other's realtime data backups.  Some
things are going to happen at SSEC to give the community more access to
higher resolution GOES imager and sounder channels as well.  This will
take a little time as there is some infrastructure that needs to be
put in place.  More news at 11... :-)

re: DATALOC ADD RTGINI
>Whoa! Wait a minute. I did that command to add ADDE.UNIDATA.UCAR.EDU
>(only difference is the machine name). How do I
>know that, when I make an image, it is being downloaded from Plymouth
>rather than from UNIDATA? Both are "RTGINI", if I recall correctly.

The setup for ADDE is that you get data from one and only one site
at a time for a particular dataset.

re: setup at NIU
>> have remote ADDE server setup
>Got it.

I knew this was the case some time ago, but I didn't know if you
had turned it off.

>> have datasets that can be accessed through the remote ADDE server
>Got it.

I see that you have RTIMAGES and RTPTSRC pretty much fully populated.
You are not, however, producing McIDAS GRID files, so no model data
can be had from your ADDE server.  Also, the TEXT data seems to be
somewhat sparse on your machine.

re: TCP wrappers
>I don't know how to block ports other than to do an ALL:ALL on my
>hosts.deny file. If I want to block other ports, how do I do this to
>prevent unathorized access?

Your /etc/inetd.conf file has to be modified to run TCP wrappers
for the McIDAS services.  How this is done is a little different from
operating system to operating system.  Since you are running RedHat
6.0 on your PC, your /etc/inetd.conf entries should currently
look like:

mcserv  stream  tcp     nowait.255      mcadde  /home/mcidas/bin/mcservsh      
mcservsh -H /home/mcidas
mccompress      stream  tcp     nowait.255      mcadde  
/home/mcidas/bin/mcservsh       mcservsh -H /home/mcidas

(they do; I know 'cause I am looking at them right now :-)

The TCP wrapper setup would change these lines to be:

mcserv  stream  tcp     nowait.255      mcadde  /usr/sbin/tcpd  
/home/mcidas/bin/mcservsh      -H /home/mcidas
mccompress      stream  tcp     nowait.255      mcadde  /usr/sbin/tcpd  
/home/mcidas/bin/mcservsh       -H /home/mcidas

Mind the tabs!!!!!!

After making changes to /etc/inetd.conf, you have to send the inetd process
a HUP so that the file will be reread:

kill -HUP <process_id_of_inetd>

re: configuration file for TCP wrapper allow/deny
>Where is this file?

hosts.allow and hosts.deny are both in the /etc directory.

The configuration entry in these files for ADDE processes would look
like:

mcservsh:       ALL

If all machines are to be allowed access.

>Thanks again, Jim and Tom, for all your help! Looking forward to the
>response.

I hope that this helped.

Tom