13:01:06 <bstinson> #startmeeting
13:01:06 <centbot> Meeting started Mon Sep 15 13:01:06 2014 UTC.  The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:06 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:01:27 <bstinson> #meetingname CBS-Infra-2014-09-15
13:01:27 <centbot> The meeting name has been set to 'cbs-infra-2014-09-15'
13:01:52 <bstinson> #chair alphacc Arrfab kbsingh bstinson MerlinTHP_
13:01:52 <centbot> Current chairs: Arrfab MerlinTHP_ alphacc bstinson kbsingh
13:02:45 <bstinson> #topic Is this a good time to meet?
13:02:54 <MerlinTHP_> Well, it works for me :)
13:03:51 <alphacc> Me too if we keep it under 30 min
13:04:01 <bstinson> Good, I think we should make this a regular thing (weekly, or every-other-week) for a while until we run out of things to talk about
13:04:09 * MerlinTHP_ nods.
13:04:11 <bstinson> short meetings are good
13:04:17 <alphacc> I think weekly is good for now.
13:04:39 <MerlinTHP_> Agreed, i imagine we can find things to talk about
13:04:57 <wolfy> works for me too. although I am just a lurker
13:05:18 <bstinson> #agreed Weekly meetings on Monday at 13:00 UTC
13:06:36 * lalatenduM is here too
13:06:54 <bstinson> #topic SIG/Developer authentication
13:07:39 <alphacc> so far cbs has his own CA, I don't know the status of git.c.o auth
13:07:53 * MerlinTHP_ assumes it's ssh key auth
13:07:59 <MerlinTHP_> Can anyone confirm?
13:08:08 * kbsingh is here
13:08:14 * gwd is here
13:08:17 <bstinson> we also need to worry about the lookaside cache
13:08:42 <MerlinTHP_> I'd be tempted to start from a default position of "what does fedora infra do?"
13:09:01 <MerlinTHP_> If only that they've solved a lot of this stuff, and have existing tooling
13:09:10 <bstinson> I think FAS is on the radar
13:09:24 <kbsingh> i am not sure if FAS is indeed on the store for CentOS though - is it ?
13:09:38 <MerlinTHP_> I've heard it mentioned, but nothing conclusive.
13:09:49 <kbsingh> there certainly hasent been any movement on that front - FAS was brought up a few times, but only in line with other potential solutions as well
13:09:49 <gwd> What's FAS?
13:09:57 <Arrfab> alphacc: atm git.c.o uses his internal auth DB
13:09:58 <kbsingh> gwd: the Fedora Accounting System
13:09:59 <MerlinTHP_> Fedora Account System
13:10:24 <MerlinTHP_> I'm not sure we really want to build something from scratch.
13:10:33 <alphacc> Arrfab: but gitblit does support ssl cert ?
13:10:45 <kbsingh> git.centos.org can more or less do anything, includiung ldap, krb, shared certs, shared ca, pub certs, internal pipe backend for auth or even static files
13:10:51 <kbsingh> alphacc: yes
13:10:57 <MerlinTHP_> What does g.c.o do now?
13:11:13 <kbsingh> MerlinTHP_: flat file, internal auth
13:11:24 <MerlinTHP_> I suppose we're at the point of not having a huge userbase to reeducate
13:12:24 <kbsingh> are we talking purely in the context of git.centos.org + cbs.centos.org ? I guess having FAS like system would help if were to come up system wide for all of .centos.org - and we can move wiki + bugs + forums + other things to it as well
13:12:41 <MerlinTHP_> I'd suggest that ideally the latter
13:13:15 <MerlinTHP_> In addition to FAS, I'd be tempted to throw IPA into the ring as an option too.
13:13:48 <MerlinTHP_> I spend a fair amount of time in $dayjob getting stuff to auth against our IPA instace.
13:14:04 <Arrfab> MerlinTHP_: such discussion started too, but the scope is wider than just cbs+git which is supposed to be the "to be discussed points" today
13:14:06 <alphacc> kbsingh: yes. In term of interaction between cbs/git we just need people to be able to create branches at the git level
13:14:26 <MerlinTHP_> Arrfab: agreed.
13:14:38 <MerlinTHP_> Seems silly to build something just for cbs & git, though
13:15:34 <kbsingh> how would branches in git.c.o work - at the moment, the distro brach is locked - noone can commit to those. and I've been working to have branch name be the sig name for someone
13:15:37 <alphacc> MerlinTHP_: I think it's better to test the workflow for building and defer auth for later.
13:15:54 <kbsingh> eg. VirtSig people will need to work with their own branch - but wont be able to create and push to other ones, unless they had acl's for other sig's as well
13:16:21 <MerlinTHP_> alphacc: I'm just a bit worried about getting people too familiar with something that we might well change later
13:16:21 <Arrfab> MerlinTHP_: agreed too, but it would be good to know what are the blockers now on the git/cbs status. and if common auth is the real issue, then another meeting around centralized auth can be foreseen :-)
13:17:19 <alphacc> MerlinTHP_: the koji part won't change, and educate user to access git with pass or ssh key doesn't seems an issue for our audience
13:17:27 <MerlinTHP_> alphacc: fair enough
13:17:40 <gwd> kbsingh: So I think we need to be able to have dev branches from which we can issue a pull request.
13:17:50 <alphacc> MerlinTHP_: I would agree if it was for everybody.
13:18:29 <MerlinTHP_> alphacc: I'm a bit worried that you don't scale, though ;)
13:18:37 <MerlinTHP_> alphacc: you're doing all the account creation by hand atm?
13:19:04 <alphacc> MerlinTHP_: correct. this is part of this week documentation effort.
13:19:05 <Arrfab> MerlinTHP_: yes, but afaik less than 10 people have access through approved SIGs
13:19:17 <kbsingh> in terms of forward-looking-planning, my estimate on user accounts to end of the year 2014 is 50
13:19:27 <MerlinTHP_> OK
13:19:27 <kbsingh> and in the next 18 momths, is to grow that to 150
13:19:44 <bstinson> which is not so bad
13:20:10 <kbsingh> most SIG's are only going to have a few people commiting into git.centos.org right ? I'm counting on the biggest ones having 10
13:20:18 <Evolution> I still think long-term it should be automated, rather than blocking on a specific person
13:20:27 <Evolution> or group of people.
13:20:31 <MerlinTHP_> Mm
13:20:48 <MerlinTHP_> This is one of those "FAS has already solved this issue" things, tbh
13:21:04 <kbsingh> gwd: would'nt that be local though ? eg. if come of people want to do local branches ? or are you saying that people will need commit access to git.centos.org where from a 'privileged' account can merge into the production branch and issue a build req ?
13:21:06 <Evolution> yeah. fas or a bit of scripting around ipa.
13:21:11 <MerlinTHP_> Evolution: exactly
13:21:27 <alphacc> Evolution: yes agreed
13:21:36 <MerlinTHP_> TBH I personally like IPA a lot, but I'm trying not to be too biased ;)
13:22:01 <kbsingh> gwd: if we want the push coming to git.centos.org - we might need to workout some sort of a convention for personal branches.
13:22:18 <kbsingh> automate everything
13:22:49 <gwd> kbsingh: Well it doesn't need to be on git.c.o, if that's what you mean; it could be on gitorious/github/some other public repo.  But wherever it is, we want to be able to build from it.  At least, I assume the burden of testing to make sure it builds properly should be on the person sending the pull request, not on the person potentially doing the pulling. :-)
13:23:04 <kbsingh> specially, since automation is the only way to really make sure there is a 'user-exiting' cleanup process as well
13:23:15 <MerlinTHP_> Just bear in mind that koji needs config for each git server you want to pull from
13:23:26 <kbsingh> MerlinTHP_: it will only pull from git.centos.org
13:23:27 <MerlinTHP_> I'd recommend only having koji pull from g.c.o
13:23:33 <MerlinTHP_> Right.
13:23:39 <alphacc> yes
13:24:02 <MerlinTHP_> So anything you want to build has to end up in g.c.o, even if people are pushing to github or whatever
13:24:34 <Arrfab> MerlinTHP_: yes
13:24:43 <kbsingh> yeah, its a good problem domain to fix, its the classic who CI's and how does the CI queue work
13:24:46 <alphacc> MerlinTHP_: There is SRPM use case, but I really didn't find any good reason.
13:24:47 <gwd> MerlinTHP: Then that would imply either 1) sending pull requests from trees that haven't been tested on koji or 2) having development trees on git.c.o so that things could be tested on koji before sending a pull request
13:25:06 <kbsingh> i wonder if we can have people do scratch builds, and the results be a consideation for people doing the pulls
13:25:16 <alphacc> gwd: koji should not become a CI.
13:25:28 <MerlinTHP_> Yeah, koji isn't great for CI
13:25:37 <kbsingh> i dont think gwd is talking CI though
13:25:51 <MerlinTHP_> Right.
13:25:53 <kbsingh> were not testing the code, per se - its just to make sure the branch is buildable
13:26:04 <kbsingh> maybe --scratch builds might be a middle ground there ?
13:26:05 <alphacc> Yes just a warning, casue I have koji users :)
13:26:21 <gwd> Just because it build via an SRPM doesn't mean it will build from a git tree. :-)
13:26:44 <MerlinTHP_> There's not that much difference between koji building a package and mock on a user box, as long as mock is using the koji repos.
13:26:54 <kbsingh> gwd: right, but koji only ever builds from a srpm - the git is just where the srpm is stored, were never building from git
13:27:15 <kbsingh> when koji gets a build-this, it git checksout, make it into an srpm - then does the mock run to build rpms out of it
13:27:17 <MerlinTHP_> Well, koji pulls the source from git and builds a srpm
13:27:24 <alphacc> kbsingh: yes
13:27:24 <MerlinTHP_> Yeah, tha
13:27:25 <MerlinTHP_> t
13:28:13 <bstinson> (bringing it back in a little bit) it sounds to me like we aren't quite ready to talk about long-term auth
13:28:21 <kbsingh> nutshell: gwd's point is that people need to be able to propose changes, without running their own buildsystems. right ?
13:28:24 * MerlinTHP_ is getting that ;)
13:28:28 <MerlinTHP_> +feeling
13:29:30 <bstinson> what can we do in the short term to get people access to the lookaside caches? i know that's come up a couple of times
13:29:45 <MerlinTHP_> Auth with the same SSL cert they use for koji?
13:30:10 <alphacc> bstinson: I think we need at least docs on the process will be handled.
13:30:27 <MerlinTHP_> The upload script for fedora's lookaside is public, and can be easily adapted to our cache
13:31:07 <MerlinTHP_> I can hunt that out if there's interest
13:31:07 <alphacc> MerlinTHP_: can it be part of centpkg ?
13:31:11 <kbsingh> are we talking about https://git.centos.org/sources/ ?
13:31:26 <bstinson> kbsingh: yes
13:31:27 <MerlinTHP_> Yeah
13:31:35 <kbsingh> the privileged path to that store is via ssh or rsync over ssh at the moment
13:31:42 <Evolution> 868963
13:31:43 <MerlinTHP_> Hmm
13:31:58 <kbsingh> but its a flat filesystem, so a cgi script ( like what fedora use ) might be easy to adapt, and we can protect branches at the unix level
13:32:09 <Evolution> 195082
13:32:16 <kbsingh> ( ie. I can make sure the buildsystem and distro branches are owned by someone else )
13:32:27 <kbsingh> Evolution: move your yubi key to a different usb port
13:32:32 <MerlinTHP_> Heh
13:32:36 <alphacc> ah ah
13:32:39 <Evolution> bah, was dialing phone.
13:32:47 <kbsingh> alternatively, folks - anyone needing to break into Evolution's 2FA accounts, you ahve about 180 seconds to use those two codes
13:32:48 * Evolution moves laptop
13:32:50 <MerlinTHP_> No, you weren't ;)
13:32:55 <bstinson> heh
13:33:18 <kbsingh> i need a better keyboard, way too many typos
13:33:31 <bstinson> alphacc: to answer your question, it's already built into rpkg we just need to figure out how to say if a user has upload privs or not
13:33:32 <kbsingh> so, what / how would centpkg integrate with the sources / lookaside push ?
13:33:47 <MerlinTHP_> centpkg has upload support
13:33:57 <MerlinTHP_> It needs tweaking for centos' cache layout
13:34:11 <MerlinTHP_> It does an HTTPS request with the client cert for auth
13:34:42 <MerlinTHP_> sorry, rpkg has that, centpkg can override that code
13:35:02 <alphacc> ok
13:35:14 <kbsingh> what do we need on the server to support that push ?
13:35:31 <MerlinTHP_> A CGI script on an HTTPS server with some client auth config
13:35:41 <MerlinTHP_> So cgi + httpd config
13:35:47 <kbsingh> what sort of auth backend can that support ?
13:36:05 <kbsingh> also, upload via https.... is going to need some multipart fluffery
13:36:40 <MerlinTHP_> That bit is a solved problem, afaik.  rpkg already does it
13:36:57 <MerlinTHP_> The server validates the client cert against our CA
13:37:14 <MerlinTHP_> Needs a CRL to be able to revoke certs.
13:38:14 <kbsingh> right, so this would then share the ca with koji ?
13:38:19 <MerlinTHP_> Yeah
13:38:39 <kbsingh> and we'd need to have git.centos.org also then use the same CA
13:38:47 <MerlinTHP_> Mm
13:38:55 <MerlinTHP_> IPA getting more attractive by the second...
13:38:56 <MerlinTHP_> ;)
13:39:31 <alphacc> if we keep the koji CA (and use it for soemthing else) we may want to move easy_rsa + git-crypt (for scaling issue)
13:39:37 <alphacc> or FreeIPA ;)
13:40:36 <gwd> I'm more of a stout man myself...
13:40:40 <kbsingh> gitblit can maknss calls as well if that makes life easier
13:40:53 <kbsingh> can make nss
13:41:22 <kbsingh> from the git.centos.org perspective, we can use pretty much anything and it will consume it .
13:41:27 * MerlinTHP_ nods.
13:41:49 <kbsingh> there are 2 things that we need to protect though - (1) there is always going to be a privileged path for rhel sources and buildsystem feedback - both of those can never fail
13:42:09 <kbsingh> and (2) we need a way to gurantee branch names and commit access to branch names is locked down
13:42:33 <bstinson> does gitblit currently give you that control?
13:42:34 <kbsingh> so if the auth setup is going to happen at koji CA - that needs to provide a user:sig name mapping which can be used to map users:branch
13:42:34 <MerlinTHP_> Can gitblit do that per-branch stuff?
13:42:38 <kbsingh> bstinson: yes.
13:42:52 <MerlinTHP_> Hrm
13:43:20 <MerlinTHP_> We need more than just a CA for this
13:43:30 <MerlinTHP_> CA + something with groups and things like that.
13:43:33 <kbsingh> I worked with the author of gitblit ( james moger ) to work that in, and I've made some more tweaks at this end that make it work quite nicely
13:43:49 <MerlinTHP_> That's cool.
13:44:10 <kbsingh> for the git code itself, and the lookaside cache - the privleged path is via ssh
13:44:28 <kbsingh> and gitblit does not mind that, it will happy refresh local git content cache if it finds the underlaying storage changee
13:44:53 <MerlinTHP_> I'd have assumed that git+ssh was the default push method anyway
13:45:06 <kbsingh> fwiw, gitolite can also consume and implement a user:branch mapping
13:45:37 <kbsingh> push mode for git is over https
13:45:41 <MerlinTHP_> Oh, ok
13:45:54 <kbsingh> thinking there is that if we need entity verification, an EV cert will give you that
13:46:31 <MerlinTHP_> Do we have a cert revocation system for the current koji CA?
13:46:48 <MerlinTHP_> If I lose my laptop with koji cert now, what happens?
13:47:09 <alphacc> MerlinTHP_: we can revoke access to koji
13:47:23 <alphacc> MerlinTHP_: no crl right now but agreed it's needed.
13:47:55 <MerlinTHP_> Is that turn off the user, or turn off the cert?
13:48:05 <MerlinTHP_> ( so to speak )
13:48:16 <alphacc> MerlinTHP_: user
13:48:21 * MerlinTHP_ nods.
13:49:02 <bstinson> ok, let's start wrapping up
13:49:07 <alphacc> MerlinTHP_: user-rsa when Arrfab show me it existed. I don't want to reinvent the wheel.
13:49:16 <MerlinTHP_> alphacc: *nod*
13:49:23 <alphacc> MerlinTHP_: easy_rsa
13:49:26 <MerlinTHP_> Being a CA is a PITA.
13:49:45 <MerlinTHP_> OK, so, do we have any sort of consensus? :)
13:49:54 <MerlinTHP_> Or anything to have a consensus about
13:50:34 <MerlinTHP_> koji requires either SSL or KRB auth, and we're using SSL.  Trying to use that for everything we can sounds appropriate?
13:50:44 <MerlinTHP_> Sounds like g.c.o can use it
13:51:07 <bstinson> so (if i'm understanding correctly), we want gitblit to talk to the koji CA but we need to work out some name:sig mappings, and we want to look at having the lookaside cache use the fedora-style cgi script
13:51:08 <MerlinTHP_> We need a way to store cert / user / group / sig info
13:52:00 <kbsingh> yeah, if we can get some groups info in there that would rock
13:52:16 <MerlinTHP_> OK
13:52:16 <kbsingh> if not, we can always store user:group mappings in gitblit itself, and just have it querry the CA for auth
13:52:31 <MerlinTHP_> I reckon we probably want that centrally too
13:52:41 <kbsingh> and i presume the upload script can do something with the same CA as well ... if so - then we should trial it - or start trialing it at git.dev.centos.org
13:52:53 <kbsingh> yeah, ideally all the info would be in one place
13:53:01 <MerlinTHP_> It's the httpd config rather than the script itself, but yeah
13:53:40 <kbsingh> ah i see
13:53:50 <kbsingh> but will that be able to map user's to dir names ?
13:53:59 <bstinson> once all that's in place we can sculpt centpkg around our setup
13:54:04 <kbsingh> eg. if someone is locked to branch 'virtsig' they can only upload into <packagename>/virtsig/
13:54:17 <MerlinTHP_> kbsingh: ok, that bit would need script changes :)
13:54:40 <MerlinTHP_> the httpd-level stuff is authn, the authz would need to be in the script, I think
13:55:28 <bstinson> Is MerlinTHP_ volunteering to look at that for the next meeting?
13:55:36 <MerlinTHP_> Sure
13:56:30 <bstinson> ok, great!
13:56:35 <MerlinTHP_> :)
13:56:47 <MerlinTHP_> Running out of meeting
13:56:48 <kbsingh> when are we meeting next ?
13:56:54 <MerlinTHP_> Same time next week?
13:57:09 <kbsingh> ok, weekly works, but longer term we should think about making it bi-weekly
13:57:13 <MerlinTHP_> Sure
13:57:18 <kbsingh> maybe do ~ 6 weekly ones ?
13:57:21 <bstinson> #info Next meeting: Monday 22-Sept 2014 13:00 UTC
13:57:36 <bstinson> kbsingh: that's reasonable
13:57:40 * MerlinTHP_ nods.
13:58:12 <bstinson> #info We will be doing 6 weekly meetings, then moving to a bi-weekly schedule
13:58:14 <lalatenduM> works for /Me
13:58:24 <MerlinTHP_> Is there a meetbot give-merlinthp-an-action command? ;)
13:58:41 * MerlinTHP_ should read the manual
13:59:20 <lalatenduM> does "#action" work
13:59:21 <bstinson> #action MerlinTHP_ Research lookaside cache authentication and upload permissions
13:59:35 <MerlinTHP_> Ah :)
13:59:42 <bstinson> i think i said that right
13:59:52 <MerlinTHP_> Works for me.
13:59:54 <bstinson> anything else that needs to go in the minutes?
14:00:07 <kbsingh> is someone going to look at storing user:groups in the koji auth layers
14:00:18 <MerlinTHP_> I'll have a think about that too
14:00:19 <kbsingh> there must be something like this already - since users are limited to some tag's and targets
14:00:27 <kbsingh> cant those just be the groups and sig names as well
14:01:32 <alphacc> kbsingh: user are limited to the tagging action not to some target. This policy stuff need investigation. I don't think there is a group directive.
14:02:54 <MerlinTHP_> OK, so we done with the meeting? :)
14:02:59 <bstinson> gwd: i think that was you who sent a message to -devel with other agenda items, sorry our discussion sort of trampled over yours
14:03:00 <alphacc> #action alphacc investigate koji policy for cbs.
14:03:08 <bstinson> hopefully there will be time for an open-flood next week
14:03:53 <bstinson> #info send agenda items for next week to the centos-devel@centos.org
14:04:01 <bstinson> 1 minute warning before I close the minutes
14:04:16 <MerlinTHP_> I'm good.
14:04:44 <kbsingh> same here
14:05:02 <kbsingh> i think were going to need some of these sessions of just open chat before we start working on and only on agenda items.
14:05:04 <alphacc> ok with me.
14:05:28 <bstinson> sure thing
14:05:31 <bstinson> #endmeeting