[7926] in Release_7.7_team
Re: linerva / athena.dialup transition
daemon@ATHENA.MIT.EDU (Alex Dehnert)
Thu Jun 27 07:10:10 2013
Message-ID: <51CC1D83.1030101@dehnerts.com>
Date: Thu, 27 Jun 2013 07:09:55 -0400
From: Alex Dehnert <alex@dehnerts.com>
MIME-Version: 1.0
To: Jonathon Weiss <jweiss@mit.edu>
CC: linerva-root@mit.edu, release-team@mit.edu
In-Reply-To: <201305021558.r42FwOUp011522@outgoing.mit.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Apologies for the delay; I think we may have gotten a bit distracted by
end-of-term and then forgotten about this. In roughly decreasing order
of priority, here are some athena.dialup-related issues I'm aware of.
I believe the only thing we consider to be a true blocker to being able
to suggest athena.dialup in most cases where we currently suggest
linerva is the difficulty in reconnecting to a persistent screen
session. Current approaches I think tend towards "pick a favorite dialup
and then ssh directly to it", which will be confusing when the available
dialups changes.
The best solution we've come up with to this problem is to have a custom
DNS server that maps, e.g., adehnert.dialup.mit.edu (or
adehnert.preferred-dialup.mit.edu or some such) to the same dialup
consistently (presumably storing the user's backend dialup in a database
or picking it based on a hash). Users could then ssh to
their-username.dialup.mit.edu and always be able to connect to their
screen session. When the time came to switch to new hostnames, users
could be informed in some way (message at login, email, ...) and
transferred to another backend.
I began prototyping such a DNS server using Python and Twisted a couple
months ago, but got distracted and haven't finished it. If this seems
like a promising approach, I'm happy to resume work on it and/or make my
current (distinctly limited) progress available to you.
kchen also pointed out that athena.dialup seems to have much slower AFS
than Linerva; I believe he reported this to bug-dialup today as RT
#2406178. I don't believe we came up with any particularly convincing
explanations or fixes for this in our discussions.
We've asked before about the reboot policy for the dialups, and I think
we've been told "best effort". It would be nice to get that clarified a
bit more --- is that "we will try to keep the dialups up as long as
possible, excepting critical updates that require rebooting"? Is that
"we will try to announce things $time in advance, unless the machine is
totally non-functional"? I think we'd be happy with a policy like either
of those, but it would be nice to know what.
For people ssh'ing in from devices with ssh key support but no kerberos
support, Linerva currently allows logins but the dialups do not. It
would be nice if this changed, possibly by letting people opt-in by
adding a flag file. Two relevant tickets are
https://athena10.mit.edu/trac/ticket/1216 and
https://athena10.mit.edu/trac/ticket/500.
Linerva supports IPv6 via SIPBv6/limekiller; we have one user who
apparently likes IPv6 at least enough to have been trying to traceroute
an IPv6 address, and was surprised athena.dialup didn't support it.
Users doing kerberos ticket-based authentication to the dialups but not
running a local caching DNS resolver (which I believe is an unusual
situation) may find it difficult to authenticate to the dialups due to
the DNS load-balancing causing them to get the wrong service tickets;
https://athena10.mit.edu/trac/ticket/1195 has more information.
We've had one user note that mtr works on Linerva but not on
athena.dialup. This appears to be because it's setuid root on Linerva,
so it's possible we should resolve this discrepancy by breaking it on
Linerva as well...
It would be lovely if the hostname.mit.edu shellinabox issue got fixed
at some point (RT #2329061), though by no means critical.
Thanks,
Alex
On 05/02/2013 11:58 AM, Jonathon Weiss wrote:
> Hello,
>
> It's been a little while since we've talked about transitioning linerva
> users to athena.dialup.mit.edu. As you know the athena dialups were
> upgraded to Precise in February. In the process, I believe we added
> most of the features that had previously made linerva preferable to the
> dialups for some users.
>
> While we're unlikely to make changes to athena.dialup.mit.edu between now
> and the end of finals, I wanted to get an updated list of what things
> are currently blocking or interfering with the transition, so that we
> can work on eliminating them.
>
> Thanks
> Jonathon
>
> Jonathon Weiss <jweiss@mit.edu>
> MIT/IS&T/OIS Server Operations
>
