Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Andreas K. Huettel <dilfridge <at> gentoo.org>
Subject: Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014
Newsgroups: gmane.linux.gentoo.project
Date: Tuesday 3rd June 2014 22:02:59 UTC (over 3 years ago)
Am Montag, 26. Mai 2014, 14:13:32 schrieb Rich Freeman:
> The next Gentoo Council meeting will be on 10 Jun 2014, at 19:00 UTC.
> 
> Please reply to this email with any proposed agenda items.

Here's an agenda item. For discussion at the moment, since this is not 
something the council can decide on its own; we need the help of Infra and
the 
foundation. Hopefully it will turn into something concrete, though more on
the 
lines of a GLEP or an Infra policy. Several Infra and Council members have 
contributed ideas.

########
Create a mechanism how Gentoo developers can 
* host non-critical services 
* on self-provided machines or later Gentoo-provided machines
* visible in a subdomain of gentoo.org, 
* which they themselves administer fully and are fully responsible for
* outside the direct control of Infra, but with some limitations (see
below)

See it as a semi-official staging area for future core services.

The foundation is asked to consider supporting such initiatives financially
if 
they are clearly in the interest of the general developer community.
########

Why?

The Gentoo infrastructure is administered with the help of tools like
cfengine 
or puppet, designed to distribute configuration to many machines. The way
this 
is set up now, fine-grained access control is not yet possible. Which means

that someone planning deployment of a new service on an official machine
needs 
to get access to the central repositories and thereby intrinsically also
power 
over core, critical services such as, e.g., cvs. 

Obviously administrative access to critical services should be restricted
to a 
small trusted group, and this is what Infra is. 

Any new service that does not need any elevated access permissions towards 
core critical services (example, a repoman-checker that grabs the public 
portage tree, analyzes it and generates alerts; example 2, a program that 
parses ebuild SRC_URI, checks for availability of future versions, and 
displays that information on a web interface) is effectively and
unnecessarily 
blocked by this architecture. 

Our admins are busy keeping the core infrastructure running and safe (and
they 
are doing this very well, thank you!); it's understandable that they may
not 
want to accept additional burdens. Here's the way around it. 

Many of the pieces needed are already possible. This initiative aims to
make a 
package of it and advertise it.

What limitations?

This is mostly obvious stuff.

* The maintainers need to take security into account
* Minimal/none interaction with core services (except publically available 
things)
* No use of infra passwords / credentials
* Disclaimers on the service if web-based
* Possibly some sort of infra access as non-privileged user required, e.g.
for 
running glsa-check

Cheers & happy discussion, 
Andreas

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/
 
CD: 3ms