www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Hudson access for non-PMC member
Date Fri, 29 Jan 2010 09:24:08 GMT
On 28/Jan/2010 12:46, Gav... wrote:
>> -----Original Message-----
>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>> Sent: Thursday, 28 January 2010 2:04 AM
>> To: builds@apache.org
>> Subject: Re: Hudson access for non-PMC member
>> On 27/Jan/2010 11:26, Justin Mason wrote:
>>> Hi Philip --
>>> it's purely because the user accounts on the Hudson machines have
>>> quite a lot of privileges.
>> Anything much more significant than people's privileges via their
>> people.a.o accounts?
>>> Personally I'm open to the idea of making an exception if the AVRO
>> PMC
>>> call for it, and assuming none of the other Hudson admins are against
>>> it.
>> Not against it, but if there is a flood of new account requests from
>> committers I'd like to examine whether we can roll those machines into
>> the existing infra routines.
> What has been talked about in the past, to the Hudson admin team, is restricted
> access to Hudson Admins ONLY on the main Hudson Master box. This is going to be
> implemented real soon now and those not in the Hudson Admin Team will have their
> accounts removed.
> Regarding the slave machines, Minverva/Vesta , only those PMC members and approved
> Committers (approved by their PMC if they are not PMC Members) that need shell
> accounts will get one. All accounts will need to login using an SSH key as password
> logins will also be disabled. If you have an account on Minerva/Vesta please ensure
> you have a pub key installed and in use as we will switch to this system soon.
> Rather than seeing 500+ accounts on these machines I would rather see as few as 
> possible, with those having accounts helping out the maintenance and configurations
> for all projects and not just their own.

Agreed.  There is a steady stream of requests for accounts, and while
I'm happy to enable people to make progress on their project tasks, we
are building a potential problem for administering all those users.

> I've seen here and elsewhere maintenance become a nightmare for machines with too many
> accounts, too many people doing configurations for their projects which overwrite or
> overrule configurations for other projects, folks upgrading stuff which makes tests
> useless for certain projects because they depended on the older version etc.

... and just the day to day aspects of creating accounts, resetting
passwords, etc. etc.  Which is why I called for rolling these machines
into the regular ASF Infra routines if we choose to go down that route.

> It may seem a pain for some, not being able to just log in and do as they like, but I
> would rather they asked instead for things to be done, and those things be done by a
> few volunteers, such as is the case for the majority of Infra machines. This will make
> maintaining and upgrading and keeping secure the machines a whole lot easier, and those
> that volunteer to look after the machines (not just their own project interests) will
> get to know the machines, where things are, what can and can not be upgraded/replaced
> etc. Minverva/Vesta are in need of patching as a minimum and dist-upgrade preferable
> considering the recent cve releases this past couple of weeks. We need people that
> can perform these Operating System level upgrades and patches, and know what to do if
> any of that breaks stuff for projects.

Yep.  I see no significant difference here with the regular business of
infra.  Can Minerva/Vesta/Hudson-Win be wholly adopted by infra for

> So, I'm certainly -1 on continuing down this track of giving shell account to anyone
> who asks for it, it's just not workable and not sensible. 


> I am absolutely +1 on Hudson Admin Team maintaining these boxes and giving out shell
> accounts to the few PMC members that really need it, and also expanding out the 
> Hudson Admin Team if necessary to add a very few more folks that will maintain all
> aspects of the machines for the benefit of all projects.

Or reducing/removing the responsibility of the "Hudson admin team" and
making these 'real' ASF Infra managed machines.

I don't have the time (or skills!) of the dedicated infra folk here, and
while I know I can call on you and Philip to help out if things go
wrong, better to have the machines properly managed in the first place.


View raw message