Hi!
Here are the release notes from Cockpit 337, cockpit-machines 330,
cockpit-ostree version 208, cockpit-podman 107, and cockpit-files 19:
https://cockpit-project.org/blog/cockpit-337.html
This big news this time is the upgrade to Patternfly 6 across the board.
Enjoy!
Attention: Please don't respond to this mail, but to the GitHub discussion
mentioned below.
Hello all,
the Cockpit team is currently investigating a redesign of Cockpit's web server,
which becomes slowly but surely more pressing. See [1] for details if you are
interested. A very interesting possibility is to replace much of it with a web
service worker [2], which would allow us to make the architecture dramatically
simpler, more robust, and more secure (see prototype[3]).
The main concern with this approach is that web service workers don't work with
unknown TLS certificates ("secure context"), in particular for the self-signed
certificates that cockpit creates on startup if you didn't supply your own.
I. e. they don't support the usual TOFU model with "click here to accept this
unknown certificate anyway" that browsers show for "normal" web pages in this
case.
So I would like to do a little survey and request for comments about
deprecating or changing the handling of self-signed TLS certs in Cockpit. This
is an annoyingly hard problem: On one hand we really want to build a world
where TLS works and your services are trustworthy (*especially* if you are
typing in your root password as the next thing!), but for many home or even
small business situations even LetsEncrypt etc. is impractical/impossible (no
DNS, etc.). My questions:
* Are you currently accessing Cockpit with the builtin fallback self-signed
certificate?
* If so, would you have a better option like getting a proper cert, or joining
the machine to a FreeIPA domain (which requests a valid cert from the IPA
server), or running Cockpit behind a reverse proxy which already has a
proper certificate? Or using the Cockpit Client flatpak?
If any of these don't work for you, can you describe your situation?
* If the above isn't possible, could you live with running the cockpit web
server on a machine which has proper TLS setup, and connect to your target
machines with SSH?
* As last resort, Cockpit could show an error page (after accepting the
invalid certificate in the browser) which explains the situation and offers
you to download the CA certificate for importing into your browser as
trusted CA. This includes the case that the default self-signed certificate
is not valid for the hostname you are using to connect to cockpit (i.e. not
"localhost" or the server's unqualified host name) - then you need
to regenerate the certificate with the additional name.
This could then be used to actually establish some trust to the certificate,
by something like `ssh remote cockpit-show-cert` which would show you the
fingerprint or similar -- then you have something actually meaningful to
check in the browser.
Would that be acceptable for you?
* Are you working on a different web-based project and already have some experience
with handling proper certificates?
Notes:
* This only affects remote connections -- if you connect to your own machine
on http://localhost:9090, you can use unencrypted HTTP and service workers
are fine.
* We are aware of and use `sscg` if it's installed (cockpkit-ws.rpm
Recommends: it). We can change the non-sscg fallback to also create a
separate CA and cert, instead of the single self-signed cert. So that's not
a problem, just a bit of work.
Please respond on https://github.com/cockpit-project/cockpit/discussions/21695
to keep the responses in one place -- this annoucement goes to several mailing
lists.
Thank you!
Martin
[1] https://issues.redhat.com/projects/COCKPIT/issues/COCKPIT-1238
[2] https://developer.mozilla.org/de/docs/Web/API/Service_Worker_API
[3] https://issues.redhat.com/browse/COCKPIT-1240
Hi!
Cockpit is the modern Linux admin interface. We release regularly.
Here are the release notes from Cockpit 334, Cockpit Machines 328,
Cockpit Podman 101, and Cockpit Files 17:
https://cockpit-project.org/blog/cockpit-334.html
Summary:
- Files: Apple-compatible keyboard shortcuts
Enjoy!
Hello all,
three months ago, Firefox announced [1] that they are dropping support for the
Chrome Devtools Protocol, the browser automation protocol that we have used in
Cockpit's test API for many years. This finally happened in Firefox 129 [2],
which just recently made it into Fedora 40.
The new thing to use is "Webdriver BiDi" [3], which is finally a standardized
protocol that has all of Chromium/Firefox/Safari/Webkit behind it. I recently
ported Cockpit's test API to that [4] and I'm now in the process of updating
our auxiliary projects like cockpit-{podman,machines,ostree} to it. There had
to be a few API changes, but for the most part this should be painless -- e.g.
starter-kit [5] or c-podman [6] were outright trivial (the "glob" change is
unrelated), and for e.g. c-machines [7] it only requires a little API
adjustment.
You will automatically get this if you update to the latest cockpit pkg/lib and
test/common API. You can then drop the chrome-remote-protocol NPM dependency.
If you run into any trouble, please don't hesitate to ping me -- chances are
very high that I've run into a similar problem already. Best is to
@martinpitt me in GitHub for having appropriate context, but you can also
ask me on Matrix or reply here.
This is relatively urgent if you test on Firefox -- the next time we refresh
our cockpit/tasks container (which runs our CI), it will pick up Firefox 129.
Of course projects can pin the tasks container (.cockpit-ci/container), but not
all of them do.
Thanks,
Martin
[1] https://fxdx.dev/deprecating-cdp-support-in-firefox-embracing-the-future-wi…
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/129
[3] https://w3c.github.io/webdriver-bidi/
[4] https://github.com/cockpit-project/cockpit/pull/20832
[5] https://github.com/cockpit-project/starter-kit/pull/949
[6] https://github.com/cockpit-project/cockpit-podman/pull/1819
[7] https://github.com/cockpit-project/cockpit-machines/pull/1761
Hi!
Cockpit is the modern Linux admin interface. We release regularly.
Here are the release notes from Cockpit version 322 and cockpit-files 5:
https://cockpit-project.org/blog/cockpit-322.html
Summary:
- Shell: Deprecate host switching
- Files: Permissions column in details view
Hello Cockpiteers,
Is anyone using https://github.com/cockpit-project/cockpit-certificates and
interesting in taking over its development and maintenance? From the cockpit
team's PoV it is rather abandoned, nobody uses it or is interested in it, and
we have too much to do and need to shed some load.
It's not currently packaged in any distribution. It currently works, we've kept
it on life support with CI and dependabot and such, but it hasn't seen any real
development in a long time.
If you are interested, please let us know -- we can transfer it to a different
user/org, or you maintain it through PRs and we help with reviewing etc.
If nobody is interested, we'll archive the repository in two weeks.
Thanks,
Martin
Hello all,
Is anyone using https://github.com/cockpit-project/cockpit-certificates and
interested in taking over development/maintenance?
This never made it into any distribution or even an official upstream release,
we have too much to do in Red Hat's Cockpit team, and we need to shed some
load. It's not much (mostly keeping up with dependabot and cockpit lib
changes), but every bit helps.
We are going to archive the repository in a weeks if nobody else is interested
in it.
Thanks,
Martin
Hi!
Cockpit 310 and cockpit-machines 306 have been released, with
improvements to btrfs support, support for external snapshots of VMs,
support for migrating a VM away from SPICE, and other things.
More details as usual in the release notes:
https://cockpit-project.org/blog/cockpit-310.html
Enjoy!
Another wonderful "Wednesday", and another set of releases!
- cockpit 309
- cockpit-machines 305
- cockpit-podman 83
- cockpit-ostree 199
The big mention this time around is that Cockpit itself gained support
for btrfs (including manipulating subvolumes) in the storage page.
There are bug fixes all around (including some important ones in
cockpit-machines) and the usual library and translation updates.
The release announcement and the download links are in the usual place:
https://cockpit-project.org/blog/cockpit-309.html
Until next time — keep your stick on the ice,
lis