[4133] in Release_7.7_team
Re: An idea for a technically enforced definition of 'Administered
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Nov 29 01:17:29 2003
From: Greg Hudson <ghudson@MIT.EDU>
To: Bill Cattey <wdc@mit.edu>
Cc: owls@mit.edu, release-team@mit.edu, openafs-release@mit.edu
In-Reply-To: <1069791126.20186.84.camel@tokata.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1070086639.14143.96.camel@error-messages.mit.edu>
Mime-Version: 1.0
Date: Sat, 29 Nov 2003 01:17:20 -0500
On Tue, 2003-11-25 at 15:12, Bill Cattey wrote:
> Idea: Define "A system supported by Athena" as a system that makes that
> daily syslog.
> Enforcement: Modify Athena software execution scripts to run a test (it
> might mean a subtle change to the syslog stuff) to see if that
> syslogging is enabled. If not, error out with a message,
However we do this, some number of people are likely to read the script
and figure out what they need to do to fake it out. I'm not sure how
much you're worried about that.
> Stated differently: When we give people stand-alone AFS, some may well
> expect to run Athena locker software, except that the locker software
> will be relying on a bunch of stuff out of /usr/athena that we're just
> not installing. I think it would be better to build some mechanism
> whereby scripts test explicitly for "Athenized" rather than blowing out
> with obscure errors depending on which Athena tool is missing in the
> course of running the start-up script.
If the problem is technical--that we want to give a better error when
someone tries to run locker software on a non-Athena machine--then we
can simply look for the presence of /etc/athena/version.
If the problem is one of licensing, then we're stuck in a cat-and-mouse
game; any reasonable amount of athenization we might look for can be
easily faked up.
