1 |
On Sat, Nov 19, 2005 at 10:03:58PM +0000, Kurt Lieber wrote: |
2 |
> On Sat, Nov 19, 2005 at 01:51:15PM -0600 or thereabouts, Brian Harring wrote: |
3 |
> > Stop pointing at one interpretation of it that sucks, when the glep |
4 |
> > _does_ leave it open to you how to implement it. It's a waste of |
5 |
> > people's time and bandwidth, and is a bit disenguous. |
6 |
> |
7 |
> I'm trying to find a solution to the issues as I see them. Telling me I'm |
8 |
> wasting people's time and bandwidth doesn't seem conducive to working |
9 |
> together towards a resolution to this all. If you're going to say, "it was |
10 |
> passed, you guys just have to find a way to implement it. now please stop |
11 |
> bothering us" then I'm going to come up with an implementation plan that |
12 |
> looks something like the following: |
13 |
> |
14 |
> * all SSH keys and email addresses for arch testers will auto-expire after |
15 |
> 60 days. If an arch tester needs to have continued access, a gentoo dev |
16 |
> will have to re-submit the key and recreate the alias for that arch |
17 |
> tester every 60 days. |
18 |
> |
19 |
> That meets the requirements of the GLEP down to the letter and also |
20 |
> satisfies infra concerns around key management. However, it's a crappy |
21 |
> solution. |
22 |
> |
23 |
> So, I'd much rather work together towards finding a better one. |
24 |
|
25 |
Simple solution, that I've repeatedly pointed at. Use the existing |
26 |
ldap setup. It's not infra's responsibility to add their accounts nor |
27 |
disable them (that is left in the air as stated, although I'd expect |
28 |
it'll fall on devrels head). Infra doesn't even do retirement beyond |
29 |
when _devrel_ asks them to. If that process is slow, ask for help and |
30 |
someone will chip in and improve it (mainly to minimize bottleneck |
31 |
involved). |
32 |
|
33 |
A simple script handling a pull from ldap sshPubKey attribute |
34 |
updating $USER/.ssh/authorized_keys on lark, you've got the cvs ro |
35 |
issue licked. Doesn't require anything crazy/new, and could be |
36 |
implemented in no time- no infra overhead beyond an initial setup cost |
37 |
for cvs, which I would be willing to implement myself. |
38 |
|
39 |
It's minor to do it within existing framework, which is why I've |
40 |
stated it's daft pointing at the minimal requirement as admin hell. |
41 |
~harring |