[7930] in Release_7.7_team
Re: linerva / athena.dialup transition
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Fri Jul 26 12:32:45 2013
Message-Id: <201307261632.r6QGWa6q013785@outgoing.mit.edu>
To: Alex Dehnert <adehnert@MIT.EDU>
cc: Jonathon Weiss <jweiss@MIT.EDU>, linerva-root@MIT.EDU,
release-team@MIT.EDU
In-reply-to: <alpine.DEB.2.02.1307191109480.12978@novgorod.mit.edu>
Date: Fri, 26 Jul 2013 12:32:36 -0400
From: Jonathon Weiss <jweiss@MIT.EDU>
Alex,
I'll look into this wehn I get a chance, hopefully in August. However,
I suspect it will, at the very least, require code change to our patch
to sshd that forces you to get tickets if you authenticate with
kerberos, but don't forward your existing ones.
Jonathon
Alex Dehnert <adehnert@MIT.EDU> wrote:
> 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
> >>>
> >>
> >
