14:05:49 <mvollmer> #startmeeting naked ping
14:05:50 <zodbot> Meeting started Mon Dec 12 14:05:49 2016 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:05:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:05:50 <zodbot> The meeting name has been set to 'naked_ping'
14:06:05 <mvollmer> #topic Agenda
14:06:08 <mvollmer> .hello mvo
14:06:10 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:06:34 <dperpeet> .hello dperpeet
14:06:34 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
14:06:45 <cockpitbot> 1 tests failed - http://fedorapeople.org/groups/cockpit/logs/master-5c863e2b-verify-fedora-atomic/log.html
14:07:19 <stefw> .hello stefw
14:07:20 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
14:07:30 <larsu> .hello larsu
14:07:31 <zodbot> larsu: larsu 'Lars Karlitski' <lars@karlitski.net>
14:09:54 <mvollmer> do we have topics?
14:10:39 <mvollmer> * ram disks on Ubuntu
14:11:16 <stefw> * Authorization for privileged actions
14:11:30 <stefw> * Remaining translations work
14:13:33 <mvollmer> alright
14:13:40 <mvollmer> #topic ram disks on Ubuntu
14:14:12 <mvollmer> the storage page on ubuntu shows dozens of inactive loopback devices and small ram disks
14:14:28 <mvollmer> this is unlike any other OS we support, I think
14:14:50 <mvollmer> normally, inactive loop devices don't exist at all, I think
14:15:01 <mvollmer> anyway, they can be filtered out
14:15:16 <mvollmer> ram disks are different, they actually work
14:15:31 <mvollmer> except that the udev rules skip them
14:15:50 <mvollmer> so udisks2/storaged will not tell us what is in them
14:15:57 <mvollmer> which makes them also useless in the UI
14:16:15 <mvollmer> i made a PR for storaged to set the IGNORE hint for them
14:16:33 <mvollmer> does anyone know anything about these ram disk things?
14:16:50 <mvollmer> the internet says to use tmpfs instead
14:17:12 <mvollmer> I could ask pitti
14:17:50 <mvollmer> eot :-)
14:18:08 <mvollmer> #topic Authorization for privileged actions
14:18:41 <stefw> The next release of Cockpit will require that you check a box before logging into the system
14:18:45 <stefw> if you would like to perform privileged actions.
14:19:05 <stefw> The privilege escalation logic still uses the same mechanisms before, although that will change shortly after the next release.
14:19:18 <mvollmer> but root is still root, right?
14:19:21 <stefw> yup
14:19:34 <stefw> This workflow means that we model the Linux privilege model better
14:19:43 <stefw> essentially we automatically do a sudo for you if you check the box
14:20:04 <stefw> In addition, not yet implemented, reprompting for passwords after the fact.
14:20:30 <stefw> Again, that'll be future work. Where likely you can click a button within Cockpit to get such a prompt ... i doubt we'll interrupt your work randomly to prompt.
14:20:49 <stefw> There are two remaining pull requests that should get in before the release
14:20:57 <stefw> which help the API of things merged recently to be solid:
14:21:05 <stefw> https://github.com/cockpit-project/cockpit/pull/5545
14:21:06 <mvollmer> stefw, could you explain why we change our approach here?
14:21:10 <stefw> https://github.com/cockpit-project/cockpit/pull/5548
14:21:39 <stefw> I tried to "reinvent" the way reauthorization happened in Linux API services ... years ago ... by implementing something alternate in Cockpit.
14:21:53 <stefw> I didn't have the time or energy to actually finish the massive amount of work that this entails.
14:21:57 <mvollmer> the pam module?
14:22:01 <stefw> yup
14:22:02 <stefw> as seen here:
14:22:12 <stefw> https://github.com/cockpit-project/cockpit/blob/master/doc/reauthorize.md
14:22:38 <stefw> So given that I/we haven't been able to change Linux in this respect (yet?) ...
14:22:57 <stefw> ... we need to instead model the fact that Cockpit is a real Linux session, and deal with the realities of real Linux sessions.
14:23:35 <stefw> in the future if we do actually make reworking of privilege escalation in a Linux session happen in a better way, then we can obviously have Cockpit model that
14:23:51 <stefw> The current Linux model is:
14:23:56 <stefw> 1. log into a system as non-root
14:24:12 <stefw> 2. use sudo and/or polkit to escalate privileges as permitted
14:24:36 <stefw> These changes reflect that model, but allow both steps to be collapsed into if desired.
14:24:55 <stefw> In other words, the second step can automatically happen right after authentication if desired.
14:25:07 <stefw> the user who logs in indicates this desire by checking the box
14:25:11 * stefw gets a screenshot
14:25:52 <stefw> https://cloud.githubusercontent.com/assets/795070/20791780/0524cd4a-b7bf-11e6-9a56-ebeeb876a0d0.png
14:25:56 <stefw> does that make sense?
14:25:58 <mvollmer> so there is only a single cockpit-bridge process, and it is either privileged, or not?
14:26:16 <stefw> when the user has become privileged, there is usually a second bridge process
14:26:18 <stefw> this has not changed.
14:26:22 <stefw> nor will that change
14:26:24 <mvollmer> okay
14:26:49 <mvollmer> but when the checkbox is checked, all channels get { superuser: true } by default?
14:26:53 <stefw> no
14:27:14 <stefw> "superuser: true" works when the checkbox is checked ... and the user can escalate privileges
14:27:23 <stefw> if the checkbox is not checked ... and the user is not already root
14:27:29 <mvollmer> right, isee
14:27:32 <stefw> then "superuser: true" will fail with access-denied
14:28:40 <stefw> the checkbox choice is remembered between logins
14:28:56 <stefw> so the same browser used against the same host will preserve the checkbox state
14:29:00 <stefw> all of this is already merged
14:29:09 <stefw> but two further pull requests help solidify this work into an API stable state
14:29:15 * stefw has to go in 1 minute ...
14:29:28 <mvollmer> thanks for the explanation!
14:29:31 <stefw> both pull requests are marked with priority in github
14:29:46 <petervo> i'm reviewing and will merge soon hopefully
14:30:15 <stefw> awesome. thank you.
14:32:05 <mvollmer> okay, next?
14:32:18 <mvollmer> ahh, that's also stefw...
14:32:54 <mvollmer> let's just talk about translations a bit
14:33:07 <mvollmer> #topic Translations
14:33:32 <mvollmer> so keeping translations complete is hard
14:33:38 <mvollmer> how do we do it? :-)
14:33:54 <mvollmer> strict code review?
14:34:25 <mvollmer> we have fixed the machinery a couple of times
14:34:34 <mvollmer> but then it has rotted away again, I guess
14:34:52 <mvollmer> can we make some automated tests for the bare minimals?
14:35:11 <petervo> well we have tests
14:35:14 <dperpeet> mvollmer, we have a test
14:35:18 <mvollmer> ahh, cool
14:35:28 <petervo> a big problem before was that we introduced new javascript frameworks
14:35:47 <petervo> without sorting out how translations would happen
14:36:09 <petervo> and then because they weren't work there, we sort of ignored problems elsewhere as well
14:36:45 <mvollmer> yeah
14:36:50 <petervo> having regular contributors who care about a non english language is really helpful for this
14:37:10 <petervo> vanloswang on github has helped alot
14:37:28 <petervo> with finding what's missing
14:38:26 <github> [cockpit] mvollmer pushed 1 new commit to master: https://git.io/v16ee
14:38:26 <github> cockpit/master 88a6171 cockpituous: Image refresh for fedora-24...
14:38:33 <mvollmer> petervo, do you know what work still remains?
14:38:56 <petervo> no i don't, i was interested in what that was
14:39:12 <mvollmer> okay
14:39:17 <petervo> maybe to do with supporting multiple releases?
14:39:26 <petervo> idk
14:39:36 <mvollmer> sorry, I didn't realize stef had to go and messed up the schedule, I guess
14:39:45 <dperpeet> mvollmer, https://trello.com/c/Eut2LIkk/111-epic-translations
14:40:05 <dperpeet> or did you mean the agenda?
14:40:08 <mvollmer> very good
14:40:18 <petervo> ah login screen
14:41:04 <mvollmer> packaging is quite fundamental
14:41:45 <dperpeet> yeah, the question is how we do that properly across distros
14:41:47 <petervo> yeah, they are packaged now but always all together
14:42:26 <github> [cockpit] mvollmer opened pull request #5581: test: Handle dynamic storage content rows better (master...storaged-dont-race-the-rows) https://git.io/v16eM
14:42:41 <mvollmer> okay, we will see what stefw has in mind
14:42:47 <stefw> hi i'm back
14:43:21 <stefw> so my basic agenda topic was to say that the translations are mostly done, but there are two areas where they are incomplete
14:43:22 <mvollmer> alright
14:43:29 <stefw> 1. the login screen
14:43:39 <stefw> 2. splitting translations among packages installed on different schedules
14:44:00 <stefw> For the login screen petervo has suggested a solution, which could work.
14:44:16 <stefw> For the split of translations we don't have ideas or work done there yet.
14:44:27 <stefw> right now everything is in the shell component
14:44:40 <mvollmer> and each language is a single file, right?
14:44:44 <stefw> and so if a later version of (lets say) the ostree package is installed ... then the translations will be missed
14:44:46 <stefw> mvollmer, yes
14:45:08 <stefw> so we need a solution that is performant (not another 15 HTTP requests) ... but still able to be split up somehow
14:45:23 <mvollmer> right
14:45:41 <mvollmer> could manifests bring their own translations inline, for example?
14:45:48 <mvollmer> like *.desktop files
14:46:05 <stefw> yes there are solutions like that
14:46:31 <stefw> i'm not sure we have to decide the final solution here ... unless someone has an idea and wants to run with it :)
14:49:46 <mvollmer> so translations would always be bundled with the code, right?
14:50:07 <mvollmer> and we would always install all languages
14:50:35 <dperpeet> I wouldn't necessarily say that
14:50:51 <dperpeet> but for now that seems the most practical solution
14:51:33 <dperpeet> but I guess some translation is always better than none
14:51:40 <mvollmer> it's also what everyone else is doing, right?
14:54:11 <dperpeet> I believe it is a common solution, yes
14:55:04 <mvollmer> okay, looks like we are done
14:55:13 <mvollmer> #topic Open floor
14:55:55 <stefw> dperpeet, i like that point
14:56:10 <stefw> if we can choose a translations-per-package solution that doesn't involve stable aPI
14:56:16 <stefw> then we can be pragmatic and change it later
14:56:25 <dperpeet> yes, I agre
14:56:27 <dperpeet> agree
14:57:01 <mvollmer> we might want to share common translations between packages
14:57:11 <mvollmer> but that should happen at build time or translation time
15:00:33 <stefw> mvollmer, indeed
15:00:40 <stefw> msgfilter FTW
15:00:44 <stefw> that's the easy part, in fact
15:00:46 <stefw> especially at build time
15:00:58 <stefw> we already split our translations
15:01:22 <stefw> for example we only inlcude in our binary gettext mo files the translations used by cockpit-ws
15:01:33 <stefw> and we don't include those messages in our frontend javascript based po files
15:03:55 <mvollmer> okay, all done?
15:04:01 <stefw> yes, i think so
15:04:04 <mvollmer> thanks everyone!
15:04:08 <mvollmer> #endmeeting