[6544] in Release_7.7_team
Re: Collaboration document update
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Thu Dec 3 18:51:42 2009
Date: Thu, 3 Dec 2009 18:51:35 -0500 (EST)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Evan Broder <broder@mit.edu>
cc: release-team@mit.edu, debathena-dev@mit.edu
In-Reply-To: <2706d8dd0912031253l67215d52xa70b7b84d4da8d5c@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0912031843380.21147@dr-wily.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Flag: NO
X-Spam-Score: 0.00
On Thu, 3 Dec 2009, Evan Broder wrote:
> I suspect that forcing updates to a given machine would be seen as
> moderately dangerous if it was allowed to run unauthenticated (I'd
> certainly be skeptical of it), and we can't authenticate to cluster
> machines.
You could certainly have some sort of signed metadata file on
debathena.mit.edu saying what machines are permitted to take what updates.
Cluster machines would check this file every 5-10 minutes, verify it
against the Debathena apt key, and see if there's anything special to do
-- e.g., grab a certain package out of our -proposed or Ubuntu's, take an
auto-update immediately, attempt to back out a package, or inhibit
auto-updates -- listed under its hostname.
Part of why I want this is it makes the process of testing packages on
cluster machines through the auto-update process much less hokey, which is
a good thing for system stability anyway.
--
Geoffrey Thomas
geofft@mit.edu
