[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20051003: Running IDV on account not owning console



>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