20:00:22 <sgallagh> #startmeeting Server Working Group Weekly Meeting (2017-03-28)
20:00:22 <zodbot> Meeting started Tue Mar 28 20:00:22 2017 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:22 <zodbot> The meeting name has been set to 'server_working_group_weekly_meeting_(2017-03-28)'
20:00:23 <sgallagh> #chair nirik sgallagh mhayden dperpeet smooge jds2001 vvaldez adamw mjwolf
20:00:23 <sgallagh> #topic roll call
20:00:23 <sgallagh> .hello sgallagh
20:00:23 <zodbot> Current chairs: adamw dperpeet jds2001 mhayden mjwolf nirik sgallagh smooge vvaldez
20:00:24 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
20:00:34 <nirik> morning
20:00:41 <mjwolf> .hello mjwolf
20:00:42 <zodbot> mjwolf: mjwolf 'Michael Wolf' <mjwolf@us.ibm.com>
20:00:45 * nirik has to leave in about 20min, but should be around until then.
20:00:51 <adamw> .hello adamwill
20:00:54 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
20:01:01 <adamw> why does this meeting always seem to happen when something is on fire?
20:01:04 <adamw> oh, i know. everything's always on fire.
20:01:08 <sgallagh> adamw: Beat me to it
20:01:14 <sgallagh> What is it this time?
20:01:45 <nirik> we live in a land of fire.
20:02:46 <sgallagh> Today's meeting is going to be somewhat informal, so if we don't hit quorum, I'm not overly concerned.
20:03:06 <sgallagh> #topic agenda
20:03:07 <sgallagh> #info Agenda Item: Brainstorming the NFS API
20:03:36 <sgallagh> I invited steved to join us today as we brainstorm our idealized API for configuring NFS via Ansible
20:04:22 <sgallagh> For those who do not know him, Steve Dickson is our resident expert on all things NFS
20:04:40 <sgallagh> steved: Wave to the camera?
20:04:42 * nirik waves
20:04:52 * steved waves :)
20:05:19 <sgallagh> #topic Brainstorming the NFS API
20:05:58 <sgallagh> I started a discussion with Terry Bowling (aka tmoney on IRC) last week regarding our desire for an NFS module in Ansible.
20:06:25 <sgallagh> (He is a product manager at Red Hat and heavily involved in the ongoing effort to produce new Ansible roles for server needs)
20:06:52 <sgallagh> He was going to try to get us a straw-man to critique before the meeting, but unfortunately he was unable to do so before he disappeared on a week's PTO.
20:07:25 <sgallagh> So I figured it would make sense for this group to offer up our first pass for his team to look at.
20:07:44 <jds2001> .hello jstanley
20:07:45 <zodbot> jds2001: jstanley 'Jon Stanley' <jonstanley@gmail.com>
20:07:50 <jds2001> sorry for my tardiness :/
20:08:24 <sgallagh> Some constraints we have to keep in mind: Ansible is declarative. We don't make changes, we assert a state.
20:08:48 <sgallagh> jds2001: Could you remind us with a #link where to find the initial user stories you put together?
20:09:08 <jds2001> that means i have to find it :)
20:09:11 <jds2001> give me a sec
20:09:33 <sgallagh> Ah, just found it
20:09:42 <sgallagh> #link https://docs.google.com/document/d/1jLyKsECdHdlKltmHGgf_-iOKj-hj4Qjbh5Zgm7a-eMc/edit?usp=sharing
20:10:21 <jds2001> ahh, just found it myself :)
20:11:32 <sgallagh> steved: My first query to you would be: what obvious cases did we miss in those stories?
20:11:47 * steved quickly reading it...
20:13:01 <steved> sgallagh: looks like a good start to me....
20:13:20 <sgallagh> OK
20:14:13 * steved wonders what a "CIDR block" block is
20:14:14 <sgallagh> These are somewhat high-level; they don't imply any of the implementation that may be necessary (including user/group synchronization and/or using kerberos to avoid that)
20:14:44 <sgallagh> jds2001: ^^
20:14:45 <steved> ack
20:15:07 <jds2001> steved: i.e. 10.1.2.0/24
20:15:23 <jds2001> to mean that the set of hosts 10.1.2.X (to vastly oversimplify)
20:15:31 <steved> ah got it...
20:15:42 <sgallagh> OK, so perhaps phrased differently: "It must be possible to restrict access by network segment and/or host identity" ?
20:16:04 <sgallagh> (with the latter implying but not specifying a trust mechanism to identify hosts)
20:16:07 <steved> yeah... that would have helped
20:16:34 <steved> also "Probably need to find a reasonable set of defaults" why not just used the current NFS defaults? Those are the ones most tested ;-)
20:17:08 <sgallagh> steved: That would qualify as "reasonable" in my mind :)
20:17:43 <jds2001> steved: i meant for the hosts being exported to
20:17:44 <sgallagh> Taking it back to a higher level, I think we should decide what we want out of the Ansible API directly.
20:17:48 <jds2001> steved: not anything else.
20:17:52 <sgallagh> There are a few open questions.
20:18:32 <jds2001> so i guess the question is what minimal data do you need to configure a NFS share?
20:18:36 <sgallagh> 1) Should there be a mechanism for creating (partitioning and formatting) space to be shared?
20:18:47 <jds2001> path and hosts (ro and rw) come to mind.
20:19:09 <jds2001> sgallagh: within cockpit, yes. Within this role, no.
20:19:41 <jds2001> however, I think that the UI should be task oriented.
20:19:42 <sgallagh> 2) Should the Ansible API specify access-control rules or should that be handled elsewhere. And if the latter, should it configure the system to find that elsewhere?
20:20:46 <sgallagh> steved: Actually. would you be willing to give us a five-minute primer on how NFS does access-control today in v3 and (kerberized) v4?
20:21:03 <steved> sgallagh: 1) do you mean creating local fs... yes... but I'm not sure it belongs in the NFS world
20:21:43 <sgallagh> steved: I think I agree with jds2001 that it would be nice to have in the Cockpit UI but not as part of the Ansible API.
20:22:26 * steved nods
20:23:19 <sgallagh> steved: It's worth noting that the doc we presented describes our Cockpit aspirations and we're now looking lower-level at implementing the NFS configuration via Ansible
20:23:47 <sgallagh> With an eye towards making an API that is stable across multiple releases of Fedora and RHEL (and probably other distros as well)
20:25:07 <steved> Yeah... I know about that work...
20:26:41 <sgallagh> So, let's assume for the moment that the Ansible API is only going to work with the filesystem as it stands
20:26:55 <sgallagh> Any objection? (I'll #info that if not)
20:27:53 <sgallagh> #info The Ansible API for NFS will not be expected to create any of its own mount points. The Cockpit UI may do so using other mechanisms.
20:28:28 <steved> It keeps things simpler...
20:28:48 <sgallagh> OK, so the other question I raised was about access-control. There are a couple ways that this could be presented to the user.
20:29:35 <sgallagh> steved: Would you mind describing what mechanisms people use today to control access to shares at both the share level and the file level?
20:30:50 <steved> From a share level kerberos is used quite a bit
20:31:33 <steved> From file level there there are the chmod bits as well as nfsv4 acls (which are thing kinda work?)
20:32:28 <sgallagh> steved: When you say "kerberos is used" on the share-level, how does that work?
20:33:07 <sgallagh> Does that just mean "you can access this share as long as you have any valid TGT from a realm" or is it more granular?
20:33:22 <steved> the exports options (sec=sys:krb5:krb5i:krb5p) are set
20:34:10 <steved> TGT from a realm
20:34:17 <sgallagh> ok
20:34:49 <sgallagh> So then once connected, it's FS-level permissions that decide whether you can read/write/execute any individual content.
20:35:30 <sgallagh> steved: I assume there are other access-control mechanisms, since not everyone has deployed Kerberos.
20:35:44 <sgallagh> For the sake of this discussion, could you remind us what they are?
20:35:47 <steved> sgallagh: read/write can also be set in the exports
20:36:04 <sgallagh> steved: Right, globally for the entire share. Correct?
20:36:11 <steved> right
20:37:31 <jds2001> so perhaps im confused, I'll admit to never having used kerberized NFS.
20:37:36 <sgallagh> steved: The exports file allows host-based restrictions, though I'll admit I've only really used them personally as individual machines.
20:37:41 <jds2001> so what happens at boot? when you have no TGT?
20:38:05 <jds2001> do you get one via the host principal?
20:38:22 <sgallagh> jds2001: I assume you mean an NFS share that is mounted by default?
20:38:29 <jds2001> sgallagh: yeah
20:38:33 <sgallagh> You would need to kinit with a host keytab and use that account to mount the drive.
20:39:29 <sgallagh> Though I'm not sure what that would mean for permissions.
20:39:55 <sgallagh> I seem to recall that it's possible to mount as one user and then allow other users to access it with their own credentials if they have a TGT, but I forget the mechanics
20:40:06 <sgallagh> steved: Am I remembering correctly?
20:40:34 <steved> Yes...
20:42:02 <sgallagh> steved: Is it a better practice to mount such default shares automatically at boot or via autofs?
20:42:31 <sgallagh> (And as we develop the Ansible API, should we provide a means to do it both ways?)
20:43:38 <steved> Good question... I don't think it really matters... with autofs there just move config-ing needed
20:43:44 <steved> s/move/more
20:44:15 <sgallagh> steved: I was wondering if the idle disconnection is a better practice in general
20:44:34 <sgallagh> And whether that would make life easier on clients if the host rebooted, etc.
20:45:02 <steved> It is always a good thing to use less resources... IMHO....
20:45:13 <steved> Let things can go wrong ;-)
20:46:25 <sgallagh> OK, well that's on the client side, so perhaps we should move on from here.
20:46:53 <sgallagh> steved: I asked before but didn't get an answer: what can NFS do with regards to host-based access control.
20:46:56 <steved> sgallagh: so this is a server only thing?
20:47:18 <sgallagh> steved: That's the part we're discussing right now, at least: configuring the NFS server
20:47:30 <steved> host-based access control??
20:47:31 <sgallagh> It's useful to know how the clients will interact with it, of course.
20:47:57 <sgallagh> steved: in /etc/exports, you can restrict which hosts have access by several patterns, right?
20:48:01 <sgallagh> What are they?
20:48:39 <steved> yes you can restrict hosts access to exports in /etc/export
20:49:22 <sgallagh> steved: And that is done by: name? IP address range? Submask?
20:49:26 <sgallagh> (all of the above?)
20:49:40 <steved> as well as network access (aka 10.1.2.0/8)
20:49:59 <steved> all of the above :-)
20:50:28 <sgallagh> steved: How does name-based restriction work? Is it a reverse DNS lookup or does it just trust the client to be reporting its name accurately?
20:51:46 <steved> sgallagh: I seem to remember there is a reverse DNS lookup done...
20:52:12 <sgallagh> OK, which then carries an implied requirement that DNS be properly configured :)
20:52:42 <steved> yup!
20:52:57 <sgallagh> steved: OK, expert opinion: Are there any parts of the NFS configuration that are so unpleasant that you would want them *not* to be exposed in an API?
20:53:18 * steved thinks...
20:54:23 <sgallagh> (or parts that people consistently get wrong and that we should consider wrapping in a use-case based directive instead of exposing directly)
20:54:53 <steved> whell there is /etc/idmapd.conf, /etc/exports, and very brand new on /etc/nfs.conf that controls all the server daemons...
20:56:14 <sgallagh> steved: Ah, we didn't talk at all about ID-mapping (beyond what is done automagically by Kerberized NFS)
20:56:20 <steved> I would think we should move to only having to change /etc/nfs.conf and /etc/exports (basically roll idmap.conf into nfs.conf)
20:57:20 <steved> sgallagh: id mapping has gotten better for non kerberized mounts...
20:57:51 <sgallagh> steved: Well, we'll definitely wrap the functionality. The module itself should be designed to write to whichever config file makes the most sense for the appropriate platform.
20:57:55 <steved> sgallagh: most server now pass "3606" string instead of a "steved@redhat.com" string that needs to be translated
20:58:16 <sgallagh> (Meaning we should be able to point the same ansible playbook at a RHEL 6 machine and a Fedora 27 machine and expect it to work)
20:59:00 <sgallagh> steved: Does that mean that the client has to have ID's synchronized with the server, though?
20:59:03 <steved> hmm... well f27 will not be a problem but RHEL 6 would if we center around /etc/nfs.conf
20:59:16 <sgallagh> (e.g. both enrolled with the same domain controller)
20:59:34 <sgallagh> steved: I think you misunderstood. We're not going to expose directly which config file it's using.
20:59:45 <steved> In theory no... In reality probably ;-)
21:00:18 <steved> but that is an NFS layer thing that should not be worried about from the API... IMHO
21:00:45 <sgallagh> steved: Probably not from the API, no. But the module probably needs to understand it
21:01:07 <steved> sgallagh: maybe or maybe not... only time would telll
21:01:31 <sgallagh> steved: That's not a helpful statement :-/
21:02:14 <steved> I'm thinking have the API worry about syncing ids would be a bit difficult and not needed if krb5 is being used.
21:02:47 <sgallagh> I guess I'm not sure how idmap.conf (or the nfs.conf variant) would need to be configured and how much we would have to present to the user vs. implement under the hood
21:03:07 <steved> The same code is used to parse both of them...
21:03:35 <sgallagh> steved: Yes, and our plan for Cockpit in the first pass involves only allowing the use of krb5 setups in a domain configuration (to simplify it for us).
21:03:45 <sgallagh> But the Ansible API *will* need to support other configurations.
21:03:51 <steved> there is even some talk about moving that parsing code out to its on library for other things to use
21:04:19 <sgallagh> steved: I'm not concerned about the file format. I'm concerned about how much of what you configure there needs to be exposed in the API
21:04:35 <sgallagh> The file format and location is an implementation detail under the API
21:04:41 <steved> sgallagh: "only allowing the use of krb5 setups" wow that is a high bar IMHO
21:05:09 <sgallagh> steved: Sorry, that was more strongly phrased than necessary.
21:05:40 <sgallagh> In our initial release, we've chosen to go that route because it will require the least mucking about with synchronization, since you can trust that the domain enrollment handled that for you.
21:05:51 <steved> sgallagh: "how much of what you configure there needs to be expose" this is a good question... IDK
21:05:52 <sgallagh> We *will* be supporting other approaches in Cockpit as time goes on
21:06:32 <sgallagh> Think of it as "Minimum Viable Product" vs. "Complete NFS Solution"
21:06:56 <sgallagh> Get one thing working from top to bottom, then work on the harder cases.
21:06:57 <steved> sgallagh: I guess what you are asking is should the API be man page compatible
21:07:12 <sgallagh> steved: IMHO it doesn't need to be that.
21:07:35 <sgallagh> If the API doesn't do some specific trick that a user wants, they can always fall back to pushing config files around directly.
21:07:42 <sgallagh> The API should solve problems.
21:07:52 <sgallagh> All of the most common problems, I should say
21:08:35 <steved> sgallagh: and the trick is to define "common problems" ;-)
21:09:05 <sgallagh> Problem 1: defining problems is hard
21:09:49 <sgallagh> steved: Right, but my point is that we should focus on solving the 60% case first, then the 80% case next, then the 90% case and then retire and leave the rest to the next generation :-)
21:10:10 * steved completely agrees with that!
21:10:35 <sgallagh> OK, we're over time here, but I'll open the floor for any other comments.
21:10:58 <sgallagh> After that, I'll ask for at least one volunteer to help me draft a straw-man API proposal this week.
21:12:01 * jds2001 has little time :(
21:12:20 <jds2001> $DAYJOB deadlines.....
21:12:26 <steved> sgallagh: you can run it by me... ;-)
21:12:51 <sgallagh> steved: I certainly plan to, and thank you.
21:13:20 * steved agrees with jds2001
21:13:21 <sgallagh> steved: Are you subscribed to server@lists.fp.o ? I'll probably write up a draft and send it there.
21:14:31 <steved> sgallagh: yes but please ping me when you send it out...
21:14:45 <sgallagh> WIll do, thank you
21:15:36 <sgallagh> OK, thank you all for coming.
21:15:38 <sgallagh> #endmeeting