Ticket #206 (closed enhancement: fixed)

Opened 15 years ago

Last modified 14 years ago

Define behavior around zwgc and remote X11 sessions

Reported by: jdreed Owned by:
Priority: normal Milestone: Karmic Deploy (Canceled)
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

A desire has been expressed to change how zwgc behaves for remote logins. Specifically, there is a debate about whether or not it is desirable for zwgc to run when connecting to a Debathena machine with SSH and X11 forwarding. Some people expect this behavior and either like it or configure it to their needs, others find it intrusive and wish to disable it.

For the history surrounding this, see #137

Change History

comment:1 follow-up: ↓ 6 Changed 15 years ago by jdreed

I propose the following solution, which keeps the default Athena behavior but provides customizability.

The system dotfiles check for the presence of a zephyr variable (tentatively named "remotex11"). If zctl show remotex11 | awk '{print $2}' returns 'false' and $DISPLAY is set, then don't run zwgc. Otherwise, do.

Users who find zwgc intrusive can run a one-time command of "zctl set remotex11 false". Since we also check for $DISPLAY being set, users who have remotex11=false and fallback=true will get a ttymode zwgc in regular ssh sessions, as they would expect.

comment:2 follow-up: ↓ 3 Changed 15 years ago by xavid

I feel like we should make some effort to make the default behavior less confusing. The most common case for most users where you would SSH with X forwarding is from a cluster machine. In this case, you get two copies of each window gram, and the normal methods of turning off windowgrams don't effect the remote set. The fact that it's totally nonobvious that some of your windowgrams are coming from the remote server, especially if you're not actually taking advantage of X forwarding. While some people are used to the current behavior, it is not very intuitive and it seems to me that most new Athena users would not want the current behavior.

I would propose that we have as default behavior not running zwgc for SSH sessions of any type, but document this as a change in Debathena and provide a simple way using zephyr variables to enable the old behavior.

(FWIW, up until the point where I disabled zwgc all together, I was surprised every single time this happened when I was on a cluster machine. Interpret this as you will.)

comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 15 years ago by jdreed

Replying to xavid:

The fact that it's totally nonobvious that some of your windowgrams are coming from the remote server, especially if you're not actually taking advantage of X forwarding.

I'm not sure what you mean by "not taking advantage of X forwarding". We don't enable X11 forwarding by default right? Users should still have to type ssh -X (or -Y) if they want X forwarding, so I'm not sure when a user would be connecting with X forwarding without knowing it.

I would propose that we have as default behavior not running zwgc for SSH sessions of any type, but document this as a change in Debathena and provide a simple way using zephyr variables to enable the old behavior.

Fair enough, we can simply invert the description above and only run zwgc in .login/.bash_login if $DISPLAY is set and the zephyr variable "remotex11" is true. I think if $DISPLAY is not set (ie: a tty ssh session), we should run zwgc regardless, because it won't have any effect anyway unless the user has set fallback=true.

comment:4 in reply to: ↑ 3 Changed 15 years ago by xavid

Replying to jdreed:

I'm not sure what you mean by "not taking advantage of X forwarding". We don't enable X11 forwarding by default right? Users should still have to type ssh -X (or -Y) if they want X forwarding, so I'm not sure when a user would be connecting with X forwarding without knowing it.

It's always been my experience on Athena 9 that I get X forwarding even when I don't explicitly request it. Maybe this is a change from Athena 9 to Athena 10, or maybe I messed up my dotfiles Freshman year (though I've seen other people get X forwarding without expecting it in clusters, and I don't see any obvious configuration of this in my dotfiles...)

Fair enough, we can simply invert the description above and only run zwgc in .login/.bash_login if $DISPLAY is set and the zephyr variable "remotex11" is true. I think if $DISPLAY is not set (ie: a tty ssh session), we should run zwgc regardless, because it won't have any effect anyway unless the user has set fallback=true.

Sounds good to me. (Aside from implementation details, this is not running zwgc by default in either case.)

comment:5 Changed 15 years ago by jdreed

  • Milestone set to IAP 2010

comment:6 in reply to: ↑ 1 Changed 14 years ago by geofft

Replying to jdreed:

The system dotfiles check for the presence of a zephyr variable (tentatively named "remotex11"). If zctl show remotex11 | awk '{print $2}' returns 'false' and $DISPLAY is set, then don't run zwgc. Otherwise, do.

Why "remotex11"? Doesn't this setup prevent the local zwgc from starting, either? I think what we really want here is for zwgc to run once inside a $DISPLAY, but not more.

To throw out some other ideas:

  • You could do something like Firefox does where running 'firefox' remotely opens a new one locally; running a remote zwgc should realize a local one is already running and quit unless you say -f or -no-remote.
  • Don't start zwgc if $SSH_CONNECTION is set, or perhaps if $SSH_CONNECTION is set and you can ping the user (indicating they have a zephyr client running already somewhere).

comment:7 Changed 14 years ago by jdreed

We should deal with this again now that we have dialups. A user complained that zwgc was not being run (in ttymode) and they expected it to be running.

comment:8 Changed 14 years ago by jdreed

Looking at the code, we actually made the fallback change already. Yhis has the downside of requiring users who want X-forwarded zwgc to have to set fallback = true. Alternatively, they can set ZEPHYR_CLIENT in .environment.

I'll document that and move on.

comment:9 Changed 14 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.