[1324] in athena10
Re: [Debathena] #124: De-crustify the CellServDB
daemon@ATHENA.MIT.EDU (Tom Fitzgerald)
Fri Mar 6 16:36:33 2009
From: Tom Fitzgerald <tfitz@MIT.EDU>
To: Evan Broder <broder@mit.edu>
Cc: Jonathon Weiss <jweiss@mit.edu>, debathena@mit.edu
In-Reply-To: <49B16928.5070304@mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Fri, 06 Mar 2009 16:33:13 -0500
Message-Id: <1236375193.5851.40.camel@sligo.mit.edu>
Mime-Version: 1.0
> Would you be open to trimming down the CellServDB to a shorter list of
> cells than the full list maintained in grand.central.org? Since all
> current Athena systems can use DNS these days (they can, right?), it
> seems like having entries for cells that aren't essential to Athena is
> just asking for them to become out of date.
I'd argue against this.
Ops shouldn't be in a position of deciding which cells are
essential to all Athena users. Admins of new cells shouldn't
have to jump through two hoops to get them recognized on Athena.
And users shouldn't be put in the position of figuring out why
a computer installed from a public openafs package can get to a
cell while an Athena system can't.
If a cell is dead, the grand.central.org people should be asked to
remove it from the full list - if it's not, it might be useful to
someone on Athena, now or someday.
Granted, entries for cells that have AFSDB records are redundant
on Athena systems, but they're also harmless and it's more work to
remove them.