[117] in athena10
Re: Missing pieces in Athena 10
daemon@ATHENA.MIT.EDU (Timothy G Abbott)
Tue Mar 11 15:25:21 2008
Date: Tue, 11 Mar 2008 15:24:37 -0400 (EDT)
From: Timothy G Abbott <tabbott@MIT.EDU>
To: ghudson@mit.edu
cc: athena10@mit.edu
In-Reply-To: <200803111803.m2BI39D8006250@outgoing.mit.edu>
Message-ID: <Pine.LNX.4.64L.0803111406270.15118@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 11 Mar 2008, ghudson@MIT.EDU wrote:
> aptitude tells me the following pieces are missing for installing
> debathena-standard from the Athena 10 test apt repository:
>
> libsasl2-krb4-mit
> debathena-dotfiles
> debathena-moira-clients
> debathena-pine
> pine
It may be useful to generate filler equivs packages to temporarily fill
some of these holes so that you don't block on these particular clients
for testing things (for example, without AFS homedirs, you don't actually
use debathena-dotfiles). Not that I necessarily think this needs to be
done in this case, but it's a useful trick.
> Plans for dealing with these:
>
> cyrus-sasl: Rework to use debathenificator and stick into third.
Sounds good.
> dotfiles: Debathena has a package based on packs/dotfiles from the CVS
> tree; I didn't import this. My project plan here is to eliminate the
> concept of platform-independent dotfiles and thus the structure of
> packs/dotfiles, instead creating from-scratch packages in
> debathena/debathena/dotfiles and debathena/debathena/root-dotfiles.
Sounds good.
We should consider removing some of the weird nonstandard features of the
Athena system dotfiles that generate confusion (e.g. CDPATH) in the
process.
The Athena 10 release may also be a good time to change the default shell
for new accounts to bash (since that is the standard shell for everything
these days), but that's probably a topic for another thread.
> moira clients: I assume ops would like Athena 10 to continue using the
> moira locker for moira clients, which is not what Debathena does. So
> debathena-moira-clients in Athena 10 will presumably be a package full
> of attach-and-run scripts.
It's not ideal for the Moira clients to depend on AFS. This is a big
problem for laptops, where AFS tends to fail and take a long time to
recover when one switches networks. While admitedly this is AFS's fault,
I don't think AFS reliability problems on laptops are going to go away
soon.
If we decide to go this route, we'd probably want to take tytso's
suggestion that Moira clients demand upgrade when they have an out-of-date
protocol version to avoid problems when the Moira server upgrades.
> pine: The best answer here is to create a debathenificator alpine
> package for the necessary code and build configuration changes and
> maybe create a debathena-pine-config. The quick answer is to bring in
> Debathena's pine package (which is based on third/pine). I may start
> with the quick answer.
Since alpine is packaged in Debian, using the debathenificator on it seems
optimal (one may want to add various -backports repository for building it
on some distributions...).
I think the only thing we do to configure pine is set its sendmail command
to /usr/lib/debathena-msmtp. If we decide to go through with the plan to
configure this script as the generic sendmail program for the system (with
Provides: mail-transport-agent and all that), then we may not need a
debathena-pine-config package.
Since I think commands line "mail" should also be able to send authentic
email on Athena 10, this may be the right approach.
-Tim Abbott
