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: Tom Whittaker <address@hidden> >Organization: SSEC >Keywords: 200109261738.f8QHc7117319 McIDAS ADDE mcadde Tom, >Below is some correspondence from Rick Kohrs and Dave Santek regarding the >running of the ADDE servers. Perhaps I misunderstood what Jim told me >yesterday (that ADDE servers could only be run from the ~mcidas account and >that's why you had to move the source code into this account and compile). > >I had sent a note in response to one from Dave Santek about this, and put the >"It would be a good idea..." at the bottom...you can read what they wrote. > >Was I wrong? Here is the story on setting up the remote ADDE server. 1) 'root' runs the mcinetX.Y.sh script to setup /etc/inetd.conf and /etc/system entries. mcinetX.Y.sh ascertains the home directories for the user specified on its command line and for 'mcidas'. Entries are written to /etc/inetd.conf that use the home directory information for these users. Here is an example: <as root> sh mcinet7.8.sh install mcadde This says to setup the /etc/inetd.conf entry to run as the user 'mcadde'. It also will setup the '-H' flag using the home directory of 'mcadde'. Here is what these may look like if the home directory of 'mcidas' is /home/mcidas and the home directory of 'mcadde' is /home/mcadde: mcserv stream tcp nowait mcadde /home/mcidas/bin/mcservsh mcservsh -H /home/mcadde mccompress stream tcp nowait mcadde /home/mcidas/bin/mcservsh mcservsh -H /home/mcadde 2) the way ADDE works is as follows: a) an interrupt is received on a port like 500 or 503 b) inetd uses the information in /etc/inetd.conf and /etc/services to determine what to start and as whom. In our example /home/mcidas/bin/mcservsh is run as the user 'mcadde'. A comment here: the copy mcservsh that is setup to be run is the one that lives in the ~mcidas/bin directory. One can override this by setting McINST_ROOT before running mcinetX.Y.sh, but you wouldn't know this unless you read the source for mcinetX.Y.sh (at least, it is not mentioned in the 'Installing the McIDAS-X 7.8 ADDE Remote Server' of the McIDAS User's Guide). c) the copy of mcservsh that gets run by inetd internally defines the environment variable McINST_ROOT. The value of this McINST_ROOT gets set when McIDAS is installed. d) mcservsh checks to see if there was an '-H' flag on its invocation command line. If there was, the value of it is used to set the internal environment variable HOME. Then, mcservsh checks to see if $HOME/.mcenv exists. If it does, settings defined there are read in. One might, at this point, assume that PATH could be set so that a particular distribution of McIDAS could be run, but this is not really the case. This is the point where things get really confusing to the power users that are trying to do something out of the ordinary. e) the last thing that mcservsh does is exec $McINST_ROOT/bin/mcserv. Again, this will be the copy of mcserv that was installed with the version of McIDAS that was installed in the 'mcidas' account. f) mcserv takes it upon itself to PREpend the following directories on any existing PATH that is in effect: ~/bin:~/mcidas/bin:~mcidas/bin The PATH that might be existing is the one that the user could have setup in .mcenv. This means that a user could have merrily setup PATH stuff in .mcenv _thinking_ that it would determine what version of McIDAS executables would be used from that point on. The problem is that it _won't_! What will be used peferentially is the stuff in ~/bin, ~/mcidas/bin, and/or ~mcidas/bin. This is counter intuitive to me! To reinforce the point, IF a different version of McIDAS was installed under the account that was setup to run the remote ADDE server (mcadde in this example), it would be used in preference to the copy installed in ~mcidas/bin. In this case, we would be using mcservsh and mcserv from a different version of McIDAS than the servers that will eventually be run by mcserv. The good news here is that mcservsh and mcserv have not changed in quite a few versions of McIDAS. The bad news is that not all executables being used are from the same release. g) next, mcserv decides which server is supposed to be run and it then execs it. h) the primary ADDE server execed by mcserv might find that it needs to exec a secondary server i) and so on... The key issue in dealing with the CIMSS setup was that Jim N. installed 7.801 executables somewhere different than ~mcidas/bin, and he thought that the 7.801 executables were being used. Don was running code that was getting stuff back from the server mdksserv, and the information coming back was bad. The reason that it was bad was that the code being run was the SSEC version of mdksserv, a version that did not have the needed fix applied to it. The solution to Jim's problem could be had in three different ways: 1) update his 7.7 McIDAS installation to the very latest 7.70x addendum (this would work 'cause the latest 7.70x addendum had the fix for mdksserv) 2) make a link from ~mcadde/bin to where his 7.801 binaries were installed 3) make a link from ~mcadde/mcidas/bin to where his 7.801 binaries were installed Jim was under the impression _and I was also until I actually read the source for mcserv.cp_ that one could change which version of McIDAS would be used by changing the /etc/inetd.conf entries manually (and sending a HUP to inetd). This does not work. After I learned this some time ago, I figured that I should be able to change which version of McIDAS binaries would be used by changing the PATH setting in the ~mcadde/.mcenv file. This also does not work. The only way that one could determine that a different version of McIDAS could be used by the remote server is to read the source code for mcserv.cp. Just how many people will do this? As to Dave's comment: "The PATH variable for the mcadde account determines where to look for the servers." I do not think that this is the case given that mcserv prepends PATH settings with ones it creates. So, now you know the REST of the story :-) >Dave Santek wrote: >> >> Rick Kohrs wrote: >> >> > > It would be a good idea to allow the ADDE servers to be run >> > > out of some account other than ~mcidas... >> > > >> > > -- >> > > Tom Whittaker (address@hidden) >> > > University of Wisconsin-Madison >> > > Space Science and Engineering Center >> > > Phone/VoiceMail: 608/262-2759 >> > > Fax: 608/262-5974 >> > >> > Tom, >> > >> > You can run the servers from any directory you want. The PATH variable >> > for the mcadde account determines where to look for the servers. Sym >> > links are also a possibility. You have to tell inetd an account, we use >> > mcadde. So we are limited in the flexibility due to unix. I suppose >> > for another test, you could have swap different inetd configurations >> > (one for mcadde and another for mcaddetest). You'll need root access to >> > do this. >> >> In /etc/inetd.conf >> >> dave >> >> > >> > >> > Rick > >-- >Tom Whittaker (address@hidden) >University of Wisconsin-Madison >Space Science and Engineering Center >Phone/VoiceMail: 608/262-2759 >Fax: 608/262-5974 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/* +-----------------------------------------------------------------------------+