cockpit-devel June 2020

cockpit-devel@lists.fedorahosted.org

6 participants
7 discussions

Suggestion for changing cockpit default session timeout
by Gal Zaidman 06 Jul '20

06 Jul '20

Hi Cockpit developers, I saw that on cockpit-209 Session timeouts were added with the default to 15 minutes of inactivity (https://cockpit-project.org/blog/cockpit-209.html ). I think that this change is problematic because: 1. The timeout is very short and it can cause unexpected behavior to users and cockpit packages. 2. The timeout can only be configured in the /etc/cockpit.conf file, so it is hard for packages to configure it to fit to their behavior. For example, we created a package for installing ovirt with cockpit UI, that installation can take a lot of time, it has different phases and logging out in the middle can cause problems. We prefer to avoid editing /etc/cockpit.conf because we don't want to run over user configuration (what to do when there is already cockpit.conf present?) I want to suggest: 1. Raising the timeout to 2 hours of inactivity, this seems reasonable. 2. Provide a more flexible way of configuring the timeout, with an option to the manifest.json package file and/or with a cockpit API call. Thanks

7 8

Importing base1/patternfly.css is deprecated
by Martin Pitt 25 Jun '20

25 Jun '20

Hello Cockpit developers, for many years, Cockpit related projects used to do this in their top-level HTML: <link rel="stylesheet" href="../base1/patternfly.css"> This was also an officially documented API, formerly at [1]. The intention (most probably) was that CSS tweaks applied to Cockpit itself would also directly apply to all projects that provide Cockpit pages, to keep a consistent look & feel. However, this is not sustainable. PatternFly 3 has been replaced with PatternFly 4 a while ago, and Cockpit can't offer a PatternFly 3 API indefinitely. Also, base1/patternfly.css was modified heavily so that PF3 would *look like* PF4 [2]. This broke third-party extensions in a lot of subtle ways. Thus it is better if pages are bundling their own CSS completely, and thus can update to newer PatternFly releases at their own pace, and visually check that everything fits together. That's why [1] disappeared, and this API is now deprecated. Instead, projects should include PatternFly 3 and/or 4 themselves and import (and regularly sync with) Cockpit's CSS overrides [3]. Projects that only use PatternFly 4 follow starter-kit's example [4]. Projects that still need PatternFly 3 still can instead do what cockpit-podman did [5]. Our next goal is to track down all consumers of base1/patternfly.css, and help them with the conversion. This is what we have found so far: DONE: - cockpit itself - cockpit-podman - cockpit-ostree - cockpit-certificates PR FILED: - cockpit-composer: https://github.com/osbuild/cockpit-composer/pull/1001 - subscription-manager: https://github.com/candlepin/subscription-manager/pull/2284 - session-recording: https://github.com/Scribery/cockpit-session-recording/pull/56 TODO (I will file issues today): - https://github.com/oamg/leapp/tree/master/cockpit - https://pagure.io/389-ds-base - https://github.com/NethServer/nethserver-cockpit (has no issues, will email maintainer directly) - https://github.com/abbra/cockpit-app-samba-ad (unclear if it's still active) UNAFFECTED (does not use base1/patternfly.css): - https://github.com/fleet-commander/fc-admin - https://github.com/hellcatz/zcash-cli-cockpit If you are aware of any other project, please speak up, and we are happy to help you. We aim for dropping this API for RHEL 9 (that's pretty firm), and Fedora 34. Thank you! Martin [1] https://cockpit-project.org/guide/latest/api-base1-patternfly.html [2] So that we could do the migration to PF4 step by step, instead of a single insurmountable step) [3] We try hard to not have any long-standing customizations. Most of them are PatternFly bug fixes which we forwarded upstream, it just always takes a bit until they get released. [4] https://github.com/cockpit-project/starter-kit/commit/96514e279e540c [5] https://github.com/cockpit-project/cockpit-podman/commit/86fa1ee8b84

1 0

Cockpit 222 released
by Martin Pitt 24 Jun '20

24 Jun '20

Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from version 222: https://cockpit-project.org/blog/cockpit-222.html Summary: - Logs: More flexible text filters - Services, Dashboard: Hide some buttons when access is limited - Webserver: Lock down cockpit.service privileges You can get Cockpit here: http://cockpit-project.org/running.html Cockpit 222 is available in Fedora 31 and 32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f6114a1e30 https://bodhi.fedoraproject.org/updates/FEDORA-2020-0318da8e1f Or download the tarball here: https://github.com/cockpit-project/cockpit/releases/tag/222 Take care, Martin Pitt

1 0

Questions regarding addition of our own Cockpit module
by Dinesh Prasanth Moluguwan Krishnamoorthy 22 Jun '20

22 Jun '20

Hello team, I’m part of Dogtag PKI open-source project [1]. Our team strives to provide enterprise-class open-source Public Key Infrastructure (PKI) [2]. Dogtag PKI server is a Java web application running on Tomcat. Currently, we have a stand-alone Java AWT client tool called pkiconsole to access PKI services on the server. PKI users are authenticated using client certificates stored in LDAP. These users only exist in LDAP, they are not users on the host itself. We are trying to convert pkiconsole into a web application. We had a chance to look at Cockpit from a very high-level and have some questions. I’m reaching out to the members of the Cockpit team, before we could make a concrete decision on whether Cockpit is a perfect choice for us. The questions are: 1. According to [3] Cockpit seems to require the host to join the IdM domain in order to authenticate PKI users into Cockpit using client cert auth. Is it possible to use client cert auth without joining a domain? Will that require major changes in Cockpit? 2. Suppose the user has been authenticated into Cockpit using a client cert as described in #1, is it possible for Cockpit to use the same client certificate auth to access PKI server? Or do we need to use a different auth mechanism? Regards, The PKI Team [1] https://github.com/dogtagpki/pki [2] https://www.dogtagpki.org/wiki/PKI_Main_Page [3] https://cockpit-project.org/guide/latest/cert-authentication

4 4

Cockpit 221 released
by Martin Pitt 15 Jun '20

15 Jun '20

Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from version 221: https://cockpit-project.org/blog/cockpit-221.html Summary: - Support for Cross-Origin-Resource-Policy - Accounts: Some buttons are hidden when access is limited - Developers: Importing "base1/patternfly.css" is deprecated You can get Cockpit here: http://cockpit-project.org/running.html Cockpit 221 is available in Fedora 31 and 32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-983ae499fa https://bodhi.fedoraproject.org/updates/FEDORA-2020-9c0127be8c Or download the tarball here: https://github.com/cockpit-project/cockpit/releases/tag/221 Take care, Martin Pitt

1 0

Permission Denied Error in test/check-application from inside Container
by Justin Stephenson 04 Jun '20

04 Jun '20

Hi Cockpit team, We have been making some changes and additions to our tests in cockpit-session-recording upstream, sometimes this causes our downstream OSCI-Gating tests to fail however. I would like to spin up a RHEL 8 VM and attempt to replicate the OSCI test run to enable quicker troubleshooting of downstream test runs. I'm assuming that is possible without the complete ansible/standard-test-roles setup so I recently installed the latest RHEL-8.3 nightly compose ISO into a VM, and now I am attempting to run our tests[1]. This is giving me permission denied and timing out when attempting to connect from inside the container to the host [2]. I tried disabling SELinux but no luck with that attempt either. I wonder if someone has seen this problem, or may know how to workaround this issue. [1] https://src.osci.redhat.com/rpms/cockpit-session-recording/blob/rhel-8.3.0/… [2] http://pastebin.test.redhat.com/870598 Thank you in advance. -Justin

2 2

Impending change for developers: $TEST_DATA is going away, better default image caching
by Martin Pitt 04 Jun '20

04 Jun '20

Hello fellow Cockpit developers, Cockpit's test machinery currently supports an environment variable `$TEST_DATA` which on the developer side is commonly used to put downloaded VM images into a specific path. If you don't specify it (nor the cockpit.bots.images-data-dir git config variable), then images are put into the project checkout, which is impractical: 1) development often requires `git clean -fdx` and such, which would kill your downloaded images 2) developers often have multiple checkouts, which don't share downloaded images $TEST_DATA was also used by our CI, which also is problematic as it was being used by far more than downloaded images. As this cannot be salvaged cleanly, I sent https://github.com/cockpit-project/bots/pull/943 to eliminate it completely. Once this lands, you have to do some actions on your machine to adjust, to avoid having to re-download the images: If you don't use $TEST_DATA, nor set the git config: Create ~/.cache/cockpit-images/, and move your images from bots/images/*.qcow2 to there If you set `$TEST_DATA`: Create ~/.cache/cockpit-images/, and move your images from $TEST_DATA/images/*.qcow2 to there. Afterwards, clean up the other stuff, as that is not needed: `rm -r `$TEST_DATA`. Edit your ~/.bashrc (or wherever) to undefine it. If you set cockpit.bots.images-data-dir: No action necessary, this continues to override the ~/.cache/cockpit-images default. However, you may still want to move images to the standard directory and eliminate the git config setting for simplicity. After that, cockpit testing DTRT by default: Downloaded images go to ~/.cache/cockpit-images/ and are shared between checkouts, and truly temporary files (overlays, locks, etc.) go to tmp/ or ./tmp/, and the github cache goes to ~/.cache/github/. Please let me know if you have questions or concerns -- ideally, follow up on the pull request, but discussing it here is also fine, of course. Thanks! Martin

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

cockpit-devel June 2020