15:00:33 <sgallagh> #startmeeting Server Technical Specification Working Session (2014-02-28)
15:00:33 <zodbot> Meeting started Fri Feb 28 15:00:33 2014 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:43 <sgallagh> #chair sgallagh mizmo nirik davidstrauss Evolution adamw simo tuanta mitr
15:00:43 <zodbot> Current chairs: Evolution adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta
15:00:48 <sgallagh> #topic roll call
15:01:16 <sgallagh> .hellomynameis sgallagh
15:01:23 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:04:39 <simo> hola amigos
15:04:52 <sgallagh> Greetings, simo
15:05:05 <sgallagh> So far, it's you and I.
15:05:20 <simo> we can wait some
15:05:30 <simo> it was not clear to me you called for another meeting today tbh, I saw it by accident
15:05:55 <sgallagh> When I sent out the message to the WG members, I noted that we'd use this slot if yesterday's ran out of time
15:06:24 <sgallagh> Hopefully, others saw that :-(
15:11:18 <mitr> Hello
15:11:59 <sgallagh> Hello
15:12:03 <sgallagh> That makes three :)
15:12:12 <sgallagh> Need a couple more folks for quorum
15:15:00 * nirik is kinda sorta barely here.
15:15:50 * sgallagh nods
15:15:53 <sgallagh> I'm also co-attending the Base WG meeting concurrently
15:15:54 <sgallagh> But I can juggle that well enough
15:28:43 <sgallagh> Ok, we should really try to have at least some of this conversation now and get votes on the list later.
15:29:17 <sgallagh> My suggestion was that we should go through the items on the rough draft I sent out and discuss any that seem contentious.
15:29:51 <simo> go
15:30:12 <mitr> Meta-comment: This doesn't specify anything for roles, and we can't get it done.
15:30:15 <sgallagh> Alright, as I wrote most of it, I defer to you guys to tell me which sections need to be adjusted.
15:30:31 <sgallagh> mitr: "and we can't get it done"?
15:30:37 <mitr> sgallagh: .. by March 3
15:30:44 <simo> mitr: what are you referring to ?
15:31:38 <sgallagh> You guys are chaired, set the topic for any section you want to discuss
15:32:40 <mitr> #topic Logging
15:33:04 <mitr> 1) The 'developer use case" reference doesn't apply here, and "collect" vs."send" the logs.  Perhaps "Server will support sending logs to a remote log server (which we want to eventually provide a s a role)."?
15:33:48 <simo> what section ?
15:33:53 <mitr> 2) I don't know what to do about all the daemons that manage their own log files.  Do we want to commit to forward that to the syslog stream?
15:34:02 <mitr> simo: see /topic, in https://fedoraproject.org/wiki/Server/Technical_Specification
15:34:05 <nirik> +1cccccccbjhrgtrkrrffdlidcnigiujbndjcutbrluhnl
15:34:08 <nirik> 820134
15:34:11 <nirik> nice. ;(
15:34:15 <nirik> sorry about that.
15:34:31 * nirik is +1 to remote logging.
15:35:10 <sgallagh> That's quite a password ;-)
15:35:21 <simo> nirik: your OTP PIN needs changing I guess :)
15:35:30 <mitr> (Should I be bringing up /var/log text logs?  That's probably a flamewar we don't need, rather focusing on remote logging.  So I'm not bringing that up :) )
15:36:07 <nirik> simo: just got a yubikey nano, it's apparently easy to brush up against. ;) Luckily that is just otp, not the pin. ;)
15:36:16 <simo> mitr: we should certainly enable (by default ?) syslog logging for those projects that suport both file or syslog logging
15:36:19 <sgallagh> I think we should commit to scraping the logs of any service that's part of the base or a Role
15:36:31 <nirik> yeah.
15:36:51 <simo> sgallagh: isn't that provided by journald if you can at least tell the daemon to log to stderror instead of files ?
15:37:04 <simo> sgallagh: but something like apache ?
15:37:06 <sgallagh> Yes, assuming the daemon can
15:37:14 <sgallagh> Right, Apache might be trickier
15:37:29 <simo> there is also a problem of verbosity, this area is hard
15:37:33 <mitr> simo: That still means packaging/repackaging work.
15:37:49 <simo> mitr: I know, which is why I am thinking we should not have strong wording
15:37:57 <simo> but just express an intent
15:38:05 <simo> to be done as much as feasible in the short term
15:38:25 <sgallagh> Well, that's the point of the opening paragraph
15:38:53 <sgallagh> "Some of the desired characteristics may not be entirely achievable in the first version of the Server product, and will be approximated."
15:39:03 <mitr> (FWIW rsyslog has "imfile" to watch a log with inotify and import it into the syslog stream ... but that means depending on rsyslog, and journal won't be complete log storage unless we support running  _two_ instances of rsyslog, one to do imfile -> journal, another to do journal -> socket)
15:39:22 <mitr> ... so native logging to syslog would be much simpler.
15:39:35 <nirik> I think it makes sense to have journal for local logging + rsyslog for remote.
15:40:12 <sgallagh> journald doesn't have forwarding to remote syslog yet?
15:40:18 <sgallagh> I thought that was on the 2013 plan.
15:40:45 <nirik> it doesn't...
15:40:52 <nirik> but you can run a local rsyslog to do that.
15:41:08 <simo> sgallagh: the way toi do it is to have a local rsyslog
15:41:23 <simo> in that case you have local -> journal -> rsyslog -> remote
15:41:43 <simo> mitr: what is the problem of requiring rsyslog for remote logging ?
15:42:06 <sgallagh> Mostly proliferation of daemons, I'd guess
15:42:17 <mitr> simo: there's no problem with that.  There's somewhat of a problem with using imfile to get non-syslog files into the log stream (you need two rsyslogs - doable but ugly)
15:42:34 <simo> mitr: why 2 rsyslogs ?
15:42:54 <mitr> simo: ... or giving up on "local storage backend is journal"
15:43:34 <sgallagh> mitr: Or deciding that you can only get those logs if you use central forwarding
15:43:49 <sgallagh> simo: Because one rsyslog manages the inotifies and forwards to journald
15:43:59 <sgallagh> journald then forwards to the other rsylog to send to the remote server
15:44:04 <sgallagh> mitr: Accurate?
15:44:24 <mitr> sgallagh: yes.
15:44:27 <simo> sgallagh: why to we care for journald when we are fdoing remote logging ?
15:44:28 <nirik> are there other cases aside from httpd that we would need to worry about?
15:44:48 <mitr> So, proposal - part 1: goals
15:44:50 <simo> nirik samba ?
15:44:50 <mitr> Server will by default store log files locally, and to the maximum extent possible support sending full log data to an external server.  For writing to logs, we recommend the syslog or ournal APIs.  An API for reading the logs will be provided through OpenLMI.
15:44:51 <sgallagh> simo: structured logging is still nice
15:45:14 <simo> sgallagh: it still lost when you send it remotely after you grepped it from files ?
15:45:20 <mitr> nirik: samba at least; individual log files are fairly widespread
15:45:28 <nirik> journal has a number of advantages, but still has issues too. ;)
15:45:34 <simo> I mean if you are aggregating remotely through syslog it doesn't really matter if the stuff is available locally and structured
15:46:53 <sgallagh> Well, you still might want to grab the binary journal and use native tools on it
15:47:04 <sgallagh> But I can't decide how common I think that will be
15:47:17 <sgallagh> Certainly less if we don't support the journal locally
15:47:27 <mitr> Proposal part 2 - implementation: We will use rsyslog for forwarding data to a central server; Roles are expected to configure their daemons or rsyslog so that Role-generated data is included in the rsyslog stream.  At this point we don't commit to having the full data available locally in the jourrnal storage database, but it will be locally available within /var/log in convenient format.
15:47:55 <mitr> ^^^ is basically saying "we don't know"
15:48:55 <mitr> sgallagh: (systemctl status) is certainly convenient. OTOH whether it should include the last N transactions for httpd is... rather unclear :)
15:48:56 <sgallagh> mitr: Let me try to restate this so I'm sure I understand
15:49:59 <sgallagh> mitr: 1) any service that CAN send to the journal, must.
15:50:29 <sgallagh> 2) The journal will forward to rsyslog for remote transmission
15:50:29 <mitr> Hm... OpenLMI actually can read only journal/syslog, not all files in /var/log, or can it?
15:50:46 <mitr> sgallagh: 1) I didn't say that, but probably should have; that's certainly the simplest option.
15:50:46 <sgallagh> 3) Anything that cannot send to the journal will go directly to rsylog and remote
15:50:55 <nirik> I mean we could tweak httpd and samba and whatever to send to journal... but I don't know how much work that will be.
15:51:00 <mitr> 2) yes; 3) will go both to some local files, and to rsyslog and remote
15:51:02 <sgallagh> and is not expected to be shoehorned into the journal
15:51:08 <mitr> yes
15:51:40 <simo> note that I do not think samba logs should ever sent anywhere, they are more debug logs than anything useful :-)
15:51:48 <simo> but whatever :)
15:52:01 <nirik> yeah, thats another case too... some logs should just not be created by default. ;)
15:54:50 <nirik> but I think a goal of using journal, but using rsyslog for now where needed makes sense to me.
15:55:43 <sgallagh> +1
15:55:47 <mitr> Proposal v2:
15:55:48 <mitr> "Server will by default store log files locally, and to the maximum extent possible support sending full log data to an external server.  For writing to logs, we recommend the syslog or journal APIs, rather than managing application-specific log files.  An API for reading the logs will be provided through OpenLMI.
15:55:51 <mitr> We will use rsyslog for forwarding data to a central server.  Programs using the recommended APIs will have their logs locally stored in the journal database, and automatically forwarded; the other programs should include appropriate configuration for rsyslog so that their log output is included in the rsyslog-forwarded data stream."
15:56:19 <sgallagh> mitr: +1 to that phrasing
15:56:30 <nirik> sure, +1
15:57:03 * sgallagh notes we don't have enough members for approval
15:57:16 <sgallagh> I'll update the doc with this phrasing and leave the unapproved tag there
15:57:23 <sgallagh> simo: OK with you?
15:57:40 <mitr> How about "High-volume transaction logs may be considered for exceptional treatment, logging in them in an low-overhead way locally only"?
15:58:02 <mitr> I have _really_ no idea what is usually done for e.g. the httpd request logs.
15:58:25 <mitr> Alternatively, let's move on?
15:58:40 <sgallagh> mitr: In many cases, people actually just stick /var/log/httpd on an NFS drive :-P
15:58:51 <mitr> We don't need to get it perfect today, feel free to shut me up
15:59:29 <simo> sgallagh: one sec sorry
16:00:05 <simo> sgallagh: +1 with me too
16:00:31 <sgallagh> #info "Server will by default store log files locally, and to the maximum extent possible support sending full log data to an external server.  For writing to logs, we recommend the syslog or journal APIs, rather than managing application-specific log files.  An API for reading the logs will be provided through OpenLMI. We will use rsyslog for forwarding data to a central server.  Programs using the recommended APIs will have th
16:00:31 <sgallagh> eir logs locally stored in the journal database, and automatically forwarded; the other programs should include appropriate configuration for rsyslog so that their log output is included in the rsyslog-forwarded data stream."
16:00:53 <sgallagh> #info Doc will be updated but left unapproved until voting
16:00:53 <simo> mitr: for http logs in many case people do log aggregation/analysis either locally or remotely and then throw away the full stuff after X time
16:02:23 <sgallagh> #topic System Installer
16:02:40 <mitr> (Next sections I have comments on: Firewall, low-prio on Problem reporting , propose to drop Session tracking, low-prio on Account Handling, low-prio on all the GUI stuff)
16:02:53 <sgallagh> #info Updated this section to include note that kickstart (as implemented by pyKickstart and Anaconda) is the supported unattended installation mechanism
16:03:01 <sgallagh> That was just for informational purposes.
16:03:08 <sgallagh> #topic Firewall
16:03:53 <mitr> (I'm undecided on the default confinguration of the firewall.)
16:04:03 <sgallagh> mitr: In what way?
16:04:31 <mitr> I feel fairly strongly that roles should not be manipulating the firewall "in its firewall function";  i.e. libvirt might be manipulating bridges and forwarding for VMs, but nothing should be enabling/disabling itself.
16:04:35 <nirik> allow ssh, deny everything else until the role config says some service is ready to serve, then open it's needs.
16:05:02 <nirik> well, the role shouldn't, but the configuration tool (cockpit) should based on the roles needs?
16:05:04 <mitr> sgallagh: Both "allow anything that runs" and "deny everything that runs" by default make some sense to me.
16:05:14 <sgallagh> mitr: I think the Role API can do this, not the Role itself.
16:05:20 <sgallagh> If that's at all clear...
16:05:32 * nirik is with sgallagh there...
16:05:55 <mitr> sgallagh: It isn't.  I think Server should provide an API for system management tools (cockpit, human admins, scripts, whatever) to manipulate firewalls, but we shouldn't be expecting Roles to do that.
16:05:55 <sgallagh> I think the role should be able to say "I need these ports open, may I?" and require admin permission
16:06:19 <mitr> Roles may say what they need to have open, and mgmt tools may use that information.
16:06:22 <nirik> sgallagh: yeah, and after they are otherwise configured..
16:06:32 <mitr> "May I" would only make sense in an interactive setup context.
16:06:48 <nirik> ie, "You have finished configuring your freeipa server, would you like to open the firewall and start all the services?"
16:06:52 <sgallagh> mitr: Role setup *is* interactive.
16:06:59 <sgallagh> Role *installation* isn't.
16:07:14 <mitr> sgallagh: Great.
16:07:50 <sgallagh> mitr: Does that make more sense to you?
16:08:12 <sgallagh> And if so, would you like to suggest a phrasing that would have been less confusing?
16:08:42 * sgallagh tries
16:09:50 <mitr> Proposal: "Server roles will describe what port access they need.  The configuration process of a role may prompt the user to adjust the firewall accordingly.  Roles, while running, must not manipulate the firewall to enable/disable access to themselves (but may manipulate the firewall if it is their core function, e.g. managing network connectivity for VMs or containers)."
16:09:56 <sgallagh> Server Roles must present an API listing the set of firewall behaviors they declare are necessary for proper operation, but does not set these rules implicitly. Administrator action is necessary.
16:10:12 <nirik> +1
16:10:15 <sgallagh> mitr: +1
16:10:26 <mitr> sgallagh: +1 to yours.as well :)
16:10:50 <sgallagh> mitr: I think yours covers mine and phrases it better.
16:12:10 <sgallagh> Ok, I'll update the doc with mitr's phrasing
16:12:50 <sgallagh> I'll leave in the line about OpenLMI in the future, though
16:13:17 <sgallagh> Do we want to say the default operation will be ESTABLISHED+SSH only?
16:13:18 <mitr> sgallagh: And leave the first paragraph about default configuration as well, please.
16:13:21 <sgallagh> Prior to configuration?
16:13:34 <mitr> Or let's talk about that :)
16:14:30 <sgallagh> "The default configuration of the firewall on Fedora Server will be to allow inbound access only to SSH."
16:14:36 <sgallagh> Proposal: "The default configuration of the firewall on Fedora Server will be to allow inbound access only to SSH."
16:14:50 <mitr> ... and cockpit, if that ends up running by default?
16:14:53 <nirik> well, and all outgoing?
16:15:06 <mitr> Anyway, "0" I really don't know.
16:15:37 <mitr> Cloud will be running with firewall disabled, won't it?
16:15:48 <sgallagh> mitr: Cockpit operates via SSH tunnel :)
16:16:25 <mitr> sgallagh: if you have another Server running
16:16:36 <sgallagh> mitr: Sorry, you're right. We still need the web port, though
16:16:38 <simo> sgallagh: sorry to be jhonny come late
16:16:49 <simo> I do not get why role install shouldn't open firewall ports ?
16:16:49 <sgallagh> hmm?
16:16:51 <mitr> This would impact the "first Linux server for testing by a newbie" scenario
16:17:09 <sgallagh> simo: Risk for multi-homed servers
16:17:22 <sgallagh> Only safe thing to do is ask which interfaces we're allowed to open
16:18:00 <mitr> simo: What is the firewall protecting against?  If every running process opens its own ports, the firewall is essentially equivalent to kernel replying RST to an incoming connection on an unused port.
16:18:05 <simo> so in interactive config you have to make complex determinations of what interfaces should be open and ask for each of them ?
16:18:05 <sgallagh> mitr: A newbie would hit google and see 'systemctl stop firewalld' and get on with his life...
16:18:30 <simo> mitr: install/config != process ask for itself
16:18:38 <mitr> sgallagh:"find another computer; install putty; log in; then..."
16:18:57 <sgallagh> mitr: I don't follow you, sorry
16:19:00 <mitr> simo: Sorry, the proposed wording does allow interactive dialogs on role _installation_.
16:19:12 <simo> yes but it seem complex to me
16:19:22 <simo> the qustion should just be: can i poke the firewall ? yes/no
16:19:32 <mitr> simo: I'm actually leaning towards the orignal proposal, i.e. firewall is open by default.
16:19:35 <simo> if you have multihomed and say 'yes' you get what you asked for
16:19:42 <sgallagh> I'd like to leave the UX decision to someone else
16:19:54 <sgallagh> I'd rather we just agree that *technically* we want a decision to be made
16:19:59 <sgallagh> As opposed to being made *for* you
16:20:00 <simo> mitr: I am completely contrary to running a firewall that firewalls nothing :)
16:20:02 <nirik> if you say no tho, it would be nice to know what you need to manually add to your custom fw
16:20:03 <mitr> simo: I think such as yes/no is what the proposed wording allows.
16:20:20 <simo> nirik: right
16:20:22 <mitr> simo: How about running a firewall API that also may be a firewall? :)
16:20:35 <simo> sgallagh: the *only* reason freeipa does not open its ports, it is because it is too hard to code up with iptable
16:20:45 <mitr> nirik: The proposed wording is already asking for that.
16:20:49 <simo> sgallagh: once we can give firewalld for granted we will just proceed and open the ports for you
16:20:53 <sgallagh> simo: It's trivial with firewalld :)
16:21:01 <simo> sgallagh: I do not understand what's the point of asking
16:21:19 <nirik> the service may not yet be configured?
16:21:31 <simo> sgallagh: should we also ask at the end of config/install: "congrats now that you nstalled do you *really* want to run it?"
16:22:01 <simo> nirik: read configure-script-run
16:23:31 <simo> nirik: when you run ipa-server-install you have it ready and runnig
16:23:35 <simo> what is the point to even ask if you want to poke the firewall ?
16:23:37 <mitr> simo: ipa is kind of special in that you always want it to be fully accessible
16:23:38 <simo> *of course* I want to poke it, I installed *and* configured a network role!
16:23:39 <sgallagh> Not necessarily
16:23:39 <nirik> you may also want to start things and test locally before opening firewall?
16:23:42 <mitr> simo: Think httpd, where it might make sense to open it for a subnet, do some penetration testing, and then open to the whole world.  (... might e an unusual case)
16:23:43 <simo> mitr: ok but then we need to acknowledge that roles *themselves* determine if they need to ask
16:23:43 <simo> not a general rule
16:23:46 <sgallagh> I disagree
16:23:46 <simo> nirik: seriously ? no
16:23:48 <simo> sgallagh: ok you get -1
16:23:48 <sgallagh> They should always ask, and we can special-case some of them to say yes
16:23:48 <simo> let's move on
16:24:46 <sgallagh> simo: How about this:
16:24:48 <sgallagh> If there is more than one public interface on the system (handwavy bonding), then we ask
16:24:48 <mitr> simo: I think what would make sense is either 1) firewall off by default, roles don't touch it, admins that want to do something different enable firewall first, then set up roles, or 2) firewall on by default, and then we need a reasonable UI that makes it easy to allow the firewall
16:24:49 <sgallagh> If there's only one public interface, assume it's okay to open
16:25:48 <adamw> morning
16:25:49 <sgallagh> adamw: Hello!
16:25:51 <sgallagh> (We're at quorum!)
16:25:57 <simo> sgallagh: I do not think single/multiple interface matters tbh
16:25:58 <mitr> sgallagh: A good heuristic for making the right decision,  might be confusing to the admin ("but I tested this and the firewall was on!")
16:25:58 <simo> some service you must always ask
16:25:59 <simo> database for example
16:26:00 <simo> because it could be fully local
16:26:22 <simo> some others it makes little sense
16:26:22 <simo> domain controller
16:26:40 <simo> and defaulting to opening on install makes sense
16:26:40 <simo> the admin can always close it down
16:26:48 <sgallagh> s/install/setup/ but I suppose I can see that argument
16:26:54 <mitr> Re-proposal: by default, ssh open, others closed
16:26:55 <simo> so I propose each single role determines the policy
16:26:55 <mitr> (Rationale; we have little time, and this is the F20 default; we don't strictly need to decide on a better design today, it doesn't affect Role implementation in any case)
16:27:02 <sgallagh> We certainly want to make sure we have an interface that displays clearly what's open
16:27:19 <simo> sgallagh: yes sorry by install here I mean exactly "role setup"
16:27:23 <mitr> simo: Strongly -1 on roles deciding for themselves
16:27:23 <simo> certainly *not* rpm install
16:27:36 <sgallagh> simo: Would you mind starting a discussion thread on this?
16:27:48 <simo> mitr: it totally affect role implementation or I wouldn;t care
16:27:48 <sgallagh> I think we clearly need to hash this out with a wider audience
16:28:25 <mitr> simo: We ask the role to list ports that it needs; whether they would be open by default or open by interactive UI or closed by default is something that only the role setup code needs to know.
16:28:33 <simo> mitr: I think you are still confused about role doing itself means program opens firewall at startup, which is not what I am proposing
16:28:54 <simo> mitr: we are talking about role setup here
16:29:08 <mitr> simo: No, even at role setup time, the role shouldn't have a say.  The admin should know what to expect when installing a role they haven't seen before.
16:29:15 <simo> and you are telling me exactly what I proposed after you said -1 :-)
16:29:25 <simo> mitr: ah no then we do not agree
16:29:36 <simo> we are here to make things uable
16:29:39 <simo> *usable
16:29:40 <adamw> sgallagh: i think we're not technically at quorum until i have a coffee
16:29:44 <adamw> what are we arguing about?
16:29:47 <simo> usability means *things work* after I runs etup
16:29:55 <sgallagh> adamw: firewall behavior wrt roles
16:30:12 * sgallagh suggests that adamw may want a whole pot for this
16:31:03 <mitr> simo: I _would_ see a good case for disabling the firewall by default at all; I can well live with having the firewall enabled, and having a "yes I'm OK with that" step during role setup.  Having a silent role install and not knowing whether the service is accessible by the time setup finishes doesn't work for me.
16:31:18 <mitr> Unpredictability is not usable.
16:31:39 <sgallagh> mitr: and simo's argument is that if you install/configure a role, it should ALWAYS be available
16:31:46 <sgallagh> Punching holes in the firewall where necessary
16:32:02 <mitr> sgallagh: That's just a high-overhead way to disable a firewall
16:32:48 <sgallagh> eh... the default firewall config in F20 is DROP, whereas if the firewall is up, doesn't it become REJECT?
16:33:00 <sgallagh> err, "firewall is down"
16:33:35 <sgallagh> REJECT at least tells you there's a machine at that address to start nmapping
16:33:45 <mitr> I don't think drop/reject matters much
16:33:58 <mitr> You can always map port 22
16:34:10 <sgallagh> fair
16:35:09 <sgallagh> Let's assume for the moment that (regardless of value) there is a sizeable chunk of the population that would balk at the firewall not being enabled by default.
16:35:21 <sgallagh> (Because this is likely true)
16:35:46 <adamw> are we agreed that, at least, roles should be accessible once configured?
16:35:56 <adamw> (without manual firewall configuration)
16:36:13 <nirik> what does accessable mean there?
16:36:13 <mitr> adamw: I don't have a strong opinion
16:36:35 <nirik> remote? local? both?
16:36:48 <adamw> nirik: well, in this context, "not blocked by firewall"...
16:36:50 <sgallagh> adamw: There are problematic roles
16:36:55 <mitr> sgallagh: Right, with that assumption, auto-punching holes is a practical thing to do - stomach-turning but practical
16:36:58 <simo> sgallagh: I think DROP is a stupid configuration we shouldn't use it by default
16:37:02 <sgallagh> e.g. A Database Server may only be needed locally
16:37:08 <adamw> true.
16:37:13 <nirik> yeah.
16:37:13 <sgallagh> A File Server may only want to be available on some interfaces
16:37:47 <simo> sgallagh: that's why each role need to be allow to choose how to behave wrt firewall punching IMO
16:37:49 <sgallagh> So the way I see it, we have two choices
16:37:53 <simo> DC will probably auto open
16:38:00 <simo> database almost certainly will *ask*
16:38:21 <simo> other roles may not even ask and assume *local* use by default
16:38:26 <sgallagh> 1) Default to allowing roles to punch through all interfaces and make sure the admin has an easy way to close it up again
16:38:31 <simo> database we may even decide not to ask and assume local by default
16:38:34 <sgallagh> 2) Require the roles to ask for permission
16:38:51 <simo> sgallagh: -1 and -1
16:39:06 <simo> proposal: roles determine the best default policy ro firewall puncing
16:39:07 <adamw> per-role behaviour seems reasonable, but it should be based on some kind of product policy, not just up to whim of an individual role maintainer or something
16:39:11 <sgallagh> Either way, I think we need the Roles to have an API that describes what firewall holes they want and currently have, so we can present that
16:39:19 <sgallagh> (Either during the configuration or after the fact)
16:39:25 <simo> role APIs will allow admins to affect default policy and query status
16:39:59 <sgallagh> simo: Ok, even with that proposal, I think the most important piece here is the API I just described
16:40:11 <sgallagh> Because whatever default the Role would choose, the admin needs an easy override
16:40:32 <simo> sgallagh: yes imo role api should be able to be told: "install (use role default policy)" or "install (no poking firewall)"
16:40:32 <adamw> if a role just makes no sense for local-only use, it must be unblocked, we can't just have it blocked 'for security!' as in current situation
16:40:37 <sgallagh> Ideally simpler than the complete Firewall view. I should be able to look at a role's status and understand immediately whether it's open
16:40:44 <mitr> sgallagh: Either disable firewall by default, or 2)
16:40:47 <simo> or install (poke firewall this is a pubblic service)"
16:41:22 <simo> sgallagh: I agree
16:41:30 <simo> role has default
16:41:32 <sgallagh> Let me try another proposal
16:41:36 <simo> admin can override at setup time
16:41:43 <sgallagh> I'm coming around to simo's point here
16:41:46 <simo> admin should be able to query/change after setup
16:42:13 <mitr> (Ideally the firewall API and role setup API should be decoupled, so that one can set the filrewall up in the desired state before setting up and starting the role; whether specific UIs expose that would be up to them)
16:42:16 <simo> mitr: disable firewall by default is not ok, we've already got plenty feedback about that
16:42:48 <mitr> simo: I'm in a pedantic mood today and I'm not inclined to make "enable firewall by default but punch all holes" the default choice.
16:42:54 <simo> mitr: you can always "systemctld disable firewalld.service :-)
16:43:13 <mitr> I recognize we may need to support that, but it really is revolting.
16:43:13 <simo> mitr: it is not, you are being a little bit obtuse now if I may :)
16:43:28 <sgallagh> Proposal: On a pristine system, the only open incoming port is SSH. When Roles are deployed, they may elect to open one or more ports based on the most likely need. Roles *must* provide an interface that describes which ports they want open and which ones they currently have opened. The admin must be able to easily modify this configuration.
16:43:51 <simo> sgallagh: +1
16:44:15 <mitr> sgallagh: -1.  User should know what to expect when installing a Role.
16:44:30 <simo> mitr: ok let me get a little bit upset now
16:44:36 <sgallagh> mitr: What they should expect is that the Role works.
16:44:45 <simo> mitr: if I install a domain controller, do you expect it to be operationl when I finish the setup ?
16:44:47 <sgallagh> It's up to the Role designers to say whether that means a port is open
16:44:48 <adamw> mitr: i agree with simo. there's a significant difference between 'no firewall' and 'firewall but with hole punching for all services deployed by a well-understood central configuration mechanism'.
16:44:52 <mitr> (I will go with the majority even if it's not 5 votes, I don't want us to be blocked on this)
16:45:35 <adamw> broadly +1, i'd like a bit more policy around the 'may'.
16:45:35 <mitr> adamw: That difference is "you got owned and a php script has opened a root shell port - because it is stupid and hasn't instead connected to a remote command center" AFAICT
16:45:55 <adamw> mitr: i can't parse that at all.
16:46:07 <nirik> the php script shouldn't be able to do that...
16:46:14 <mitr> simo: I agree with that expectation, so let's disable the firewall/ coinfigure it not to reject anything by default and stop the charade
16:46:36 <simo> mitr: that is just stupid
16:46:40 <adamw> no-one seems to agree with you that it's a 'charade'.
16:46:43 <mitr> adamw: On a non-compromised system, what else but deployed services is there?
16:46:56 <simo> mitr: the reason the firewall is up is that you do not want random JOE user to create a listening daemon on port 12345
16:47:01 <adamw> mitr: services deployed outside of the role mechanism, for instance?
16:47:09 <simo> random joe cannot install roles though
16:47:11 * nirik thinks we are in the weeds. Perhaps move this to list and see if there's any other topics we should try and get to today now?
16:47:11 <adamw> mitr: systemd, notoriously, contains a web server.
16:47:25 <mitr> simo: Do we expect "multi-user Linux shell system" to at all become a role?
16:47:27 <adamw> and yes, services deployed by a non-admin user in some way.
16:47:31 <simo> mitr: YEs
16:47:31 <mitr> As I said, I'll go with the majority here, let's not waste time on this...
16:47:40 <pjones> It seems like making sure deployed services are /intentionally/ deployed would be a more productive discussion to have than arguing about whether deployed services should be firewalled or not.
16:47:48 <simo> "bastion host" is clearly a role that would make sense
16:47:57 <simo> it would have pretty tight configuration
16:48:07 <simo> except with your proposal it would be a hole
16:48:19 <mitr> Wouldn't a VPN server be a more common thing nowadays?
16:48:25 <simo> taht too
16:48:46 <simo> but lot's of people regard ssh as good
16:48:58 <simo> especially in open infrastructures like  ... fedora infra ?
16:49:03 <adamw> any other votes?
16:49:30 <simo> pjones: role setup is always intentional
16:49:52 <sgallagh> adamw: BTW, if the "may" was supplemented by "default port openings must be approved by the Server WG", would that suffice?
16:50:09 <simo> sgallagh:+1 to that from me
16:50:18 <adamw> sgallagh: eh, i'd like it just to be a policy, not explicit approval for everything. but sure. you can count me as a +1 already.
16:50:23 <simo> I do not want a free pass for roles
16:50:36 <simo> I just want role setup to be meaningful and give a working product
16:50:42 <adamw> pjones: right, as simo said, the whole 'role' thing is kind of about that. we are not expecting that anyone is going to be able to accidentally deploy a role.
16:50:45 <sgallagh> adamw: Roles are going to be few. I think it just becomes part of the official process of promoting them to official
16:51:09 <adamw> sgallagh: just count me as +1. :P
16:51:21 <simo> sgallagh: at least official roles
16:51:29 <sgallagh> simo: Right
16:51:38 <simo> but this mechanism would be great for "unofficial roles" too once we have an API of sorts
16:51:46 * sgallagh nods
16:52:26 <sgallagh> ok, I have a hard stop in seven minutes.
16:52:49 <sgallagh> We don't have a consensus here, so I'm going to ask either simo or mitr to start a mailing list thread, please
16:53:30 <mitr> sgallagh: Just use the majority opinion in the document
16:53:39 <sgallagh> mitr: Ok
16:54:16 <mitr> It should be up to me tho start the thread I suppose, but I can't allocate much time for it in the near future - and I can live with that opinion even if I don't like it.
16:54:18 <adamw> iirc, the typical 'quorum' rules are that, if you're using a quorum system, a majority of voting members present at a vote is sufficient to pass it.
16:54:33 <adamw> e.g. if we have a quorum of 5, and 5 people present, 3 votes are sufficient to pass.
16:54:41 <adamw> i don't know if we've written our rules down anywhere, though.
16:54:58 <mitr> adamw: https://fedoraproject.org/wiki/Server/Governance_Charter says "5"
16:55:03 <simo> I think we discussed in the past we want always simple majority
16:55:09 <simo> right
16:55:34 <adamw> ah, OK.
16:55:40 <simo> sgallagh: anything 'light' we can go through in 5 min ?
16:56:15 <sgallagh> Not likely.
16:56:25 <mitr> Proposal: drop "session tracking" rationale: don't expect multi-user sessions to be an important case so that we need to enshrine an API for this
16:56:25 <sgallagh> Shall we formally request additional time from FESCo?
16:56:37 <sgallagh> I don't think it's likely that we'll be ready on Monday...
16:58:03 <sgallagh> mitr: +1. I mostly copied that from Workstation without thinking about it too hard.
16:58:03 <mitr> proposal: Drop accountservice reference; rationale: Server doesn't need any of the additional accountservice-provided fields
16:59:34 <simo> +1 and +1
16:59:35 <simo> we might want to do something in future, but now we shouldn;t waste time on this
16:59:35 <sgallagh> +1 to the accountsservice as well
16:59:35 <mitr> Proposal: drop "vision-impaired on the console" commitment to support rare devices, assume a Workstatiion with a good accessibility support instead
16:59:35 <mitr> ... and I think that's all I have for now.
17:00:11 <adamw> +1 to dropping accountsservice
17:00:11 <sgallagh> I added that one (vision-impaired) at simo's recommendation
17:00:11 <adamw> i'm kinda +1 to that t oo
17:00:11 <simo> mitr: -1 to the last one
17:00:11 <adamw> a11y is awesome
17:00:13 <adamw> well let's say i'm interested
17:00:13 <simo> if you are vision impaired and the network interface is down having a workstation is useless
17:00:13 <mitr> simo, adamw: Do we do any testing with a11y hardware right now?
17:00:13 <adamw> simo: how strong a commitment do we have to supporting the stuff we write about?
17:00:13 <simo> adamw: best effort
17:00:42 <adamw> desktop is coming from a position of relative strength: they have an a11y framework that's very mature
17:00:44 <adamw> i'm at least not aware that we have something like that for console
17:00:48 <adamw> simo: then it seems questionable to write something that's 'best effort' into our spec unless we're going to throw resources at it somehow
17:00:48 <simo> adamw: I know, I just think we should have at least 1 known config that can be used (locally) not via network
17:00:50 <mitr> adamw: brltty has existed for a long time, but no idea whether it even works
17:00:51 <simo> adamw: uhmm
17:01:25 <adamw> mitr: right. i mean, if we're okay with writing it into the spec and just saying 'that means it's there; we have no idea if it works'...
17:01:25 <simo> adamw: maybe we can get away with saying: "install the desktop components on the server for now"
17:01:47 <simo> although, how do you get to install them ...
17:01:47 <adamw> simo: can't we just leave it out of the spec, but include the bits?
17:01:59 <simo> ok
17:02:00 <simo> let's drop it
17:02:08 <adamw> message being "it's there, but we're not pretending we can 100% support it"
17:02:18 <sgallagh> +1 drop
17:02:21 <adamw> or explicitly write into the spec that we're providing it but not yet in a position to guarantee its functionality, or something
17:02:23 <simo> it would be nice though if we can get someone with hw to help make it a future feature
17:02:28 <adamw> sure
17:02:43 <sgallagh> simo: Sure, if that happens, we can add it to the spec then
17:02:44 <simo> ack
17:02:50 <mitr> Note that "Accessibility support in the optional graphical environment will be aligned with the Fedora Workstation offering. " would still stay with my proposal, just not the promise to have something for the console
17:02:51 <simo> +1 to drop for the record
17:02:54 <adamw> SUSE ALERT! SUSE ALERT! ACTIVATE DEFENCES!
17:02:56 <adamw> :P
17:03:12 * sgallagh blinks
17:03:14 <simo> rotfl
17:03:21 <adamw> brockmeier just came in :)
17:03:27 <simo> took a while for me to understand what that was about
17:03:31 <simo> and on this note I thank you all but I have to go
17:03:35 * sgallagh suppresses join/part
17:03:38 <sgallagh> Wait
17:03:45 <sgallagh> One last thing: shall we formally request more time?
17:03:46 <mitr> ... and with that, I'd be actually fine with submitting this to FESCo (as a partial document, missing the actual Role API and whether cockpit runs by default)
17:03:46 * simo waits
17:04:05 <simo> sgallagh: how many items are lef or w/o quorum ?
17:04:21 <adamw> do we in fact need more time? iirc, what fesco wants is enough to work on scheduling
17:04:25 <sgallagh> Well, we might be able to wrangle a whole-doc vote, I guess
17:04:30 <adamw> does what we have so far provide enough information for that?
17:04:38 <sgallagh> Ok, I'll clean up the changes we made today and call for a vote in time for Monday.
17:04:47 <simo> these documents are not set in stone
17:04:56 <simo> if something changes slightly will fesco care ?
17:04:58 <nirik> I think it would be good to get it to fesco early, even if we are still working on it.
17:05:04 <sgallagh> #topic Closing Remarks
17:05:11 <mitr> adamw: THe scheduling-important parts are the new development efforts like role API, which is exactly what we haven't talked about
17:05:29 <sgallagh> #action sgallagh to fix up the draft and call for a vote by Monday.
17:05:44 <adamw> mitr: true...
17:05:53 <sgallagh> mitr: FWIW, I had several conversations with the Cockpit folks this week
17:06:00 <adamw> mitr: though, i mean, what extra concrete info is the spec going to provide there?
17:06:04 <sgallagh> They're agreed to writing at least the first role example with us
17:06:16 <sgallagh> And believe they can deliver that by September.
17:06:29 <adamw> we at least broadly know the roles are going to be Cockpit and we're going to need an API to be written. is the spec going to provide any more useful detail in terms of estimating a timeframe for that to happen? eh. anyway.
17:06:41 <sgallagh> August would be pushing our luck, but it looks likely that we'll end up in October anyway
17:06:41 <mitr> adamw: Better idea of the scope.  I'm notoriously bad on time estimates, so it wouldn't help _me_ :)
17:06:47 <adamw> =)
17:06:56 <adamw> mitr: my rule of estimates is to take whatever the developer says and tripe it
17:06:58 <adamw> triple*
17:07:06 <sgallagh> I think "tripe" was accurate.
17:07:36 <sgallagh> Anyway, given that I actually have an estimate on that part from the people most involved with implementing it, I think we're in decent shape tehre
17:07:57 <simo> adamw: I trpe it and get trite, often even contrite after a while
17:08:06 <sgallagh> trippy
17:08:20 <simo> a troupe of developers will of course trip on the tripwire of the deadline
17:08:20 <sgallagh> Ok, anything further to discuss today?
17:08:33 <nirik> for me the big unknowns are: api, dbus listenerthing for api, and how exactly roles will be set (if rpm, then how and what dirs, etc). But we are making progress.
17:08:37 <adamw> someone tell the barman to cut simo off
17:08:43 <adamw> sgallagh: i think i'm good
17:08:55 <adamw> nirik: yeah, role deployment seems like a biggy.
17:09:02 <simo> adamw: a trappist beer for me, it's beer'o'clock (somewhere anyway)
17:09:30 <mitr> Here!
17:09:31 <simo> nirik: some of these things will only be discovered in time I guess
17:09:45 <sgallagh> mitr: yes, thank you for sticking it out late again
17:09:46 <simo> mitr: ah right
17:09:55 <simo> have a good beer^Wweekend
17:11:43 <sgallagh> #endmeeting