[3275] in Release_7.7_team
Re: Draft of Disconnected Operation White Paper.
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Mon May 13 21:47:04 2002
Message-Id: <200205140147.VAA22945@the-other-woman.mit.edu>
From: Jonathon Weiss <jweiss@MIT.EDU>
To: Bill Cattey <wdc@MIT.EDU>
cc: release-team@MIT.EDU, warlord@MIT.EDU
In-reply-to: Your message of "08 May 2002 18:30:50 EDT."
<1020897050.18031.34.camel@tokata.mit.edu>
Date: Mon, 13 May 2002 21:47:02 -0400
> Email delivery:
>
> Email delivery is actually already a solved case. The sendmail
> program already detects when mail cannot be immediately delivered.
> In that case outgoing mail is enqueued, and periodic attempts are
> automatically made to deliver what is in the queue.
When disconnected form the network, the application often hangs when I
send mail. This is because it is trying to make DNS queries to
determine where to send the mail. I'm not sure what the right thing
to do here is. I wonder if there are any caching nameds out there
that DWIW if they lack a route to the relevant nameservers.
I also agree with jhawk, that the queue should be run when the net
comes back up. However, I don't think we really need to put any work
into allowing users to explicitly flush or monitor the queue (sendmail
-q and mailq accomplish that if in an ugly way).
> Network printing:
>
> Athena enhanced printing to utilize a network-based service, Hesiod,
> to suplement the hard-coded file of printers and their capabilities.
> The lprng subsystem that implements printing on Athena will look first
> in the local file before attempting a Hesiod query, but if the user
> misspells the printer name, the recovery is less than perfectly
> graceful: Seeing no entry in the local printcap file, lprng will then
> make a Hesiod query. The DNS service, upon which Hesiod is based,
> will take 30 seconds or so to time out.
It's worse than that since local printcaps are not populated. This
means that the hesiod request needs to occur for essentially every
print request. Besides users are unlikely to have a printer attached
locally to their laprop while roaming, so we'll need the network to
deliver the job anyway.
> Kerberized login:
>
> In analagous fashion to printing, Athena enhanced login to do user
> account administration centrally. Additional administrative work
> beyond the UNIX norm became required to enable local accounts to
> supercede the centrally administered one.
>
> In a disconnected mode, there is a failure mode quite similar to that
> of network printing: login will look first in the local passwd file,
> and if there is no such person, it will use the network to
> authenticate the user. If there is no network, there will be a pause.
Actually, I believe login will look first to hesiod, and then to the
local passwd file. It is possible to confugure it to look only to the
local file (for specific accounts, or for all accounts), but it won't
get you kerberos tickets in this case. This also assumes that the
user has figured out how to set a local passwd and local homedir (see
my comments in the AFS section) for the local account.
Also, note that if the laptop comes up on a different IP address
(likely) kerberos will give random (possibly confusing errors) about
the IP address being wrong. We may be able to work around this in
krb.conf, but that could conceivably casue other problems.
> Recommendation 5: Enable time synchronization, but remember to
> properly bring it down and up when the network goes down and up.
As jhawk noted, you explicitly don;t want to turn off ntpd when you
fall of the net (it will continue to trim the clock based on the level
of drift it determined while on the net). However, the above does not
apply if the laptop is in suspend or hybernate mode (my laptop clock
is regularly off by up to 30s after I resume.) For this and other
reasons if may be a good ide to set the clock when we pop back onto
the net, but that could also confuse ntpd.
Also, right now the biggest problem we have with time service is
trying to set the clock at boot time when off the net.
> Issue 2: Consider providing ways to notify nomadic users of the
> availability of updates that go beyond the current Athena
> implementations.
Issue 2a: consider the security implications of machines that don't
autoupdate when a remotely exploitable bug is patched.
I think you should add a section on DNS in general. as we've noted
above, it affects many other services, and is IMHO a seperate problem
that we need to solve.
Jonathon
