Suggestion for changing cockpit default session timeout
by Gal Zaidman
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
3 years, 10 months
Cockpit on smaller sysems (OpenWRT, QNAP,
and other embedded Linux systems)
by Bernd Wechner
I see cockpit is available on all the major Linux distros. And I love having the overview in a cokjpit of all my systems.
That set does include an OpenWRT router and a QNAP NAS, both of which are smaller stripped down embedded Linux systems if you will which use the opkg package manager:
https://en.wikipedia.org/wiki/Opkg
These systems have web interfaces already (OPenWRT typically under lighttpd and QNAP use Apache) but methinks cockpit is independent of these running it's own web service (cockpit-ws).
Like the Pi these are typically ARM based machines and it's even plausible that the Pi build runs on them, but they don't typically have developement tools on them by default for building (compiling and linking) software locally.
Anyhow, I thought I'd ask if anyone has considered this, as it would rock to see the gateway router on the list of servers overseen and the NAS.
4 years
Installing the latest version
by Bernd Wechner
I just installed an Ubuntu 20.04 server. Then cockipt. And it looked way different to what I have elsewhere. So I checked versions. And sure enough on Ubuntu 20.04 we ghave:
Version: 215-1
and on our other systems:
Version: 164-1
Now it's not unusual for the repos to have different versions like this but it's usually due to lag in getting updates into repos. For which reason many packages maintain a PPA (Personal Package Archive) which a project can push latest version too without waiting on downstream approvals.
As I'd love to see all my system looking similar and have the latest all round, is there a way to install the latest version that I'm not seeing documented, that does not rely on the Ubuntu repos to absorb them?
4 years
Unable to connect to cockpit
by Parth Dhanjal
Hey!
I have a remote machine on which I have installed RHVH4.4
I'm unable to access the cockpit-plugin.
journalctl -u cockpit returns this error
cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Screenshot while trying to reach cockpit through the browser attached.
Is anyone else facing this issue as well?
And does anyone has a solution/workaround to this?
4 years
Kubernetes exec protocol
by Marc Boorshtein
All,
I'm adding websockets support to kubectl for exec and port forwarding. I
have some simple POCs working but am trying to now integrate it into
client-go & kubectl and have some questions on how their different
protocols are differentiated. Looking at
https://github.com/kubernetes-ui/container-terminal/blob/master/container...
i
see how you're integrating with the terminal resize but I don't see how
yuo're telling the api server which of the four protocols to use. If
anyone here has worked on this code and can point me in the right direction
I'd really appreciate it.
Thanks
Marc Boorshtein
4 years
