On 28/Jan/2010 12:46, Gav... wrote: >> -----Original Message----- >> From: Tim Ellison [mailto:t.p.elli...@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 administration? > 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. Agreed. > 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. Regards, Tim
