*.x.org vs xorg.freedesktop.org, again (was: Re: State of the archive)

[Egbert Eich]

Daniel Stone writes:
 > On Wed, May 10, 2006 at 07:51:04PM +0200, Egbert Eich wrote:
 > > This however is different from the 'who gets access to those machines?'
 > > question.
 > > The mirroring would remedy the problem of not having latest releases
 > > (especially security) available on the box - even without anyone needing
 > > to access the machines.
 > 
 > They're not the same problem, but they are related, and I can't say that
 > I even begin to understand the bizzare 'no-one but the board gets access
 > to the machines/website' policy, given that:

Being on the board I'm not happy with this either. The people on the
board are probably the last ones to get things moving on these machines
as they are all burdeoned by other duties :-/
Although there is hope as one board member has committed himself to
adminstrating the SUN machines.
I myself don't really need this access - although I used it once to
recover the machine from a filesystem corruption which prevented it
from booting.

 >   * xorg.freedesktop.org is, again, the master archive server, rendering
 >     any 'security' processes on ftp.x.org utterly moot;

right.

 >   * xorg.freedesktop.org is also the de facto website, rendering access
 >     controls on www.x.org mostly irrelevant.

fully agreed.
I think the only caveat here is that expo is the canonical mirror site.
Therefore - in order to keep the burdeon of our mirrors low - the directory
structure needs to be organized in a way that only long lived data gets
mirrored.

 > 
 > I find it odd that we trust ninety-one people to commit code to CVS:
 > code that runs as root on most people's systems, yet we only trust a
 > number of people I can assume to be <= 5, to update ftp.x.org, and
 > www.x.org.

I thought we had come to a common understanding on this.
I can certainly follow your line of arguments.
Even if one argues that a security compromise can be spread to
all the mirrors much more quickly if some messes with a package
file there exist technical solutions to make this rather difficult.

 > 
 > This made sense in the TOG days.  It does not even remotely make sense
 > now.
 > 
 > > 2. The machine has remote management. This allows us to kick the machine even
 > >    when not in place. I've done this once (being dialed into the internet
 > >    thru an analog line - as nobody else volunteered to do so).
 > 
 > I believe expo.x.org is (like fruit, kemper and annarchy), a Proliant
 > DL385.  Remote management on those machines is, in a word, ridiculous.
 > You have remote power management and remote console by default,
 > including over SSH, and if you have the super advanced trickery, you can
 > feed it an ISO image over the network, and say 'turn on and boot this'.

Yeah, except that we don't have a graphical login. Which requires some
trickery when booting install images as they by default switch to a
graphical screen. 
This however is a very minor obstacle and a graphical login via a 
java plugin in your browser is not really a 'must' for remote
admin.
Also the new SUN machines have remote management.

 > 
 > The only scenario I can see local access being necessary for on fd.o is
 > something that requires physical change: either replacing components, or
 > rewiring.
 > 

Yep.

Cheers,
	Egbert.