Update ttymsg for Lucid's gdm tty

[broder]

Lucid's gdm appears to run on tty8, not tty7.

At the very least, we should make sure that ttymsg tells users to press Ctrl+Alt+F8 instead of F7 on Lucid, and include tty7 in the list of ttys the message gets displayed on.

For super duper extra bonus points, we should figure out how to detect which tty gdm is running on, instead of hard-coding it.

[broder]

So here's somewhere to start:

kid-icarus:~ broder$ ps -o tty= $(pgrep -f /usr/X11R6/bin/X)
tty9

But we still need to figure out

1. If we can guarantee there's only ever 1 X server
2. How to detect if and when the X server gets restarted on a different tty

[jdreed]

At release-team, we suggested the following:

• stop doing stuff with upstart or initctl, and instead just plain divert {a,}getty, since there is never a reason to have getty on a cluster machine. (Running a cluster machine with a serial console is hereby defined as unsupported).

• have the ttymsg (diverted getty) dynamically get the tty that X is running on and then tell users to switch to that terminal

• do something awesome with console kit and just activate the session after the user presses a key.

[broder]

It looks like ConsoleKit? will work for this. At any given time, there should only be one ConsoleKit? session active at any given time (either gdm or the user's session)

We can get the list of sessions with:

>>> import dbus
>>> dbus.SystemBus().get_object('org.freedesktop.ConsoleKit', '/org/freedesktop/ConsoleKit/Manager').GetSessions(dbus_interface='org.freedesktop.ConsoleKit.Manager')
dbus.Array([dbus.ObjectPath('/org/freedesktop/ConsoleKit/Session4'), dbus.ObjectPath('/org/freedesktop/ConsoleKit/Session49'), dbus.ObjectPath('/org/freedesktop/ConsoleKit/Session63')], signature=dbus.Signature('o'))

(note that there really should be only one session on a cluster machine - I'm pretty sure the extra ones are from an ssh session)

Then for a particular session, activate it like this:

>>> dbus.SystemBus().get_object('org.freedesktop.ConsoleKit', '/org/freedesktop/ConsoleKit/Session4').Activate(dbus_interface='org.freedesktop.ConsoleKit.Session')

[broder]

Here's another option:

ConsoleKit? Seats emit a DBus signal (org.freedesktop.ConsoleKit?.Seat.ActiveSessionChanged?) whenever the active session is changed. We could listen for that signal, and when we receive it, use org.freedesktop.ConsoleKit?.Session.Activate to forcibly activate the session we want to be active.

(A "Seat" is a collection of sessions bound to the same hardware, so all local sessions get bound to the same Seat. As far as I can tell, that's guaranteed to be /org/freedesktop/ConsoleKit/Seat1)

Experimentally, this seems to work, and in some simple testing, I haven't been able to figure out a way to change ttys without ConsoleKit? emitting that signal. If we're OK with never allowing cluster users to change their tty under any circumstances, I think this could work.

It's worth noting that whatever approach we take, we need to be aware of the kiosk mode. Kiosk mode will get its own session, and we can identify that by looking for a session for which org.freedesktop.ConsoleKit?.Session.GetUnixUser? return kiosk@mit's UID. If we take the approach of forcibly switching to the right session on ActiveSessionChanged?, we can deal with the screw case where someone starts kiosk mode and then switches back to gdm's tty without quitting kiosk mode.

[broder]

I've updated cluster-login-config in r24668 with the ConsoleKit? approach. It's in development now, pending some simple testing of basic functionality.

[broder]

Since upgrades seem to work, I'm moving this to proposed so that we can get some wider testing.

geofft reported that when he tested this on a Jaunty workstation, our getty accepted keystrokes and redrew the screen on ENTER, but didn't actually change ttys. I think this means that either

1. none of the ConsoleKit sessions returned True from org.freedesktop.ConsoleKit.Session.IsLocal
2. getty.debathena was raising an exception, exiting, and being respawned by upstart

If someone reproduces the bug somewhere, the output of ck-list-sessions should be enough to figure out which of the two it is; I'm not sure how to get stdout/stderr out of upstart, so that might require a bit more cleverness.

[broder]

When Jon tested this on Jaunty today, he observed that nothing happens when at a GDM prompt. Since old GDM doesn't run a full-fledged GNOME session, it doesn't open a ConsoleKit? session.

In this scenario, the simplest thing to do is guess - r24678, now in -proposed.

[broder]

There are still some outstanding problems with the package in proposed:

1. Legacy GDM doesn't seem to consistently start on tty7 on our cluster machines - at the one I sat down at, it was on tty9. So guessing and switching to tty7 won't actually work.
2. The kiosk mode browser session isn't getting registered correctly on Jaunty, and getty.debathena is throwing a "CkSeatError.Code0: Unable to activate session".

My theory on this is that the su call in launch-kiosk is running the PAM stack, and creating a CK session with nox11, thus not setting the x11-display-device property that seems to be necessary to enable CK session activation.

I think we could work around this by wrapping the kiosk@mit xinitrc in a call to ck-launch-session (such that X would already be started when ck-launch-session was run), and then filtering in getty.debathena for kiosk sessions where the x11-display-device property on the CK session was set.

[jdreed]

Does pgrep'ing (c.f. the first comment here) not work as a fallback? Alternatively, we could display a message:

"You have switched away from your X11 session. TTY logins are not supported on cluster machines. To switch back, try Ctrl-Alt-F7. If that doesn't work, (reboot | call OLC )"

In fact, if we're making changes anyway, I'd like to advocate that before the current "Please press Enter" message, it says something like "TTY logins are not supported on cluster machines", so users are at least aware of what they've done.

[broder]

Ok. I've gone through and added every sanity check I can think of to r24761, which is now in proposed. Before this is considered verified, test the following scenarios on both Jaunty and Lucid:

• Trigger a session activation while a user is logged in
• Trigger a session activation while no user is logged in (i.e. at a GDM greeter)
• Trigger a session activation while kiosk mode is active

[geofft]

Replying to broder:

• Trigger a session activation while a user is logged in

On Lucid, brings you to their session

• Trigger a session activation while no user is logged in (i.e. at a GDM greeter)

On Lucid, brings you to the login screen

• Trigger a session activation while kiosk mode is active

On Lucid, brings you to the kiosk (whether or not a login session is active)

I didn't test Jaunty.

[broder]

Fix moved to production.