16:00:23 <nirik> #startmeeting Server SIG Weekly Meeting (2015-01-13)
16:00:23 <zodbot> Meeting started Tue Jan 13 16:00:23 2015 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:24 <nirik> #chair sgallagh mizmo nirik stefw adamw simo tuanta mitr danofsatx
16:00:24 <nirik> #topic roll call
16:00:24 <zodbot> Current chairs: adamw danofsatx mitr mizmo nirik sgallagh simo stefw tuanta
16:01:12 <mitr> Hello
16:01:24 <adamw> a glorious herd of yaks charges through the western planes, their coats flowing in the breeze...if you look carefully you can just make out a forlorn, adamw-shaped figure chasing them with a disposable razor
16:01:36 <nirik> sgallagh indicated he would be a bit late and asked me to start the meeting
16:01:38 <adamw> also, plains.
16:01:41 <nirik> ha
16:01:50 <junland> Hello
16:02:10 <tuanta_> .hello tuanta
16:02:11 <zodbot> tuanta_: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com>
16:02:16 <simo> .hello simo
16:02:17 <zodbot> simo: simo 'Simo Sorce' <ssorce@redhat.com>
16:02:22 <junland> . hello junland
16:02:23 <zodbot> junland: junland 'John Unland' <opensourcejohn2112@gmail.com>
16:03:36 <nirik> #topic Agenda
16:03:43 <nirik> anyone have any items for agenda?
16:04:11 <adamw> just an apology for not getting the role description wiki page/whatever plan done yet, it's coming, i promise...
16:04:47 <danofsatx|w> I'm here, sorry I'm late
16:04:51 <danofsatx|w> .hello dmossor
16:04:51 <simo> nirik: there are some change proposals for F22 which maybe we'd want to discuss, in order to make a SIG recommendation ?
16:04:51 <zodbot> danofsatx|w: dmossor 'Dan Mossor' <danofsatx@gmail.com>
16:05:22 <nirik> ok.
16:05:24 <simo> nirik: one of them I do not like is the one to change sshd configuration to not allow root in w/ password
16:05:41 <nirik> #info Discuss pending F22 changes related to server
16:05:51 <nirik> any other topics?
16:06:34 <danofsatx|w> have a link to those proposals, simo?
16:06:43 <nirik> I'm really not sure where we are with the database role... we punted it to f22, but I've had no time to work on it.
16:06:55 <nirik> danofsatx|w: lets wait for that topic...
16:07:01 <simo> danofsatx|w: I only followed them on the fedora-devel@ listy
16:07:11 <danofsatx|w> that's what sgallagh said he wanted to poke at in his mail (the db thing)
16:07:28 <junland_2> Sorry lost connection
16:07:41 <nirik> yeah.
16:07:50 <nirik> ok, lets go on to the one about f22 changes then.
16:07:57 <danofsatx|w> oh, sorry nirik.....I'm a bit frazzled this morning
16:07:57 <nirik> #topic Discuss pending F22 changes related to server
16:08:32 <nirik> simo: https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no is the one you were concerned with right?
16:08:47 <simo> yes
16:09:07 <simo> it concerns me on usability grounds for the server image
16:09:11 <simo> but perhaps it is just me
16:09:19 <nirik> They did change it to without-password
16:09:25 <simo> so I wonder if we need to act wrt it or not
16:09:29 <nirik> but without any way to get keys at install time...
16:09:35 <simo> nirik: exactly
16:09:46 <simo> it means you *have* to have a console to log in the first time
16:09:59 <simo> how likely is that in cloud environments and the like ?
16:10:17 <mitr> At this point this seems like a very minimal security improvement with serious usability impact, and that usability impact has minimal attention.
16:10:19 <simo> I fear we are making sure people will *not* use fedora server in their virtualized environment or even bare metal
16:10:28 <mitr> simo: cloud-init is supposed to take care of that
16:10:28 <danofsatx|w> the cloud images are deployed with a key.
16:10:35 <simo> at my hosting provider I do not pay the extra fee for the luxury of hooking up a KVM
16:10:51 <simo> mitr: cloud-init for people that use it sure can do anything
16:11:06 <simo> but I am talking of fedora server installed from the DVD
16:11:09 <simo> just a plain install
16:11:17 <simo> you do it,. you set the password ... and you are locked out
16:11:20 <nirik> or a pxe/netinstall
16:11:27 <simo> how many users are going to jump through the hoops
16:11:32 <mitr> simo: I think this discussion needs to be split between the principle of the thing and between what we would get for F22.
16:11:35 <simo> netinstall is the same
16:11:45 <junland_2> Sorry  when was the bug found? Before the release or after?
16:11:50 <simo> mitr: the principle is: increase security, sure
16:12:01 <danofsatx|w> junland_2: it's not a bug, it's a change proposal
16:12:02 <simo> mitr: but we need to be practical too
16:12:06 <junland_2> Ah
16:12:16 <simo> first access is a usability/presentation issue too
16:12:24 <simo> for workstations it doesn't matter
16:12:31 <simo> people will just log in graphically
16:12:40 <mitr> That's not the principle I mean :)
16:12:41 <simo> but for server it is a whole different story
16:12:42 <mitr> As for the principle, any individual server can have a non-root user created at install time, and this would work fine. (What to do about IPA clients that loose domain access is the unresolved question)
16:12:46 <nirik> and workstation has no sshd listening. ;)
16:12:57 <simo> nirik: exactly
16:13:01 <mitr> But I am afraid that with the month left we would not get all the UI and defaults smoothed out.
16:13:03 <simo> so IMO this is a bad change
16:13:18 <simo> and I never create local users
16:13:24 <danofsatx|w> neither do i
16:13:25 <nirik> mitr: then you login as that user and join the domain? so you are left with some weird local admin user? ;(
16:13:41 <simo> nor does anyone that do not care for them because they do not have users just "application users" that gets created later
16:13:44 <mitr> nirik: Yeah, that's the ugly/proglematic part.
16:14:13 <simo> mitr: the ugly/problematic part IMO is trying to force a questionable configuration on people "for their own good"
16:14:13 <mitr> I would really like to end up with root having _no_ password (not even for local logins) so that accesses are associated with physical people (or automated applications)
16:14:18 <nirik> it would be easier to just have some way to set 'root login with password is acceptable' in ks or the anaconda ui (defaulting to no)
16:14:34 <danofsatx|w> I like that word, mitr - porglematic. I'm going to remember and use that one ;)
16:14:41 <danofsatx|w> proglematic, too
16:14:45 <junland_2> Haha
16:15:06 <simo> nirik: I think a server admin knows how to disable root if they so desire
16:15:30 <mitr> simo: Kickstarts and shell scripts are always a fallback for people with hard requirements or fixed opinions; we _should_, though, be making it easy to have a useful and safe configuration.
16:15:34 <sgallagh> /me arrives and reads scrollback
16:15:35 <simo> I think this change is actively harmful for the server experience
16:15:53 <simo> mitr: we should be make easy to *use* this stuff
16:16:01 <simo> *then* we can think of making it more secure
16:16:11 <simo> but if security gets in the way of usability we fail
16:16:18 <simo> and I strongly think this change is such a change
16:16:47 <junland_2> So if admins have an option todo that there needs to be a window in anaconda where you can load / write a script when your installing
16:16:49 <adamw> that smells like a false argument to me
16:16:55 <adamw> just about any form of security impedes some kind of 'usability'
16:17:06 <adamw> it's more usable if you don't have to waste time typing a password...
16:17:09 <mitr> simo: I do agree, we need to make whatever the new path is easy, and the migration painless.  I think we only differ in that i do not consider “log in using the root account“ a use case, only a tool for some other use case.
16:17:28 <simo> adamw: not that just more convenient (for some)
16:17:40 <simo> adamw: and you achieve that by setting a ssh key or using gssapi or similar
16:18:04 <simo> mitr: my use case is simple, I am a guy that installs from ISOs
16:18:07 <nirik> simo: at install? I guess in %post?
16:18:08 <simo> I dop not use kickstarts
16:18:23 <simo> so this change locks me out unless I have a way to do console logins
16:18:28 <adamw> simo: i'm gonna give you credit for being able to see the rhetorical point i'm making and not chase that red herring.
16:18:28 <simo> it is that simple
16:18:45 <sgallagh> nirik: I think simo's point is "default install, log in as root, join a domain"
16:19:15 <simo> sgallagh: "default install, log in as root to do any configuration"
16:19:26 <nirik> so I guess to point this more productive way: a) can we suggest a way to make this change acceptable or more acceptable for server ? b) do we want to recomment it be rejected by fesco?
16:19:37 <simo> even copying ssh keys is a royal pain if you can't scp ssh_key root@1.2.3.4
16:19:47 <mitr> simo: No, there must be some  other essential parts of your use case that result in not having any local user accounts.  If anaconda didn't let you finish before creating a user account (and did not even prompt for a root password), would you finish the install, and use that account?  If not, why not?
16:19:56 <sgallagh> Sure, so an interesting question here is "Can we make Cockpit sufficiently useful that having root logins via SSH is no longer necessary by default?"
16:20:19 <simo> mitr: I would have to finish, log in as that account, enable root, kill the account then join to ipa
16:20:35 <simo> mitr: because I need no stinking local accounts when I use a domain server like FreeIPA and AD
16:20:46 <simo> and local accounts are just dangerous as they are not managed
16:20:48 <sgallagh> (And making "root-over-ssh" an option in Cockpit somewhere?)
16:20:58 <mitr> simo: Fair enough, IPA is a pain point, but then that is no longer the "simply install from a DVD" case :)
16:21:07 <simo> sgallagh: how do you log into cockpit ?
16:21:22 <simo> mitr: it is
16:21:23 <sgallagh> simo: root with password :)
16:21:29 <sgallagh> But it's a restricted set of actions
16:21:29 <simo> mitr: that's what I do for my machines
16:21:38 <simo> mitr: I simply install then as the first thing I join the domain
16:21:51 <simo> sgallagh: makes no difference :)
16:22:06 <sgallagh> simo: Sure it does.
16:22:10 <mitr> sgallagh: That only trivially changes the bruteforce target.  It is not entirely useless, like the change to prohibit root logins is not entirely useless, but it only makes a marginal difference in the protection.
16:22:11 <simo> the point is that yes, as a security person I can recommend people to disable root
16:22:12 <sgallagh> With SSH, you have no limits
16:22:19 <simo> but that is a far thing from making it a forced default
16:22:59 <simo> mitr: right so we get a highly annoying usability issue for a very marginal protection
16:23:19 <sgallagh> Well, regardless of the default setup, can we perhaps agree that enabling or disabling root SSH is worth making a setting in Cockpit?
16:23:19 <nirik> so, would it make sense for server to have a different config from everything else on this?
16:23:30 <mitr> simo: So, a hypothetical: anaconda that forces you to choose between domain membership and a root account, or not domain membership and a sudo-privileged local account.  Acceptable?
16:23:34 <simo> if we want protection from password guessing attacks I rather install by default a tool that blacklists/throttles attackers IP addresses instead
16:23:42 <simo> installed by default
16:24:03 <sgallagh> I thought we had that...
16:24:05 <simo> mitr: they tried to put domain joinnig in anaconda for 3 releases
16:24:08 <mitr> nirik: We already have a different config on ssh being enabled / deployed because they change the defaults :)  As for PermitRootLogin, I think that's a distraction.
16:24:11 <nirik> they all suck and are horrible, IMHO
16:24:14 <simo> mitr: it always fails to work for me for whatever reason
16:24:19 <sgallagh> simo: It's there in kickstart and works for me
16:24:41 <simo> sgallagh: in F21 ?
16:24:57 <sgallagh> simo: RE: domain-join in kickstart, yes
16:25:05 <sgallagh> I tested it as part of the F21 validation
16:25:11 <simo> last I tried it was admittedly F20, then I stopped bothering as it was failing horribly
16:25:11 <nirik> sgallagh: and in the ui? or only ks?
16:25:24 <sgallagh> nirik: only KS right now
16:25:25 <simo> ks is not sufficient
16:25:42 <sgallagh> I didn't say it was. But the capability is there, so adding the UI should be feasible
16:25:42 <simo> anyway
16:25:45 <mitr> sgallagh: On the Cockpit setting for PermitRootLogin, unsure.  Would like to make statistics of what accounts and with what frequency are being accessed, but intuitively I would say that it is not worth it.  Rather have anaconda/Cockpit make it easy to deploy and use ssh keys (can cockpit even work with pubkey auth?)
16:25:52 <simo> I will personally cope whatever people do
16:26:03 <simo> I just feel it is a bad move for the server product
16:26:11 <sgallagh> mitr: Cockpit doesn't currently work with pubkeys, only GSSAPI
16:26:30 <mitr> sgallagh: Right, sorry, I should have remembered.
16:26:32 <sgallagh> stefw indicated that it was in progress, but I'm unclear on whether it will be there for F22
16:27:27 <sgallagh> simo: BTW, you're right. We don't have a password-retry limit by default right now.
16:27:42 <mitr> simo: I agree just changing sshd.conf is a bad move; OTOH I do think we could improve upon our defaults—but that would be a bigger project and the lack of anaconda developers participating in the Change discussion is not encouraging.
16:27:46 <sgallagh> I think I remembered that we decided a while ago not to do that, because it makes it easy to DoS root
16:28:05 <simo> sgallagh: and IMO a rate limiting feature would do all we need and let people free to choose how to log in
16:28:13 <nirik> mitr: they dont read #fedora-devel... ;)
16:28:25 <simo> sgallagh: you just have to wait a while and it unlocks
16:28:35 <sgallagh> simo: Not if they just keep hammering...
16:28:36 <nirik> not if they keep trying
16:28:37 <simo> sgallagh: and if you have ssh keys it wouldn't apply
16:28:46 <simo> you can keep trying too
16:28:52 <simo> evetually you'll be lucky :)
16:28:59 <simo> but that is hardening
16:29:08 <simo> I mean everything can be abused
16:29:11 <sgallagh> I think there's more value to that discussion than the no-root-login one though
16:29:15 <simo> you lock root and force a user
16:29:21 <simo> they find the user and they lock that one instead
16:29:26 <simo> and you are still locked out
16:29:35 <simo> if that is a concern you install ssh keys
16:29:50 <danofsatx|w> sorry, impromptu budgeet meeting popped up in my office
16:30:03 <sgallagh> proposal: The Server SIG feels that disabling root logins by default would be a significant reduction in usability. [Possible addon: and we will be re-enabling it in a per-product config if this Change is approved by FESCo]
16:30:06 <nirik> All passwords suck. We need to get to a point where keys are default. ;)
16:30:25 <sgallagh> nirik: Or better: GSSAPI
16:30:26 <nirik> note it's not disabling by default... it's just forcing key
16:30:31 <junland_2> Dual passwords?
16:30:33 <simo> nirik: security sucks, the computer should just *know* who am I when I ask gently :)
16:30:36 <mitr> sgallagh: Yes; active brute forcing prevention is a great way to reduce password requirements without reducing security, and we should have it by default (and then it is just a SMOP to have it)
16:30:57 <danofsatx|w> the point I wanted to bring up (I don't know if someone already did) was what sgallagh said - this is how Ubuntu does it.
16:30:59 <mitr> nirik: _What_ the change being discussed is, is not entirely clear from the discussion.
16:31:01 <simo> nirik: which is the same as blocking, because there is no mechanism to inject a key
16:31:16 <sgallagh> danofsatx|w: What is how Ubuntu does what?
16:31:25 <danofsatx|w> lock root and force a password.
16:31:34 <danofsatx|w> force a user and password, that is...
16:31:51 <simo> danofsatx|w: yeah and it sucks, but it is ok for a desktop
16:32:09 <simo> a *single user* desktop I should say
16:32:11 <nirik> mitr: it's setting PermitRootLogin with-password in our /etc/ssh/sshd_config... which isn't exactly 'disabling'
16:32:17 <sgallagh> danofsatx|w: I agree with simo: reasonable for a desktop expecting a single (or small number of) users.
16:32:19 <nirik> simo: with ks you can add keys.
16:32:23 <danofsatx|w> It does suck, but this is how they do it with their server, too
16:32:42 <simo> nirik: with ks I can also change sshd configuration ...
16:32:45 <nirik> sure
16:32:48 <mitr> sgallagh: On the proposal, "disabling root logins by default without other UI and tool changes" or something like that would wfm.  I think it is doable (though, security-wise, fairly pointless) but requires someone to actually start writing code.
16:32:56 <nirik> so the case you care about is non ks dvd install...
16:33:15 <simo> nirik: yes
16:33:22 <sgallagh> mitr: If it's not adding security, it's completely pointless
16:33:25 <adamw> nirik: it's without-password , isn't it? not with-password .
16:33:44 <mitr> sgallagh: It is adding a few bits to the brute force space… a few bits that bots are already exploring.
16:33:53 <nirik> adamw: sorry, yes, you are correct
16:34:21 <simo> if it were for me I would block all users password auth but root
16:34:28 <sgallagh> A more reasonable approach would be to just enforce a better root password (not more complex, just longer)
16:34:38 <simo> because the weak passwords are usually on user accounts, not root
16:34:38 <adamw> the change description does seem to have considered the server deployment use case, and uses its magical powers to order new code:
16:34:39 <adamw> " Anaconda installer OR maybe OpenSSH package needs to create initial set of authentication keys for 'root' user. "
16:34:59 <nirik> right and thats the wrong way to do it anyhow...
16:35:02 <adamw> sgallagh: that's fine, so long as you don't mind me quitting. ;)
16:35:06 <sgallagh> And how would the private key get to the user...?
16:35:29 <adamw> sgallagh: all my test installs have the root password 111111 and if i have to type 'correcthorse' 10,000 times a goddamn release cycle i'm off to buy that yak farm.
16:35:32 <sgallagh> adamw: "I cannot stand long passwords" there you go
16:35:58 <adamw> sgallagh: yes, now type it a dozen times *every fking day*
16:36:05 <adamw> anyhow.
16:36:08 <nirik> I guess the dvd case is something we definitely want to work out... so yeah, without anaconda changes we should not support this change at this time.
16:36:12 <mitr> Proposal: The server SIG feels that disabling root logins provides very minimal security improvement, and is not worth any reduction in usability; accepting this change would make sense only if all relevant UIs/tools were adapted to fully support system usage after this change.  [Excluding the case that "changing anything is an unfixable reduction in usability"]
16:36:15 <danofsatx|w> I have a 12 character password that is in the muscle memory of my fingers. not too bad.
16:36:32 <junland_2> Hate long passwords but you but you got to do that in order to secure the network....
16:36:52 <adamw> mitr: s/"disabling root logins"/"the proposed change"
16:37:04 <mitr> adamw: sure
16:37:13 <junland_2> Isnt there a way to have a two-form factor password like google does?
16:37:29 <sgallagh> junland_2: You would have to have a 2FA server running somewhere
16:37:30 <mitr> junland_2: In principle, yes. AFAIK we are not making it easy (authconfig and the like)
16:37:53 <sgallagh> junland_2: FreeIPA can do this nowadays, but setting it up in Anaconda is still a UI effort
16:37:54 <nirik> I think getting rid of passwords is a good thing, but this is just one (too easy) part...
16:38:11 <sgallagh> Anyway, +1 to mitr's proposal
16:38:18 <nirik> simo: so you do remove dvd installs with no console access?
16:38:34 <mitr> (How do you even _do_ a "dvd" install with no console access? :) )
16:38:35 <adamw> yeah, having looked over the change page i don't think it's been stunningly well thought through and i'm fundamentally sceptical of any change which invokes lots of work on the part of people who don't seem to have been brought in on the plan, so +1 the proposal
16:38:46 <junland_2> I see.
16:38:55 <nirik> mitr: this is what I am wondering.
16:39:05 <mitr> nirik: In other words, having someone from Server SIG take on the greater task of improving user authentication all around would be a great thing very much in our scope.  (I'm not volunteering in the near future.)
16:39:12 <adamw> nirik: clearly, it involves robots.
16:39:36 <sgallagh> adamw: Or possibly psychokinetics
16:39:49 <simo> nirik: last time I did it I actually had console access, doh :)
16:39:52 <nirik> mitr: sure, but for example we would need anaconda work to deal with keys somehow (import from usb? pull from site?) or the like
16:39:52 <adamw> and anything that involves robots installing fedora is undeniably awesome.
16:40:07 <nirik> indeed.
16:40:39 <mitr> nirik: It seems to me this would would really end up focusing on Kerberos domains, just because ssh is so application-specific, but that's just a hunch.
16:40:41 <danofsatx|w> finally, a use for my daughter's Pi
16:41:27 <sgallagh> Keys are a usability no-go for installer
16:41:31 <junland_2> USB key as a actuall "key"  but that would require physical access to the server to insert the drive in...
16:41:47 <nirik> so really the impact is that people would have to adjust sshd_config in kickstart where they didn't before.
16:41:59 <sgallagh> If you have the installer generate them, you can't get the private key off securely. If you have to provide one in interactive install, you would have to type it correctly.
16:42:10 <nirik> junland_2: sure, but you can get a monkey to do that.
16:42:17 * junland_2 trying to think outside the box.
16:42:20 <nirik> sgallagh: or a https url or etc
16:42:44 <sgallagh> nirik: That assumes network access, which may not be granted at install time
16:42:52 <sgallagh> Hard to say
16:42:56 <nirik> sure, there's lots of variables.
16:43:07 <mitr> sgallagh: If you don't have network access you don't need network-incoming authentication?
16:43:09 <nirik> or it could just be in the ks
16:43:13 <sgallagh> Anyway, can we get votes on mitr's proposal?
16:43:24 <junland_2> Dont we have a security SIG?
16:43:25 <sgallagh> If we all agree that this Change is not helpful, we can stop talking about it :)
16:43:34 <simo> nirik: if you want ssh-key you just have to go the ks way
16:43:39 <sgallagh> mitr: I said "at install time"
16:43:39 <nirik> I'm +0. I'm not decided on if the use cases matter so much key
16:43:51 <simo> in some cases you may be able to copy&paste it into a UI, but often not
16:43:56 <mitr> sgallagh: Would love to hear more, sometime later.
16:43:58 <tuanta_> it is a long but productive discussion
16:44:10 <tuanta_> +1 from me to mitr's proposal
16:44:11 <sgallagh> mitr: Such as a machine that has to be set up and secured before the IT guys let it access the internet.
16:44:13 <simo> +1
16:44:28 <simo> sgallagh: I've done image installs before too
16:44:39 <simo> then hadned over the VM image to run in prod/dev/etc...
16:44:51 <sgallagh> /me nods
16:45:00 <junland_2> Unplug server from network = Best security ever.
16:46:29 * mitr adds +1 for the record, I think we are at +5 (with s/"disabling root logins"/"the proposed change"/)
16:46:39 <danofsatx|w> +1
16:46:42 <sgallagh> junland_2: Also needs to be encased in cement and sunk to the bottom of the Marianas Trench, for proper physical security
16:47:08 <tuanta_> :)
16:47:17 <danofsatx|w> or launched to the sun.
16:47:20 <nirik> and even then the evil manatees living in the trench will just strip off the cement and login to it. ;)
16:47:27 <junland_2> Ha. That was network security. Not physical.
16:48:17 <tuanta_> sorry, I have to go now. I will see the logs for the rest of the meeting
16:48:44 <junland_2> tuanta_: Later!
16:49:10 <sgallagh> OK, let's call this agreed (I count +6, 1, -0)
16:49:54 <adamw> nirik: also, richard branson. you can't trust that guy.
16:50:02 <nirik> indeed
16:50:39 <sgallagh> What else is on the agenda? I *do* have a brief update on the DB Role
16:50:49 <simo> adamw: as an English man I disagree! ... oh wait .. I am not English, nvm
16:51:03 <simo> adamw: and you forgot the Sir ! :)
16:51:11 <junland_2> Nope nothing from me.
16:51:11 <simo> sgallagh: DB role is next
16:51:25 <sgallagh> ok
16:51:50 <sgallagh> /me is leaving the zodbot stuff to nirik today...
16:52:04 <nirik> sorry, got distracted.
16:52:10 <nirik> #topic Database role for f22
16:52:10 <sgallagh> s'ok
16:52:19 <sgallagh> nirik: You missed the #agreed
16:52:34 <sgallagh> (I don't think I am chaired, since I was logged out when the meeting started)
16:52:35 * junland_2 starts thinking of the song Database by Man With A Mission
16:52:41 <nirik> #undo
16:52:41 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xcbee750>
16:52:44 <nirik> everyone is a critic
16:53:41 <nirik> #agreed  The server SIG feels that the ssh config proposal provides very minimal security improvement, and is not worth any reduction in usability; accepting this change would make sense only if all relevant UIs/tools were adapted to fully support system usage after this change.  [Excluding the case that "changing anything is an unfixable reduction in usability"] (+6, +1, 0)
16:53:45 <nirik> #topic Database role for f22
16:54:06 <sgallagh> OK, so I was working on this yesterday and this morning.
16:54:34 <sgallagh> Quick reference: https://lists.fedoraproject.org/pipermail/server/2014-December/001694.html
16:54:57 <sgallagh> The short version is that, unless I hear strong arguments against it, I'm going to move ahead with 1) there.
16:55:22 <sgallagh> The longer version is that 1) and 3) are the only truly viable options, and 3) doesn't work on anything except x86_64.
16:55:47 <simo> 1 worksforme
16:55:59 <mitr> sgallagh: I’m not sure that we need to be tracking individual databases as rolekit instances but that’s mostly because I don’t know all that much about databases.
16:56:02 <sgallagh> I was also hoping to hear whether anyone knows of any decent web-based postgres management tools other than the PHP one.
16:56:19 <nirik> 1 works for me as well.
16:56:44 <sgallagh> mitr: The primary advantage will be usability. It'll be easier to set up owner users for each database.
16:57:03 <mitr> sgallagh: Ah, that's a good idea.
16:57:05 <sgallagh> I mean "easier" in an end-user sense
16:57:06 <mitr> ack to 1.
16:57:18 <sgallagh> Rather than a technical/coding sense
16:58:06 <junland_2> pgAdmin? Havent used it I think its web based
16:58:20 <sgallagh> I thought it was local X
16:58:43 <sgallagh> Yeah: http://pgadmin.org/images/screenshots/pgadmin3_linux.png
16:59:30 <sgallagh> So if that's the preferred approach, we may just want to make sure it plays nicely on Workstation and work with them
17:00:04 <junland_2> JackDB?
17:00:30 <sgallagh> That's another DB entirely...
17:00:41 <junland_2> Nevermind its nonfoss
17:01:05 <sgallagh> OK, so anyway, I'm actively working on developing this Role
17:01:26 <sgallagh> I'll happily take volunteers to assist with code-review and testing when it's closer to ready (hopefully early next week)
17:02:00 <nirik> cool. thanks sgallagh
17:02:05 <junland_2> Prolly cant do any code review but I am a willing test monkey!
17:02:14 <nirik> #info help wanted to code-review and test database role soon.
17:02:20 <sgallagh> /me gets out the music box
17:02:37 <nirik> anything else on db roleing? :)
17:03:06 <sgallagh> Agreed that we won't provide a management interface in Fedora Server 22?
17:03:33 <sgallagh> (potential addendum being that we'll try to work with pgadmin3 on Workstation)
17:03:34 <simo> +1
17:03:37 <nirik> sure
17:03:44 <junland_2> Guess so unless we can find something.
17:04:14 <mitr> sgallagh: +1 let's not block on that at least
17:04:37 <danofsatx|w> +1
17:04:57 <junland_2> agreed
17:05:34 <nirik> #agreed will not block on a management interface. Will look at working with pgadmin3 on workstation (+6,0,0)
17:05:38 <nirik> anything else on db?
17:05:45 <sgallagh> I think I'm good here
17:06:05 <nirik> cool.
17:06:09 <nirik> #topic Open Floor
17:06:12 <nirik> anything for open floor?
17:06:22 <junland_2> nope
17:06:33 <sgallagh> Let's take the discussion of Changes to the list.
17:07:02 <nirik> sounds good.
17:07:05 <nirik> Thanks everyone.
17:07:08 <nirik> #endmeeting