NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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