[7929] in Release_7.7_team
Re: linerva / athena.dialup transition
daemon@ATHENA.MIT.EDU (Alex Dehnert)
Fri Jul 19 11:10:30 2013
Date: Fri, 19 Jul 2013 11:10:20 -0400 (EDT)
From: Alex Dehnert <adehnert@MIT.EDU>
To: Jonathon Weiss <jweiss@MIT.EDU>
cc: linerva-root@MIT.EDU, release-team@MIT.EDU
In-Reply-To: <alpine.DEB.2.02.1307191050290.12978@novgorod.mit.edu>
Message-ID: <alpine.DEB.2.02.1307191109480.12978@novgorod.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 19 Jul 2013, Alex Dehnert wrote:
> I'm reminded of this thread by a recent scripts@mit.edu question about ssh
> public key authentication to athena.dialup (I'm not sure why the user emailed
> scripts@). It occurred to me a couple weeks ago that if "opt-in by adding a
> flag file somewhere to show that you understand why ssh keys with
> athena.dialup is different than on most servers" is fine from a support
> perspective, then no code changes are required to implement it if the flag
> file can also be the authorized keys file (e.g.,
> .ssh/dialup_authorized_keys): I think that just setting "AuthorizedKeysFile
> .ssh/athorized_keys" (and turning on public-key auth) or so would work.
Ah, that should be "AuthorizedKeysFile .ssh/dialup_authorized_keys",
sorry.
>
> I'm not sure if you've had a chance to think about this or any of the other
> concerns I listed in my email below.
>
> Thanks,
> Alex
>
> On Thu, 27 Jun 2013, Alex Dehnert wrote:
>> 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
>>>
>>
>
