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: "=?ISO-8859-1?Q?Marianne=20K=F6nig?=" <address@hidden> >Organization: UCAR/Unidata >Keywords: 200406081246.i58CkctK029884 McIDAS accounting ADDE Hi Marianne, >It is NOT Thursday, you are not supposed to be skiing, hiking, sailing or >Godknowswhat. You are right. I am in the middle of putting together the Unidata release of McIDAS v2004 :-( >So it is time to bother you with a few questions: > >With the 2004 upgrade I saw that they went from "normal" RedHat to RedHat >Enterprise, do you yet have any experience whether the 2004 stuff would >build on RedHat 7.x or 9.0 or whatever? I have verified that it builds fine under Fedora Core 1. This is the free follow-on to RedHat 9, so I have no doubt that it will build fine under Redhat 7.x, 8.0, and 9.0. >And: > >Together with Volker, we are trying to get this remote access running, >which in principle I should know how to do that (the showstopper at the >moment is the upgrade and RedHat version). I would not worry about the RedHat version supported by SSEC. My experience is that the build should work with all current/semi-current versions of Linux. One reminder: a few of my users have run into problems using Slackware 9.0, SuSE 9.0, and Mandrake 9.2 (one was in my office yesterday afternoon). The problem on those platforms had nothing to do with McIDAS. The problem is with the 'make' that is sent with the systems. One user found an updated 'make' for Slackware 9.0 and was able to build with no problems after installing it. >However, what I am wondering about, when we configure this remote ADDE >server, how can we make the access secure - like handing out username >and password? There are two ways that you can control access, one in McIDAS and one in the OS. For the OS, what we do is: - run mcinet200x.sh to setup the remote ADDE server stuff (as 'root') - modify the /etc/hosts.allow file (as 'root') and specify which IP addresses will be allowed access to the machine The McIDAS access control requires that you setup accounting and then create a file of allowed IP addresses and logins. As a start, I would setup control through the OS. The reason for this is that you then control access by machine, not user. >Would that work with the mcidas LOGON command? Volker mentioned you know all >that. If you setup the McIDAS accounting, then you will essentially force the client user to LOGON to their workstation specifying a USER and PROJECT number that you have allowed through the accounting setup. >:) Neither procedure is hard to setup, and they can be used together. >We have got sun and 30C. >Could get a nice look on the Venus passage today. That's right, I almost forgot about the Venus passage. I am glad you reminded me! I will scope out the details of setting up accounting access in ADDE today or tomorrow, so I can better respond with details on ** Thursday ** ;-) >Marianne >Dr. Marianne Koenig >EUMETSAT >Postfach 10 05 55 >D-64205 Darmstadt >phone (49)-6151 - 807-344 >mobile phone 0171 714 5095 >email address@hidden Cheers, Tom -- +-----------------------------------------------------------------------------+ * Tom Yoksas UCAR Unidata Program * * (303) 497-8642 (last resort) P.O. Box 3000 * * address@hidden Boulder, CO 80307 * * Unidata WWW Service http://www.unidata.ucar.edu/* +-----------------------------------------------------------------------------+