[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Platforms #ZLK-587176]: linux os



Hi Frank,

re:
> We are planning to use dell pcs for this.  The university replaces
> computers in labs on a 3 year cycle, and we were able to get some this
> year.  We replaced two older dells that were in the lab for student use,
> but got 4 for older servers we use for various things.  Our main LDM
> platform is our original one, a dual cpu pc running Solarisx86.
> Everything about it is old, including 4 scsi disks, none of which is
> very big.

OK.

> So our plan is to migrate the LDM to a newer system with bigger disks,
> and start ingesting satellite and maybe radar data, which we haven't
> done up to now.

Very good.

> One networking issue remains, which you might have some insight on: our
> student lab computers are on a local network, run out of one system that
> provides a gateway to the rest of the Internet world.  This has
> protected us from some viruses, and offers at least the appearance of
> security.  We run windows, and use an X-windows product to run Gempak
> from a server that is also inside this local network (one of the servers
> we intend to upgrade).

This sounds like a very innovative way of getting around some barriers presented
by your running a Windows-based lab.

> So here's the issue -- for now, we ftp the
> gempak files from inside the local network, grabbing them from the LDM
> machine, since we couldn't get the LDM to run through the gateway
> machine.

This setup will get more and more difficult to operate as you get more and
more data via the LDM.

> Should it be relatively straightforward to be able to get the
> LDM to relay through the gateway machine directly to the Gempak server?

Yes.  The gateway machine needs to be configured to pass port 388 traffic.

> One advantage of the current arrangement is that the volume of traffic
> is pretty small, since the file transfers take place at discrete
> intervals, and only the files of real interest are transferred.  To
> maintain some kind of timeliness, we get the upper air files once an
> hour and the surface files every 10 minutes.

Yes, but the complexity of getting new data transferred over will grow as
your ingest grows.

> We don't have any real
> computer support -- I have to do all the configuration for the network,
> with occasional student or alumni help, so if things are too hard to
> configure, they just aren't done.

I understand completely!

> Sorry to go on like this, but it seems like a chance to get some advice
> before I start reconfiguring things.

No worries.  One of our system administrators and I discussed your setup
with an eye towards what would best suit your needs going into the future.
We believe that doing the following might be the best thing for you now:

- bring the LDM machine into the lab network

- configure the gateway machine to pass port 388 traffic bidirectionally

- we would work with your IDD upstream site(s) to make sure that requests
  from your LDM machine are honored (it is not likely that your machine
  would have both forward and reverse DNS after it is moved into the lab
  network)

- share the ingested/decoded data on the machine running the LDM with
  the other machines in your lab using CIFS/Samba

Also, it seems like your comments above indicate that you are running GEMPAK
on a single machine in your lab (true?).  If this is the case, then our
recommendation is to stop doing this and run GEMPAK directly on the machine
that is also running the LDM and GEMPAK decoders.  Powerful Linux PCs are _very_
cheap nowadays, so it should be easy (read affordable) to get a single machine
that will run the LDM and GEMPAK _much_ better than now.  A careful purchase
would also make it possible for you to take advantage of new technologies like
the IDV on the same machine, AND be reasonably positioned to use the next
generation GEMPAK when it becomes available (at least "kick the tires").

> Thanks for the OS advice. I think it makes sense to try CentOS since it
> works now, and may be more straightforward later!

Very good.

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: ZLK-587176
Department: Support Platforms
Priority: Normal
Status: Closed