[7928] in Release_7.7_team
Re: linerva / athena.dialup transition
daemon@ATHENA.MIT.EDU (Alex Dehnert)
Fri Jul 19 10:59:54 2013
Date: Fri, 19 Jul 2013 10:59:43 -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: <51CC1D83.1030101@dehnerts.com>
Message-ID: <alpine.DEB.2.02.1307191050290.12978@novgorod.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
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.
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
>>
>
