[7058] in Release_7.7_team
Re: Agenda for 11/19 meeting
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Wed Nov 17 17:11:15 2010
Message-Id: <201011172211.oAHMB8Jr028924@speaker-for-the-dead.mit.edu>
From: Jonathon Weiss <jweiss@MIT.EDU>
To: Jonathan Reed <jdreed@MIT.EDU>
cc: "release-team@MIT.EDU" <release-team@MIT.EDU>
In-reply-to: Your message of "Wed, 17 Nov 2010 11:35:01 EST."
<8AEDB213-0F67-4824-B099-7C8987D1772B@mit.edu>
Date: Wed, 17 Nov 2010 17:11:08 -0500
> Please send additional items to me.
>
> - Broken machines: There are a number of perpetually broken machines =
> (macgregor-5) which have repeatedly failed re-installation. We need a =
> good solution for these. In at least one case, the machine was =
> re-installed by me personally and worked just fine in N42, but upon =
> deployment to macgregor, it magically turned back into =
> debathena-workstation.
also barker-6-1 and m4-237-1 which "can't configure unconfgured packages"
>
> - Related to the above, "machtype -L | grep "debathena-cluster" is not =
> an acceptable substitute for "PUBLIC=3Dtrue". While there's some =
> argument that private workstation install logs shouldn't be publicly =
> available, w20-575-1 should, for example, always display all logs =
> publicly, even if Debathena installation failed somehow or it got =
> downgraded to workstation. I can think of several ways to accomplish =
> this: Query for hesiod cluster=3Dcluster to determine whether to view =
> the information, or have the -cluster installation create a flag file =
> (/etc/athena/public) in the sysroot at install time, and use that file =
> to determine whether a machine is "public" or not. That way, debugging =
> info will be available even for pseudo-failed installs.
For the install log itself, we can probably get away with always
displaying it even on private machines, but we can discuss on Friday.
Jonathon
