This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: "John Weeks" <address@hidden> >Organization: USU >Keywords: 200210311701.g9VH1DX20015 McIDAS ADDE proxy John, >Institution: Utah State University >Package Version: 7.8 >Operating System: Solaris 8 >Hardware Information: Sun >Inquiry: I was wondering if Tom had made any progress on a McIDAS ADDE proxy. > >I am Paul Farral's replacement at the College of Natural Resources at Utah >State University. Paul has relocated out of state to another position. OK. Nice to meet you. >If there is not yet a proxy based solution There is not. University of Nevada-Reno/DRI has recently been trying to get a proxy forwarding to work, but so far the tests have been unsuccessful. >I was considering whether we could >use SSH port forwarding and proxy services. I also have some >familiarity with the squid proxy server but I believe >that will require some limited McIDAS source code >changes to allow for use of a proxy server. If you can outline what McIDAS source code chages would be needed, I can take a look to see how long the modifications will take. At that point, I can interact with the folks at SSEC to see if they would be willing to adopt any changes I make to the various modules in the Unidata McIDAS distribution. >The last message regarding this issue I could find is as follows: Right, that was quite awhile ago. Unfortunately, the interactions I have been having with DRI have been phone conversatiouns, so there is no "paper trail" for the effort that has been made. We are down to the point of instrumenting low level McIDAS routines to see exactly what is failing in the forward (it seems like it should work, but it isn't). I made a quick attempt at locating the appropriate module a week ago Friday just before I left for a trip to Costa Rica (where I am currently). Any significant effort at code manipulation will have to wait until I return to Boulder on March 11. Cheers, Tom Yoksas >20021113: how NFS is setup on workstation machines to access Allegan > > * To: Paul Farrall <pfarrall@xxxxxxxxxxx> > * Subject: 20021113: how NFS is setup on workstation machines to access Al > legan > * From: Unidata Support <support@xxxxxxxxxxxxxxxx> > * Date: Wed, 13 Nov 2002 18:48:44 -0700 > * Cc: Mike Schmidt <mschmidt@xxxxxxxxxxxxxxxx>, "Rob Gillies" <rgillies@xx > xxxxxxxxx>, support-network@xxxxxxxxxxxxxxxx > * In-reply-to: Your message of "Wed, 13 Nov 2002 17:04:16 MST." > * Organization: UCAR/Unidata > >>From: Paul Farrall <pfarrall@xxxxxxxxxxx> >>Organization: USU >>Keywords: 200210311701.g9VH1DX20015 McIDAS ADDE proxy > >Paul and Rob, > >OK, so now we need to really understand how "all the machines inside >simply access data and run software from Allegan". Since you said that >"workstations all run Mcidas by NFS mounting application and data dirs >off of a workstation that is connected to the outside world (has a >routable IP address) and is running ldm feeds, Mcidas stuff etc", it >strikes me that if these machines can NFS mount a disk from Allegan, >they should be able to access the ADDE server on Allegan. If this is >possible, it may be possible through a simple ADDE configuration on >Allegan to send requests for datasets not local to Allegan to other >ADDE servers out on the net. > >So, if the lab workstations can access the remote ADDE server on >Allegan, I would like to get the 'mcidas' login on so I can see >if I can setup ADDE services so that they are routed to different >machines. Are you game for this? > >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. >From address@hidden Mon Mar 1 10:41:19 2004 Thanks Tom, You might have them try running ethereal http://www.ethereal.com/ (free software) on the proxy. This will allow them to see all inbound and outbound traffic as well as breaking down the contents of each individual packet. In theory a port forwarding solution should not require any changes to the software as the gateway system will simply forward packets from an internal system to an external system. My primary concern would be how multiple clients would interact and if they would each need to talk to a different port on the proxy which would then be forwarded to port 500 on the server. I am not familiar with the traffic flow between the clients and servers and what day is being provided as I have not configured McIdas on the servers originally. Hope you are having a great time in Costa Rica, several of our people had been down that way recently as well. Thanks for the info while you are out of the office, John