16:04:58 <sgallagh> #startmeeting Server SIG Weekly Meeting (2015-02-17)
16:04:58 <zodbot> Meeting started Tue Feb 17 16:04:58 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:58 <sgallagh> #chair sgallagh mizmo nirik stefw adamw simo tuanta mitr danofsatx
16:04:58 <zodbot> Current chairs: adamw danofsatx mitr mizmo nirik sgallagh simo stefw tuanta
16:04:58 <sgallagh> #topic roll call
16:05:02 <nirik> it got disconnected. ;(
16:05:26 <sgallagh> .hello sgallagh
16:05:39 <mitr> Hello</echo>
16:06:25 <nirik> hi
16:06:28 <sgallagh> We don't have quorum, which is unfortunate, but let's proceed and we'll worry about it if we have to
16:06:35 <sgallagh> #topic Agenda
16:06:44 <sgallagh> #info Agenda Item: Fedora 22 Alpha
16:06:48 <sgallagh> #info Agenda Item: Database Server Role
16:06:48 <sgallagh> #info Agenda Item: Cockpit Domain Controller Support
16:07:29 <sgallagh> Anyone have other topics requiring discussion today?
16:08:04 <adamw> don't think so
16:08:15 <sgallagh> #topic Fedora 22 Alpha
16:08:21 <junland> Not that I can think of.
16:08:40 <sgallagh> So, Alpha Freeze begins a week from today, which means that Monday is the last chance to get non-blocker changes into Alpha.
16:09:28 <sgallagh> This realistically means that the two major Changes we've proposed (see the other two agenda items) must be substantially complete and testable by Monday.
16:10:23 <sgallagh> I've been working on both of these features personally, but I send out a call for help last week, since there's no chance that I can finish both efforts in the next five days.
16:10:40 <sgallagh> #link https://lists.fedoraproject.org/pipermail/server/2015-February/001734.html
16:11:00 <sgallagh> twoerner and danofsatx have offered to help with the DB role completion
16:11:28 <sgallagh> But as of this morning's hacking on it, I suspect I'll still be needed there as well for at least another day or two worth of work.
16:11:33 <nirik> I can try and help, but have also been very busy... (was out at datacenter all last week and still trying to catch back up)
16:12:01 <sgallagh> (if only because it's more efficient for me to fix the bugs in what I've already written)
16:12:26 <nirik> so, perhaps we should concentrate on the db role and move the domain controller stuff to f23?
16:12:28 <sgallagh> #topic Database Server Role
16:12:40 <junland> same here, kinda stuck with a programming internship with my university.
16:12:47 <sgallagh> nirik: I'm leaning that way, without a sudden influx of help with JavaScript.
16:13:08 * nirik knows enough js to use noscript to block it and thats about it I am afraid. ;(
16:13:09 <sgallagh> I had hoped to find some time over the weekend to study up, but yet another blizzard put paid to that
16:13:42 * adamw not sure he can realistically add anything more to his workload at this point either :/
16:13:53 <adamw> i had the same idea independent of both of you
16:14:00 <adamw> (and i'd be learning js on the fly too)
16:14:01 <sgallagh> From conversations with the Cockpit folks, I'm convinced that if stefw or mvo opted to take it over, it could be relatively easily completed in the remaining five days.
16:14:13 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:14:18 <sgallagh> ... thanks zodbot
16:14:25 <adamw> zodbot, you're drunk. go home.
16:14:29 <junland> ha.
16:14:44 <sgallagh> #undo
16:14:44 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x677ae90>
16:14:50 <junland> Zodbot needs more RAM.
16:14:52 <nirik> it was just rejoinin it's about million channels.
16:14:59 <nirik> no, it needs less channels or a faster freenode. ;)
16:15:01 <sgallagh> (We're covering both topics, might as well leave it under the earlier agenda topic)
16:15:18 <junland> nirik: haha
16:15:45 <sgallagh> I wish stefw was around, but I believe he's on PTO today
16:16:18 <sgallagh> So without additional JavaScript expertise, I suppose we defer this effort.
16:16:47 <sgallagh> We can try to get it into the upstream project that carries its releases in COPR so we're ready for F23 early on, I guess
16:18:17 <nirik> yeah, sooner the better
16:19:11 <sgallagh> Anyone opposed?
16:21:21 * nirik is not
16:21:29 <sgallagh> #agreed Cockpit support of the Domain Controller Role is deferred to Fedora 23
16:21:31 * junland is not
16:22:05 <junland> Think it's good so we can smooth out this critical role.
16:22:12 <sgallagh> #action sgallagh, twoerner and danofsatx to work on finishing the DB role for Fedora 22 Alpha Freeze
16:22:16 <junland> Granted most of these roles are critical...
16:22:53 <sgallagh> junland: Well, the functionality of the DC role is already present in F21. This was about adding the UI to Cockpit to make it more easy to use.
16:23:14 <sgallagh> #topic Database Server Role
16:23:36 <sgallagh> There are a couple open questions about the DB role that we should try to address.
16:23:37 <junland> Thanks for the correction. :) It's been a while, been on and off with helping out.
16:24:05 * junland lots of stuff todo.
16:24:16 <sgallagh> So, one thing that remains is the default configuration. I'd like to run my thoughts passed you folks before we implement it.
16:24:43 <sgallagh> One of the goals of the Roles is that, once the deploy() method is called, the system should be "accessible" to other services.
16:25:11 <sgallagh> The default configuration of PostgreSQL is to allow only local access to users that can be associated with a local account
16:25:35 <sgallagh> However, this means that nearly all real-world usage of the server requires reconfiguring it to allow external access by DB-specific users.
16:26:17 <sgallagh> So my plan is that we will have the Role deployment configure it to accept the 'md5' auth type from any source location and control those locations at the firewall layer rather than the postgres config.
16:26:36 <sgallagh> Does that seem reasonable, or am I missing an obvious flaw?
16:27:31 <mitr> Most importantly, do we have the interface necessary to edit the firewall config in such a way?  (Just firewall-cmd, or something in rolekit?)
16:28:06 <mitr> Secondarily, this opens the default firewall configuration / zones can of worms, but that can be deferred.
16:28:54 <sgallagh> mitr: At the moment, firewall-cmd is the best approach for manipulating that.
16:29:15 <sgallagh> I know that we were going to add this to the API, but I missed whether twoerner did so
16:29:22 <mitr> fair enough I think
16:29:37 <adamw> i worry about the server admin poking at the firewall config without fully grokking its the only access control to his DB
16:29:40 <adamw> or her. sorry.
16:29:49 <sgallagh> I think we were going to be able to tie it to firewalld zones at least, and use zone definitions as the way to manage which interfaces had access, etc.
16:30:11 <adamw> but god, pg access control, why do you make me relive those memories
16:30:34 <sgallagh> adamw: Because you seemed too happy this morning :)
16:30:39 <nirik> that sounds like a good initial approach at least.
16:30:42 <adamw> well, you cured that.
16:30:44 <twoerner> sgallagh: we have support for zones, services and ports in there..
16:30:52 <nirik> if it turns out poor, we can try something else. ;)
16:30:56 <twoerner> sgallagh: to open up ports or services in zones
16:31:00 <adamw> but yeah, i don't see an immediate problem
16:31:06 <sgallagh> twoerner: The services and ports are in the API or the role specification?
16:31:08 <mitr> support != default configuration
16:31:14 <twoerner> sgallagh: both
16:32:11 <mitr> At a first glance it seems reasonable to me to have default “public-facing” and “internal-data-center” zones, and to have the DB server role automatically open only for the latter… but once we do this we shouldn’t change the default firewall config of the zone any more.
16:32:24 <mitr> And I’m not sure we can figure this out correctly in 5 days.
16:32:29 <adamw> so far as possible i'd want us to try and make it obvious to the admin in firewall config tools / files / whatever if they were about to a) block access to the db or b) remove the access control
16:32:34 <sgallagh> We don't have to figure *that* out in five days
16:32:42 <sgallagh> That's firmly a Beta target in my mind
16:32:47 <mitr> makes sense
16:32:51 <sgallagh> It needs to be functional and testable in five days.
16:32:56 <sgallagh> Not necessarily *correct* :)
16:33:48 <junland> I guess after the freeze, I can go ahead and start writing some test cases. :)
16:34:02 * junland wants to pitch in a little.
16:34:06 <sgallagh> junland: That would be very helpful
16:34:12 <junland> :)
16:35:04 <twoerner> sgallagh: firewall and firewall_zones in the role settings
16:35:16 <sgallagh> Right, I completely forgot about that.
16:35:25 <sgallagh> twoerner: Does it require a redeploy() to take effect?
16:35:33 <twoerner> ok.. I have to leave now
16:35:36 <twoerner> sgallagh: yes
16:35:38 <sgallagh> Or rather, to change it live
16:35:50 <sgallagh> Ok, so redeploy() isn't quite ready, but I'll fix that between Alpha and Beta
16:36:05 <sgallagh> So I think we at least have a reasonable story here.
16:36:12 * twoerner is leaving
16:37:16 <sgallagh> mitr, adamw: If the interface for the access is handled by rolekit, are you still concerned about the admin perception of it?
16:37:29 <sgallagh> I suppose if they change the firewall outside of rolekit, it could get confused.
16:37:34 <adamw> sgallagh: i'm worried about the case where the admin is poking at the firewall outside of...yeah.
16:37:42 <mitr> sgallagh: having it a part of the deploy configuration would be ideal from my POV
16:37:57 <adamw> i don't think we're at our ideal world where server admins never touch anything but our Awesome Shiny Tools, yet. :)
16:37:58 <sgallagh> mitr: It already is, so I think we're good there.
16:38:04 <sgallagh> The redeploy() comment was about being able to change it
16:38:23 <mitr> An admin explicitly enabling a service on a new interface is, to me, a sufficient indication of intent.
16:38:35 <sgallagh> adamw: Sure, but I'd also hope that if they're doing central firewall management, they already know enough to be blocking everything by default and whitelisting what they care about.
16:38:35 <junland> I have to leave you guys, got some stuff todo today.
16:38:42 <mitr> (Ignoring the whole firewall-is-a-second-layer-of-confirmation-to-prevent-dumb-mistakes use case)
16:40:00 <sgallagh> mitr: RE: "indication of intent". That's pretty much my thought as well. Though I acknowledge the argument that it's intent that it be available "somewhere", but not necessarily "everywhere"
16:40:26 <sgallagh> But I don't think we can do any better than "default to everywhere, give them an option to restrict it", which we have.
16:40:37 <mitr> sgallagh: I don’t thing the DB Role is an appropriate place to be fixing unclear firewall UIs (if any)
16:40:43 <sgallagh> albeit only at the firewall
16:40:52 <sgallagh> heh, agreed
16:41:46 <sgallagh> OK, so "good enough" until we're told otherwise?
16:42:11 <mitr> The open-to-the-internet default is… debatable.  But also easy to change, so “good enough” for me.
16:43:20 <adamw> especially with anything with 'md5' in the name, but i'm not gonna pretend to know the details there.
16:43:33 <mitr> adamw: AFAICS it is either plaintext, md5, or GSSAPI.
16:43:47 <adamw> yeah.
16:43:52 <mitr> The last one would be best but also not something we can quite rely on.
16:44:25 <sgallagh> And actually (not?) surprisingly difficult to set PosgreSQL up to use
16:44:47 <adamw> definitely not surprising.
16:44:49 <sgallagh> Particularly since you have to have service accounts for any application that's going to connect to it, etc.
16:45:04 <adamw> i'm sure there's something it's easy to make postgre do, but i haven't found it yet.
16:45:08 <adamw> well, fail.
16:45:11 <sgallagh> FWIW, I think "md5" may actually be historical.
16:45:19 <adamw> that's what i was guessing/hoping/whatever
16:45:21 <sgallagh> I suspect it's using a better hash than that
16:45:30 <adamw> though it does still explicitly say "MD5' in the current version of the docs
16:45:37 <adamw> but hey. we can't control that.
16:45:41 <sgallagh> /me cries
16:46:46 <sgallagh> #info The Database Server Role will be open on all interfaces upon deployment, but can be constrained using port/service configuration in rolekit.
16:47:04 <sgallagh> #info It will also be configured to use password-based authentication
16:47:14 <sgallagh> ok, I don't have anything else on this topic at the moment.
16:47:20 <sgallagh> #topic Open Floor
16:48:26 * nirik has nothing much
16:48:42 <mitr> (looking at http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/interfaces/libpq/fe-auth.c;h=8927df4f064a2d7fced76954c0c7207c91ae636b;hb=HEAD#l492 it is definitely md5)
16:49:44 <adamw> we do need the database server role requirements (in my shiny new format)
16:49:59 <sgallagh> adamw: Right. Link?
16:50:43 <adamw> sgallagh: just model it on https://fedoraproject.org/wiki/Domain_controller_role_requirements
16:50:48 <sgallagh> ok
16:51:00 <adamw> use the same template and make sure it's in the same category and that should be all
16:51:09 <sgallagh> danofsatx: You wanted to help, so I'm going to let you and junland craft that page and I'll review :)
16:51:43 <sgallagh> #action danofsatx and junland to create database server role requirements document modeled on https://fedoraproject.org/wiki/Domain_controller_role_requirements
16:52:14 <adamw> 'core' are the really basic requirements without which it can't be said to be working at all, 'requirements' are the rest of the things it ought to be capable of each release (they all block Final, so don't go too mad), tests is the test cases that check the requirements
16:53:25 <sgallagh> So Core should be working at Alpha, presumably
16:53:30 <sgallagh> And "Requirements" at Beta?
16:53:46 <sgallagh> (not necessarily blocking, but targeted at)
16:54:09 <adamw> sgallagh: it's in the criteria
16:54:45 <adamw> at alpha the 'core requirements' have to basically work, at beta 'core' has to work without any workarounds and main requirements have to basically work, at finally they all have to work without workarounds
16:54:49 <adamw> sort of a rolling process
16:54:58 <sgallagh> Oh right
16:55:02 <adamw> https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria#Role_functional_requirements (and same URL for beta/final)
16:55:04 <sgallagh> (Sorry, it's been a couple weeks)
16:55:13 <sgallagh> (... today)
16:55:41 <adamw> =)
16:55:54 <adamw> if we don't have test cases that cover the requirements, we need to make 'em.
16:56:27 <sgallagh> Yeah, that's what junland was volunteering to do
16:56:30 <sgallagh> So I'll happily let him
16:56:41 <adamw> yay junland
16:56:46 <adamw> poke me if you need help
16:57:44 <sgallagh> OK, anything else?
16:58:55 <sgallagh> /me sets the fuse
16:59:14 <sgallagh> 3...
16:59:32 <sgallagh> 2...
16:59:47 <sgallagh> 1...
16:59:58 <sgallagh> Thanks for coming, folks.
17:00:00 <sgallagh> #endmeeting