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: Dave Dempsey <address@hidden> >Organization: SF State >Keywords: 200510040239.j942dqG7003289 IDV user home Hi Dave- >> What happens if they try ssh -Y acctname@localmachine? (to tunnel >> the xwindows). > >I should have mentioned that I'm actually running > > "ssh -XC acctname@localmachine" > >(because "ssh" is an alias for "ssh -XC" on our machines). The "-Y" flag >works with Apple's version of ssh under Tiger but not under Panther, where >"ssh -X" does about the same thing. > >I've got some machines running Tiger and some running Panther, but on either >one, logging on using X-forwarding to an account that doesn't own the >console and running the IDV produces the "Window Server communications from >outside of session allowed for root and console user only". Yeah, I figured that was probably the case, but thought I'd offer my guesses. ;-) >The problem seems to transcend X-window protocol issues, though it might be >unique to Mac OS X. I searched around a bit on the Web and the only solution >I saw was to have each student log onto his/her account on the Mac, not via >ssh in an xterm window but rather through Mac OS X's User Switching feature >(for example), so that the individual student's account controls the whole >console instead of just an xterm window. This isn't practical in our case >because the individual student accounts aren't actually defined on the local >machines--the account information is borrowed from a remote account server >via NIS. Do the students have access to their "home" directories from the lab machines? >An alternative but not fully satisfying solution is just have to have >students run the IDV under the generic "student" account that controls the >console on each machine in our Mac lab, and save their IDV configuration >information in personalized (but insecure) folders on a remote server. They >would then be able to retrieve the IDV config info later using any of the >Macs in our computer lab. (This assumes that the IDV is willing to save >files on a remote mounted file system, something I haven't actually tried >yet; MATLAB seems to balk at this, for example.) This might be another way to get this to work if they have access to their home directories (or some mounted location) and student has write permission to that home directory. You can point the IDV to a particular directory for storing the user defaults using the -userpath argument. So, you could modify the runIDV script to add on the userpath so the students could type: runIDV jsmith and then modify runIDV to be: #!/bin/sh dirname=`dirname $0` userstring="" if [ $# -gt 0 ]; then userstring="-userpath /home/$1/.metapps/DefaultIdv" shift fi if test -f jre/bin/java; then ##We are in the installer directory ./jre/bin/java -Xmx512m -jar idv.jar $userstring $* else ##Try using the dirname of this script if test -f ${dirname}/jre/bin/java; then pushd ${dirname} > /dev/null ./jre/bin/java -Xmx512m -jar idv.jar $userstring $* popd > /dev/null else if test ${JAVA_HOME}; then ##Try using JAVA_HOME ${JAVA_HOME}/bin/java -Xmx512m -jar idv.jar $userstring $* else ##Try just using java java -Xmx512m -jar idv.jar $userstring $* fi fi fi That will allow them to use their settings from any of the machines. >> I'll talk to our >> Mac OS gurus when they are around and see if there are other solutions. > >I'd love to hear any other ideas that might turn up. No new ideas since that's the way the Mac works. Let me know if the userpath option will work for you. Don Murray NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly 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: Dave Dempsey <address@hidden> Date: Wed, 05 Oct 2005 12:08:05 -0700 Don, In some respects this is a more satisfying solution than what I had in mind. I'll give it a try to see if any permissions issues crop up--thanks for pushing my thinking ahead a bit! -- Dave