Hi Phil, [ Note: re-reading, I find that my mail could be read as "heated", which it wasn't meant to be. I'm firm in what I believe needs to be done, but not angry :-) ]
On Mon, Mar 28, 2011 at 03:08:12PM +0200, Philipp Kern wrote: > > So, AIUI, only members of the wbadm GID can change keys, not any random > > buildd admin. > > > > If I'm supposed to be maintaining a buildd host, I should be able to > > update the key allowed for signing, or I can't do my job properly. We've > > had a situation where only a limited group of people could activate > > buildd machines in the past, and it was broken; I have no desire to get > > back to that situation. > > AFAIR you were against autosigning on your buildds. So nothing will change > for you anyway, unless you allow it. You may remember from your wanna-build BOF during dc10 that I said something along the lines of "yes, I know I said I was against it. I changed my mind." :-) > As Joerg said, we still have that problem because only gid=wbadm can > change the ssh keys on grieg. I wasn't aware of that; I was under the impression that I could update ssh keys when and if I needed to. You're not helping :-) > And only gid=ftp-master can change the list for the hosts allowed to > access incoming. (To be fair: DSA now exports a list of d.o buildds > to ftp-master to automatically allow access to ftp-master's incoming > directory and to security-master.) And you need the machine installed > with the buildd profile by DSA in the first place. Sure. There's always going to be some things I can't do, if we want the machine to be running properly (that is, unless I become a member of the appropriate teams, but given my current time constraints that isn't very likely). But I'd think that "making sure this buildd host can still do uploads in a timely manner when the key expires" is pretty well inside the realm of the buildd admin's responsibility. > > Please fix this by doing one of > > - Adding me (and other buildd admins) to the wbadm group, > > - Creating a new GID to which all buildd admins are added (I'd suggest > > 'builddadm' for that, but apparently that's already taken and is 100% > > the same as wbadm; if that isn't used, however, it could make sense) > > which would limit who can update keys > > - Changing the GID to "Debian", rather than anything else (I don't think > > you lose much by doing that, but I guess there might be reasons not > > to, and it's not my call anyway) > > - Finding someone else to maintain praetorius and voltaire > > The purpose of the wbadm group is the maintainance of the central > wanna-build host. We also control who accesses our infrastructure and > how. That's already the case since years. Do you have any complaint > about the request turnaround time there? Not currently. However, I was not initially complaining about the request turnaround time back when the wanna-build team consisted mostly of James and Ryan, either. But eventually that changed, and I got very very very frustrated with that[1]. When the buildd stuff was changed so that many more people got involved, I was hoping that this kind of thing would never happen again. Now I'm not saying that every buildd admin should have full and unlimited access to wanna-build.d.o, or that we should all be responsible for maintaining the wanna-build software (i.e., I'm not suggesting to make wbadm and the set of buildd admins be one and the same group). But I do think that when you add a new responsibility, you should figure out whether this responsibility is in the realm of the buildd admin or not. I believe that this one is, and therefore I should be able to do it myself without requiring outside intervention. As said, usually the request turnaround time is very reasonable, and I have no complaints there. But there have been times where it was slightly longer than average, and adding more things on the heap of stuff which only you guys can do isn't helping. And, really, when a key rollover needs to be done, most of the work is "gpg --gen-key", and scp'ing the public key to the right system. If I can do all that, but need one of you to run "mv $key $targetloc", that's just adding needless bureaucracy. I want to avoid that, because I don't believe it makes sense. If the fear is that people will add keys without following proper procedure, then please document the procedure in a way which makes it hard to miss, and by all means bitchslap those who fail to follow procedure properly. The set of "buildd admins" is small enough that this should be workable. But I don't think it makes sense to take an already limited group of people (buildd admins) and limit them even further for things that lie squarely in their area of responsibility. I don't really care about SSH keys, because they don't change (unless someone breaks in and steals them, but then I expect DSA to step in, lock down the host, do forensics, reinstall, etc, and eventually generate a new SSH key while they're at it). I wouldn't care about signing keys if they didn't change, either, but they do, so I think it's something I need to be able to fix if someone pops up on IRC and asks me why $HOST (which I just happen to maintain) isn't uploading. If tomorrow someone decides that buildd SSH keys need to be rotated too (which would make sense, BTW), then I want the ability to change them on the host where buildd needs to run wanna-build. As it is, I don't think there's a need for that. [1] Note that I'm not trying to complain here about Ryan's performance in the end; as it turned out, he had very good reasons to refuse adding hosts at that point in time, but that didn't change the fact that it was frustrating. > The builddadm group is a group that's allowed to log in to all buildds > and thus is root-equivalent for quite some machines. Thus the two > groups are separated. Makes sense, I guess. > The whole key management thing isn't really limited to gid=wbadm by > design, it's just that you need to be able to access ftp-master and > have the key signing key in the admin keyring. This suggests that you wouldn't object to it being changed so that gid=wbadm isn't involved as such, provided there's a proper technical method for doing so? > The idea is that we could even do the key rotation bit for you, which > means less work for the buildd admin. What I wanted to say is that while you could basically do everything for me, you don't necessarily have the time to do so. Yes, much of it is automated, but it sucks if suddenly things break and you need to fix everything everywhere. That's why we put a person in charge of a particular buildd host and call him/her a "buildd admin". So I think that things which need doing on a per-host and regular basis for buildd stuff should be something that the buildd admin can do all by himself. What you've just done is adding something that would need to be done on a per-host and regular basis, without the ability of me doing it all by myself. That's bad. > > For clarity, the last option is *not* my preference. However, if none of > > the other three are done, I'm no longer interested in spending my time > > doing something I can't do properly anyway. I've been forced to work > > around not being able to fix issues with connectivity between my buildd > > host and the rest of the Debian infrastructure in the past, and I won't > > stand for it anymore. > > I'm not sure why it's more of a problem than it used to be. I'd be sad > to lose you as a buildd admin. I'm not actually sure why you threaten > us with it, though. It wasn't meant as a threat, but it's certainly something I feel very strongly about. I'm definitely willing to work with you and everyone involved to find a solution that will satisfy everyone; but I'm not willing to work within the confines of a system that unnecessarily limits my ability to do my work properly. As such, if no solution is found for this problem, I've no choice but to step down as buildd admin. Regards, -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html
signature.asc
Description: Digital signature