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