cockpit-devel April 2017

cockpit-devel@lists.fedorahosted.org

5 participants
5 discussions

Some upcoming events to think about for Cockpit talks
by Josh Berkus 15 Sep '17

15 Sep '17

Cockpit Devs: As we talked about earlier, we need to expose more Linux users to Cockpit. As such, I wanted to let you know about a few upcoming conferences which are heavily patronized by Linux admins and would be a good place to start: Usenix LISA https://www.usenix.org/conference/lisa17 Deadline Monday, April 24, 2017, 11:59 pm PDT Open Source Summit (was LinuxCon) http://events.linuxfoundation.org/events/open-source-summit-north-america Deadline May 6, 2017 Open Source Summit Prague http://events.linuxfoundation.org/events/open-source-summit-europe Deadline July 8, 2017 ... there will be others as the calendar progresses (as well as Meetups). If anyone is interested in presenting to external audiences about Cockpit, please let me know ... I can help with reviewing conference submissions, travel funding and more. -- -- Josh Berkus Project Atomic Red Hat OSAS

3 4

Automated Fedora update testing
by Adam Williamson 08 May '17

08 May '17

Hi folks! I thought this might be of interest to the Cockpit community, so I thought I'd write it up here in case anyone missed it elsewhere. I work on the Fedora QA team, and we have been using the openQA automated test system (developed by our friends at SUSE) to run various functional tests on Fedora composes for the last couple of years. As Cockpit is considered a critical part of Fedora Server, we run a few tests that exercise Cockpit. They're nowhere near as extensive as Cockpit's own test suite, but they run in a somewhat different context: they run on the Fedora packaged Cockpit, against the rest of a Fedora environment. They also test in a somewhat different way from Cockpit's own test suite: openQA tests a lot like a human, by booting up a virtual machine and then effectively "looking at the screen" and sending mouse and keyboard input events (via VNC). The test boots a full Fedora system, runs Firefox, and interacts with Cockpit like a human being would. For both of these reasons, it can sometimes catch problems Cockpit's own tests would not (it also sometimes goes wonky in ways that Selenium-based tests don't, but never mind, that's my job to deal with :>) Until recently we ran these tests only on Fedora's nightly development release distribution composes. Recently, though, we deployed some enhancements to our openQA setup that let us run tests on Fedora distribution updates as well, and have the results made visible through the Fedora update system (Bodhi). I have just made it so that, from now on, these tests will run on any update that contains the 'cockpit' package. They also run on any critical path update. This means that for any Fedora update containing cockpit or any critical path package, Fedora's openQA cockpit tests should run, and you should see the results in the Fedora update system (Bodhi). You can see the results in Bodhi by clicking the Automated Updates tab for any update. For instance, here's a recent Firefox update for Fedora 25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-31c64a0bbf If you look at the Automated Tests tab, you can see passes for: update.server_cockpit_basic update.server_cockpit_default update.realmd_join_cockpit indicating that this Firefox update didn't cause any problems for Cockpit. Clicking on any test result will take you to the openQA page for the test, where you can diagnose failures and so on (explaining how to do this is a bit beyond the scope of this mail, please do ask me if you're interested!) I hope this stuff will help us avoid shipping updates that break Cockpit (and other key components). If you have any questions, concerns, comments, or suggestions, please do ask! To anticipate one question: you can cause *all* the tests for an update to be re-run by editing the update in any way (you don't have to change the package loadout, just changing a single character in the description or something will do). If you think just one test result is bogus and want it re-run, currently, you'll have to ask someone with the necessary power - either me or Jan Sedlak (garretraziel on IRC). I'm in North America and he's in Europe, so we should have most timezones covered between us. We're hoping to set up a better mechanism for this in future. Note, if you're interested in the results for the nightly Fedora distribution composes, an email summary of the results for those is sent each time they're run to the Fedora test@ and devel@ lists, look for mails with "compose check report" in the subject. Any time any of the cockpit tests fails, the failure will be listed in the mail (passed tests are not specifically listed, just a count of them). I usually keep an eye on those results and analyze failures and file bugs, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

3 6

Weekly meeting
by Marius Vollmer 10 Apr '17

10 Apr '17

================= #cockpit: meeting ================= Meeting started by mvollmer at 13:01:42 UTC. The full logs are available at https://meetbot.fedoraproject.org/cockpit/2017-04-10/meeting.2017-04-10-13.… . Meeting summary --------------- * Agenda (mvollmer, 13:03:36) * Fedora 26 (mvollmer, 13:05:32) * Authentication/Authorize protocol changes (mvollmer, 13:19:42) * LINK: https://github.com/cockpit-project/cockpit/blob/master/doc/protocol.md (stefw, 13:21:17) * Other business (mvollmer, 13:33:30) Meeting ended at 13:35:18 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * stefw (39) * mvollmer (33) * pitti (13) * zodbot (8) * dperpeet_ (2) * garrett (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Weekly meeting 2017-04-03
by Andreas Nilsson 03 Apr '17

03 Apr '17

=========================================== #cockpit: Weekly Cockpit meeting 2017-04-03 =========================================== Meeting started by andreasn at 13:07:37 UTC. The full logs are available at https://meetbot.fedoraproject.org/cockpit/2017-04-03/weekly_cockpit_meeting… . Meeting summary --------------- * Agenda (andreasn, 13:08:57) * ABRT (andreasn, 13:10:17) * LINK: https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahost… (andreasn, 13:10:41) * Security between nested login sessions (andreasn, 13:14:58) * Server Apps (andreasn, 13:19:17) * LINK: https://github.com/cockpit-project/cockpit/wiki/Server-Applications (andreasn, 13:21:05) Meeting ended at 13:29:09 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mvollmer (38) * andreasn (38) * dperpeet (7) * zodbot (6) * petervo (3) * garrett (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Assumed security between nested login sessions
by Stef Walter 03 Apr '17

03 Apr '17

Cockpit is a Linux session. Normally when you connect from one login session to a second one, the second login session does not access to the first ... although the does not hold. For example if you SSH into machineA ... and then from machineA SSH into machineB ... it is assumed (and typically the case) that the login session on machineB does not have access to the login session on machineA. In Cockpit this has not been the case. When you start a Cockpit login session on machineA ... and then in Cockpit on machineA you add machineB as a second server. The Cockpit login session tasks/code for each of those have equal access to one another via the browser. I worked with Muelli over the weekend to try and fix this and here's a basic pull request: https://github.com/cockpit-project/cockpit/pull/6260 We can ask the browser to apply the Same Origin policy and keep the sessions sandboxed. There's several places where some follow up work is needed, as seen by the dependencies of that pull request. But also it's impossible to use window.localStorage from such a browser sandbox. So if we put this in, we would likely need to implement a new window.localStorage that uses window.postMessage with "hint" messages to store/retrieve contents. Once this is done, we can enforce the separation of concerns between stuff running from different machines and start to mirror this assumed behavior of Linux login sessions. Cheers, Stef

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

cockpit-devel April 2017