Ticket #1176 (new task)

Opened 9 years ago

Last modified 7 years ago

Story for screen on the dialups

Reported by: adehnert Owned by:
Priority: normal Milestone: The Distant Future
Component: linerva Keywords: transition, hackathon
Cc: Fixed in version:
Upstream bug:


To transition the linerva.mit.edu name over to athena.dialup, we need a story for how people can reconnect to their screen on the dialups without just picking a favorite dialup and getting confused when the names change.

Change History

comment:1 Changed 8 years ago by adehnert

  • Upstream bug set to hackathon

comment:2 Changed 8 years ago by adehnert

  • Keywords transition, hackathon added; transition removed
  • Upstream bug hackathon deleted

comment:3 Changed 8 years ago by adehnert

There's some progress on this on the "ssh-dialup" branch of my GitHub? fork of pag-screen ( https://github.com/dehnert/pag-screen/tree/ssh-dialup).

comment:4 Changed 7 years ago by jweiss

I've had a chance to think about this some, and after some thought would like to suggest that the best approach is probably to let users pick a favorite dialup and deal on the rare occasion when it is down. I realize that linerva has a lot more screen users than the dialups at the moment, and that this will put a small additional burden on them, however, I think there are several reasons its the right choice.

1) writing a name server to do persistent naming is hard (How do you coordinate between the two server that you need to provide redundancy at the naming level? How do you decide if a dialup is down and its user should be permanently re-directed to another machine, vs. the victim of a brief glitch, and will be back with all screen sessions shortly? For that matter, if it is really down, do you. in fact give the user a different dialup, or do you let them fail, so they know there's a problem? I suspect that at least some user would want to know why they got a machine that didn't have their existing session. (Yes, I do have partial answers to some of these, but not a solution I'm really happy with.)

2) We have a ~/.lastdialup file* that allows people to see where they logged in recently if they forgot.

  • Now on test.dialup.mit.edu ~/.lastdialup is only activated once per login (and not once per shell) even if your shell is bash.

I'll also note that after some reflection, we (server operations) are not comfortable with with a service like this run by SIPB. If someone feels really strongly that there should be such a service, please talk to me about it and we'll see if we can find some common ground.

comment:5 Changed 7 years ago by adehnert

I'm not very concerned about temporary outages. I'm more concerned that telling users to pick a favorite dialup will result in them doing fine for a year, and then being confused when the dialups get upgraded from Lucid->Precise (or future similar episodes), and their favorite Lucid dialup is no longer up. This will be particularly bad since they don't necessarily have whoever first taught them to use screen still around, or know to talk to them. (Trying to explain when initially teaching them screen isn't a great option, since they're likely to be overwhelmed with new information at the time.)

In terms of (1), my inclination would be to not worry much about most of these -- my goal is mostly to make future transitions like the Lucid->Precise one smoother, rather than to handle short-term issues. I think "your first attempt to ssh might fail if the DNS server is down" is fine, for example.

My primary concern in terms of (2) is that training people to use ~/.lastdialup is pedagogically difficult -- when they're asking for instructions, they're overwhelmed and will forget about .lastdialup; later they're likely to not know what sort of questions to ask.

The options I can think of here are:

  • DNS server handling username.dialup.mit.edu or similar
  • Modify pag-screen/owl-screen to have functionality that (somehow) automatically connects you to your preferred machine, probably using ~/.lastdialup or a similar file
  • Ops emails all screen users (or all users) on the dialups around the time of a new dialup deployment, telling them they should pick a new dialup

All of these seem like fine approaches to me; the last, in particular, requires more work from Ops every transition, but might be the least error-prone and software-heavy, which you might consider a win. I'm happy to write code for any of them, if Ops wants.

comment:6 Changed 7 years ago by adehnert

We asked about emailing people with processes running; jweiss will think about it and is not strictly opposed.

Note: See TracTickets for help on using tickets.