Sysadmin report on the modernization of our infrastructure

[Ben Cooksley]

On Thu, Jan 22, 2015 at 3:03 PM, Jan Kundrát <jkt at kde.org> wrote:
> On Wednesday, 21 January 2015 23:57:07 CEST, Ben Cooksley wrote:
>>
>> Using either
>> http://www.guywarner.com/2014/06/part-2-integrating-phabricator-and.html
>> or http://www.dctrwatson.com/2013/01/jenkins-and-phabricator/ or a
>> variation thereof.
>
>
> That is quite some custom code that one has to maintain, though.

Doesn't look like an excessive amount to me, once you strip out the
comments (which all code should have anyway).

Some of it also governs how Jenkins reports back to Phabricator -
allowing to provide fine grained commentary on test success or
failure. We could probably extend it to report on cppcheck or code
coverage differences if someone wanted to even.

I see our control over that as a plus point - so developers don't have
to go look somewhere else to see the exact nature of the failure
(whether build or test related).

>
>> Commit emails could either be sent by our existing hooks, or we could
>> migrate to Herald and customise it's template to fit what we need if
>> necessary.
>> People would filter them / subscribe to them through Herald.
>
>
> How would they subcribe via Herald if it was done via the existing hooks?

Herald can generate mails itself and send them.
While you wouldn't get the same commit mails unless we change the
template Herald uses, you will get the commit mails.

>
>> Doesn't seem too high, although I don't see how that would be made web
>> accessible - which might be the hard and costly part maintenance wise.
>> (You have to deal with security issues too as you are in a separate
>> web application, so you need to authenticate the developer first).
>
>
> Well, Apache's mod_authnz_ldap and a "Require group developers" stanza makes
> this really easy. Just look up $user from an appropriate env var provided by
> the web server. Where is the problem?

It's a separate web application to maintain. I'll admit that does
solve the authentication issue nicely, except for the part where
developers can't log out unless they close their browser.

>
>> Our existing solution is triggered on change events in LDAP and causes
>> all SSH keys to be re-read and a new ~/.ssh/authorized_keys file to be
>> written out. You can't rely on OpenLDAP stating the addition/removals
>> properly when using the syncrepl interface, at least in my experience.
>> In this way we avoid dependence on the Identity web application.
>
>
> A quick & dirty approach:
>
>  `ssh bot at gerrit set-account $user --remove-ssh-keys ALL`
>  `ssh bot at gerrit set-account $user --add-ssh-key - < authorized_keys`
>
> A better and race-free code would have to invoke `comm` in addition to that,
> and only add/remove keys which has to be removed or added. That's left as an
> excercise for the reader, it's easy enough. Or, to avoid relying on a local
> state altogether, just issue a REST call for SSH key retrieval and base a
> decision on that. It's gonna be like 10 lines of custom code.
>
> Cheers,
> Jan
>

Regards,
Ben

>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/