13:01:55 #startmeeting 13:01:56 Meeting started Mon Jun 29 13:01:55 2015 UTC. The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:56 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:02:02 .hello mvo 13:02:03 mvollmer: mvo 'Marius Vollmer' 13:02:07 .hello stefw 13:02:10 stefw: stefw 'Stef Walter' 13:02:10 .hello tengland 13:02:12 Shad0w_Crux: tengland 'Turner England Jr' 13:02:55 #topic Agenda 13:03:00 .hello dperpeet 13:03:03 dperpeet: dperpeet 'Dominik Perpeet' 13:03:05 * Certificate generation fixes 13:03:09 * Announcing compatibility issues 13:03:14 * SSH key authentication UX 13:03:17 * Fedora 23 jQuery change 13:03:39 * journal 13:04:17 * testing of master 13:04:33 should be enough :-) 13:04:48 #topic Certificate generation fixes 13:04:59 so while we're dealing with compatibility fixes ... 13:05:09 there's one more that prevents use of our generated certificates on older versions of firefox (at least) 13:05:23 https://github.com/cockpit-project/cockpit/issues/2423 13:05:35 this has to do with the fix we were forced to do for latest versions of firefox (where it would hang) 13:05:54 newer firefoxes hang when they see too many certificates with CN=localhost and CA:true 13:06:03 well really any identical CN over and over 13:06:18 and older versions of firefox refuse to connect when the self-signed certificate has CA:false 13:06:31 so we probably have to generate our own CA, and then make a certificate signed by that 13:06:35 instead of using self-signed directly 13:06:54 right 13:06:57 as an aside, all of this makes me think we should use gnutls to generate the certs (since that's what we use for TLS) 13:07:03 rather than depending on both gnutls and openssl 13:07:24 does anyone else do this? self-signed CA? 13:08:04 sorry for being late 13:08:08 i think many do 13:08:11 .hello andreasn 13:08:12 andreasn: andreasn 'Andreas Nilsson' 13:08:12 are we violating any sound principles? 13:08:13 but they all prompt for a name 13:08:22 the code we currently have was reviewed by NSS maintaniers 13:08:25 well one of them 13:08:34 but obviously they didn't consider older versions of NSS when they did so 13:08:52 i wouldn't use both "x509" and "sound principles" in the same sentence 13:09:05 :-) 13:09:06 :) 13:09:41 what I was getting at: do we need to fix our behavior or do we need a workaround for something that's weird in firefox? 13:10:43 well self-signed certs are pretty gray area 13:10:48 a lot of it is really a matter of opinion 13:10:57 i'd say the real fix is to further integrate with IPA for cert generation 13:11:10 but that would come after basic non-local users are working 13:11:24 but if we can reduce our dependencies and make the certificate generation more compatible, that's good 13:11:24 so it's a ways off 13:11:25 for now this affects lots of pepole 13:11:25 they just can't use cockpit 13:12:14 is there a way to help users see a sane error message? 13:12:25 http fallback with notice? 13:12:45 I'm not familiar enough with browser mechanics to know if that could work 13:13:01 no 13:13:06 it seems like we don't have many choices if the browser decides it's unsafe to connect 13:13:10 right 13:13:51 then let's go for the generated CA 13:14:13 alright ... unfortunately we can't use sgallagh's implementation, due to deps 13:14:16 but i'll try to use it as a guide 13:14:26 we also don't have the same needs as openlmi 13:14:34 since they tried to import it into the local trusted store 13:14:55 /me looks up 13:14:59 #info Will rewrite CA generation to have a self-signed CA and a signed certificate from that to use in cockpit-ws 13:15:27 stefw: What are the problematic deps? 13:15:41 we want to use just one crypto library 13:15:44 and not "collect the whole set" 13:15:50 stefw: OK, which one are you using? 13:15:54 gnutls 13:15:55 via glib 13:16:28 mvollmer, next topic? 13:16:33 ok 13:16:43 #topic Announcing compatibility issues 13:17:00 so ... the question then becomes 13:17:15 do we wait for above fix before announcing all our compatibility fixes? 13:17:19 or just go for it now 13:17:21 so far we have: 13:17:24 1. docker 13:17:33 2. capabilities in bridge 13:17:39 3. dbus not ignoring unknown messages 13:17:47 4. soon the self-signed cert will be fixed 13:18:24 I don't believe waiting serves any good purpose 13:18:50 the question is whether it'd be worth keeping a wiki page for such fixes 13:18:59 and linking it from the landing page 13:19:14 hmmm not sure 13:19:17 or if there aren't enough users to warrant the effort 13:19:19 i think we should just update cockpit-project.org 13:19:30 and say versions later than X have no problems talking to each other. 13:19:37 prior to that support is patchy 13:19:38 ? 13:19:43 sounds good 13:19:56 less work and more informative than having to look at a whole page of version numbers 13:20:02 right 13:20:25 under the Multi-server section in the website? 13:20:32 another angle might be to put a message into Cockpit itself: "You should update Cockpit" 13:20:43 but we need the backends for that 13:20:50 to detect new versions 13:21:07 but for that cockpit would need to connect to our server 13:21:10 mvollmer, yes, not a bad idea ... but some of the errors are unpredictable 13:21:13 of course, this is a generic feature 13:21:18 for example a "protocol-error" in some cases 13:21:25 something like that should be opt-in 13:21:38 i don't think we should overcomplicate this 13:21:48 andreasn, what multi-server section in the website? 13:21:51 i was thinking that the bridge figures out in a OS-specific way whether there is an update for itself. 13:21:54 and it sounds like an optional future feature 13:22:02 stefw: under the 3rd screenshot 13:22:03 hm 13:22:06 but that blends into the "you have updates" features 13:22:20 yes, we haven't really laid all the groundwork for updates I think 13:22:22 stefw: we can figure out the details on where on the website after the meeting 13:22:25 anyway, maybe this can help in the longer term. 13:22:31 ok, andreasn, it could go in the docs 13:22:34 and then link it from the website 13:22:39 sure 13:22:41 it's a good idea, once cockpit is good with updates 13:22:53 should be considered during design, andreasn 13:23:24 right 13:24:06 petervo, what are the updates that need to be pushed out for the compatibility fixes to take? 13:24:27 i guess there's this: https://admin.fedoraproject.org/updates/FEDORA-2015-10740/cockpit-0.62-1.fc22?_csrf_token=53967988c9a359a2794cc4f8487da31509d07f0a 13:24:36 the capabilities and the cockpit js change 13:25:09 this is a start: https://admin.fedoraproject.org/updates/FEDORA-2015-10740/cockpit-0.62-1.fc22 13:25:19 yes 13:25:51 lets give karma to that for starters 13:27:47 ok, next topic? 13:28:23 yup 13:29:01 mvollmer: ? 13:29:14 yup 13:29:30 #topic SSH key authentication UX 13:29:56 petervo is working on SSH key authentication 13:30:14 so that you can use ssh keys in the account of the first s erver you connect to then connect to other servers 13:30:25 one use case is connecting to localhost 13:30:31 what does this mean exactly? Placing a .pub key and avoid passwords? 13:30:46 so it means placing id_xxx and id_xxx.pub 13:30:48 in ~/.ssh 13:30:52 on the first serevr you connect to 13:30:59 encrypted with your login password, or no password 13:31:10 ah, right 13:31:15 i'm wondering if we can list these or help people with them in the "Administrator Accounts" stuff 13:31:19 at least for your own account 13:31:33 there is some good prior art with github 13:31:35 can we use existing keys as well? 13:31:36 's keys here 13:31:42 yes existing keys would be supported 13:31:49 as long as they have the right password or no password 13:31:57 or the user changes it 13:32:00 right makes sense 13:32:14 filesystem based or ssh-agent, too? 13:32:20 ssh-agent based 13:32:25 we start the ssh-agent in the session 13:32:29 peter has a pull request that's WIP 13:32:34 about half done, i think 13:32:43 petervo, could you start a: https://github.com/cockpit-project/cockpit/wiki/New-Features 13:32:44 ? 13:32:51 and then we can contribute and fill it out? 13:32:51 sure 13:33:02 andreasn, are you interested in working on the UX? 13:33:07 stefw: totally 13:33:39 #info petervo, andreasn, will start up a feature page for key based SSH UX 13:34:13 maybe the actual work can be a separate pull request? 13:34:23 but probably shouldn't be considered done, until normal people can actually use it 13:34:40 big use case is cloud OS's like Atomic Host that usually get deployed without password auth 13:34:55 anyway, that's all i wanted to say on that. 13:35:06 good stuff 13:36:03 next? 13:36:10 sure 13:36:19 #topic Fedora 23 jQuery chang 13:36:31 there's a Fedora 23 change suggesting that everyone uses one copy of jQuery 13:36:36 this is problematic for us 13:36:42 not only because we gzip and bundle stuff 13:36:59 doesn't every project that use patternfly also use jquery? 13:37:01 but also because jQuery ends up as part of our public API, and it will be hard to support people upstream if distributions randomly change out our deps 13:37:04 andreasn, yes 13:37:12 sgallagh, ^^ do you have anything to say about this? 13:37:39 i think the idea is not to "randomly" change it, no? 13:38:00 well if every distro did this 13:38:03 it would *feel* pretty random 13:38:05 stefw: We 13:38:17 're basically back to the old bundled vs. system lib argument 13:38:22 I'm not sure if we'd really have a problem since we don't use anything really version specific in jquery, do we? 13:38:36 from what I've seen we pretty much stick to the solid basics 13:38:38 how do we know that? 13:38:59 the problem I see is with diverging loading paths for fedora and the rest 13:39:01 sgallagh, right, which is getting pretty tried in a container world 13:39:09 it spreads our testing tree further 13:39:25 loading paths are far from the issue. we wouldn't even be able to load the files they have in place 13:39:38 I mean we would have to do things differently 13:39:49 what speaks against just bundling anyway? 13:39:57 would it be mandatory? 13:40:04 to use that one version 13:40:13 sgallagh, now we get jQuery via bower, would it be enough to get it via a rpm at build time? 13:40:29 anyway this is not set in stone 13:40:33 dperpeet: Basically, yes. It's a request to change the packaging guidelines to drop the bundling exception now that there's a way to use a central copy 13:40:33 it's up to us to speak up against this 13:40:35 if it ruins Cockpit 13:40:37 or is the idea to not have any jQuery inside the cockpit binray rpms? 13:40:47 and what about every other dependency from github? 13:41:06 this is a proposed change 13:41:11 It'll be discussed at FESCo this week, but as of right now I'm against making this mandatory before F24. (I have no problem with carrying a library that people can try) 13:41:19 so my point is that we should oppose it in its current form 13:42:03 Fedora should do its own full stack CI and support before changing upstream apps like this 13:42:24 because right after jquery comes angularjs and other stuff 13:42:26 I don't like the idea of jquery versions just changing on us, without control 13:42:41 it's difficult enough to support the different flavors that we do test 13:42:45 yes, jquery may be the most stable javascript library out there but even it is problematic in this context 13:42:55 it all goes down hill from there 13:43:01 especially things like patternfly 13:43:03 or angularjs 13:43:07 term.js 13:43:07 etc. 13:43:30 a certain version of patternfly relies on a certain version of jquery, right? 13:43:34 right 13:43:36 hubbot/f22/x86-64/jquery1.1/patternfly1.4 doesn't look good :) 13:44:02 but if there was a mandated central version of patternfly 13:44:20 then fedora can start hiring tech support staff 13:44:23 :D 13:44:55 I can send a mail about the fedora change to the patternfly list 13:45:22 because it would affect them quite a bit I would imagine 13:45:35 sgallagh, so if this sets a precedent 13:45:44 as in, will go beyond jquery 13:45:55 then Fedora becomes a really really bad place to package your software 13:46:02 well web applications 13:46:21 if the change proposal is changed significantly (ie: to include CI of the apps) then perhaps jQuery could be manageable 13:46:26 anything beyond that just plain isn't 13:46:37 if anyone wants to respond to the proposal: https://lists.fedoraproject.org/pipermail/devel/2015-June/211698.html 13:47:08 stefw: Yeah, I'm with you. As I said, I plan to oppose any attempt to make this mandatory in F23. 13:47:28 what are the reasons for the change anyway? 13:47:40 sgallagh, alright, let us know if you need any further feedback or help 13:48:12 mvollmer: better potential protection against security holes in jquery 13:48:20 ahh, found the "benefit" section. 13:49:36 and the fix should be roll-out-able by simply updating the jQuery rpm? Or is it ok to recompile? 13:49:57 so we would recompile our deps on the fly? 13:50:05 no, not on the fly 13:50:05 mvollmer: As with other libs, I think the intent is that the one package should be updated only 13:50:06 like how would we get back to our jquery.min.js.gz? 13:50:17 If all the deps need updating, then it's functionally identical to bundling 13:50:20 our bundle of jquery which includes about 8 javascript modules 13:50:21 except without the control 13:50:38 jquery update -> cockpit update -> logout/login -> user has fix 13:50:39 except it's not 13:50:39 see above ^^ 13:50:45 how do you update part of a minified javascript gzipped file? 13:50:52 without recompiling? 13:51:01 stefw: I think we're agreeing, but I phrased it poorly. 13:51:08 oh sorry 13:51:17 alright, i'm done on this topic i guess. 13:51:30 we only have ten more minutes 13:51:32 right 13:51:59 personally, I think I wouldn't balk at getting jQuery from Fedora instead of bower at build time. 13:52:13 getting it at runtime is a whole different story. 13:52:14 if we can request a specific version from Fedora, yes 13:52:20 build-time wouldn't be a problem 13:52:34 and they can keep the specific versions all patched 13:52:43 it would be a crazy amount of work for Fedora 13:52:53 so Fedora should prepare itself to recompile reverse build-depebds when updating jQuery 13:53:01 and the package would have to include the minified, gzipped file 13:53:27 well, gzipped is not necessary, 13:53:28 dperpeet, browsers don't support concatenating gzipped files 13:53:30 even though the spec does 13:53:45 dperpeet, we have more than just jQuery in our jquery.min.js.gz 13:53:50 next? :-) 13:53:51 it's a bundle of jquery and jquery plugins 13:53:52 true 13:53:53 next 13:54:08 #topic journal 13:54:24 so, I've been working on the new journal layout https://trello.com/c/if88ORZv/73-new-journal-look 13:54:37 the templates are pretty finished, after some iteration with andreasn last week 13:54:49 note to andreasn: they now work entirely without float elements 13:54:54 wow cool 13:55:01 are you using bootstrap-selectize for the search thingy? 13:55:05 because it makes that *really* really easy 13:55:12 not yet, I'm working on that section 13:55:13 and the openshift guys want us to use it on the kubernetes page as well 13:55:24 thanks for the pointer to openshift, I'll look at that 13:55:43 dperpeet, http://brianreavis.github.io/selectize.js/ 13:55:46 the search has two components 13:55:48 that's what they're using 13:55:53 one is server-side via journalctl parameters 13:56:04 where we also get a list of tags we can set 13:56:18 those are basically the "columns" in the data we can see 13:56:24 when we look at journal details 13:56:32 the other part is wildcard searching client-side 13:56:49 but that aside, there is a larger issue 13:57:02 regarding preparation for multi-host journals 13:57:16 if we have multiple hosts, do we just add a host column? 13:57:27 or do we want to do that differently, somehow? 13:57:39 I can't remember what I sketched out regarding that 13:57:42 I believe such an "interleaved" mode would be best for troubleshooting 13:57:45 let me see if I can find something 13:57:49 I didn't see anything for multihost 13:58:03 right, we talked about making this a dashboard across all the servers you have 13:58:09 or at least moving it there when you have more than 1 server? 13:58:30 should we talk about this in the Feature page? 13:58:35 there is a Feature page right? 13:58:37 yeah, that would be good 13:59:06 I would have to look, I've been using trello, issues and the mockups 13:59:11 dperpeet, i don't see a feature page here: https://github.com/cockpit-project/cockpit/wiki/Features 13:59:19 if we have one, we should probably link it there 13:59:20 no, we don't have any feature page. I can create one 13:59:23 oh ok 13:59:29 yeah, I think merging the current design into a feature page would be good 13:59:33 because that'll help answer a lot of questions 13:59:38 andreasn, want me to start one and we iterate? 13:59:39 such as how this is supposed to be used 13:59:39 etc. 13:59:43 dperpeet: sure 13:59:55 ok, then we can discuss things there 13:59:58 sure 13:59:59 dperpeet, the ideas you listed aren't bad 14:00:08 but better to hash them out on a feature page with the use cases nearby 14:00:20 I also switched to mustache templates 14:00:28 any performance data? 14:00:33 I performed some js performance tests 14:00:33 and partial loading? 14:00:38 and they were good 14:00:51 especially considering that mustache does proper html escaping 14:01:06 which would relieve a few security headaches in that part of cockpit 14:01:09 right. and i guess you just run it through mustache multiple times to do partial loading? 14:01:20 I have a template for a log-line 14:01:22 because that's a key feature of the page, obviously 14:01:24 ah ok 14:01:25 and the template is preparsed 14:01:27 cool 14:01:39 and there's a template for a "section" (i.e. day) 14:01:57 tests showed performance losses of 2-5% 14:02:03 string concat vs mustache 14:02:22 totally acceptable when considering the cleaner code 14:02:43 I can tweak the loading if necessary as well 14:02:49 but we'll discuss on the feature page 14:02:52 end of topic 14:03:30 #info dperpeet, andreasn will start feature page in wiki for new journal layout 14:04:08 #topic master testing 14:04:25 ok, only briefly, I guess 14:04:36 so master testing right now is pretty uninteresting 14:04:44 it just retests the most recent PR 14:04:59 but we had a discussion to make it more interesting 14:05:03 the idea has been for some time that we do more interesting master testing 14:05:18 so I propose this: 14:05:30 ohh, pr has been merged. :-) 14:05:45 https://github.com/cockpit-project/cockpit/pull/2445 14:05:55 no selinux policy overwrite 14:06:02 always latest packages from the distro 14:06:17 downside is that master testing takes a lot longer 14:06:31 also we are going to test f22-updates-testing separately. 14:06:55 the idea is that master should be checked like that daily 14:07:07 so we have rhel-7, f22, f-rawhide, f22-plus-updates-testing, f22-atomic 14:07:21 since our pull requests are rebased on master anyway, when they are tested before merging 14:07:23 and we shouldn't shy away from testing more 14:08:13 so, should we throttle master checking to once per day for each config before enabling --clean, or after? 14:08:41 before 14:08:55 I can fix the priority system also, that shouldn't take more than half a day 14:09:00 we should add centos, arm, maybe debian just for kicks. 14:09:11 ok, great. 14:09:27 that way our pull requests don't get railroaded my long master checks 14:09:30 *by 14:09:57 it might still happen, but that's life 14:10:17 i guess one test run will take about 30 minutes 14:10:24 or less 14:11:44 #action dperpeet make sure that master testing doesnt happen too often 14:11:55 what about testing only tags? 14:12:00 i.e., releases? 14:12:12 that would be a bit backwards, no? 14:12:23 better to test before release 14:13:14 anyway, the improved image creation machinery is almost fun to use. 14:13:29 making the stock images was quite easy, for example 14:13:43 ok, eot? 14:13:52 yes, the change was good :) 14:14:13 we are accumulating a lot of images already 14:14:18 let's see how the gc works. 14:14:28 f22 is up to version 8. 14:14:39 but it's good to make that visible 14:14:56 ok 14:14:59 maybe we should show the version on hubbot status 14:15:08 we can discuss that separately 14:15:15 yeah, why not 14:15:23 but there are many versions per pr 14:15:53 let's close 14:15:57 #topic open floor 14:17:17 someone? 14:17:23 ok 14:17:26 #endmeeting