Yedidyah Bar David [2020-04-01 10:22 +0300]:
I think that the gdm case is different. There, you lock the session,
not logout. Right? If so, after re-entering the password, the admin
has everything back there.
Correct. That should also be the case for cockpit, as pages (should) have no
long-lived state by themselves -- the state that they show is always the system
state. (Of course there's short-lived state like whether an expander is open,
but that's not precious).
Also: Does Red Hat now by default configures sshd to logout sessions
after 15 minutes? If not, what's the difference?
It doesn't, and we can certainly discuss whether to enable it by default. I
will circle back to Steve and check that requirement.
However, that's really mostly unrelated to the actual issue that you are having
-- even if we disable the timeout by default, a page really should not rely on
a cockpit session being constantly connected for a long time. Network
interfaces go down or roam, TCP timeouts happen, browsers crash, tabs get
closed accidentally or get forgotten, batteries drain, people close/suspend
> The engine-setup process should not depend on cockpit session
> It needs to run even when you log out of Cockpit and the user should be
> able to see the running process output when they log back in again.
OK, how? Do you have an example for a cockpit module/plugin/whatever that
Yes, the "Apply software updates" (dnf update) is a very similar case. The
actual operations are done in PackageKit, which is the local separate service
on the target machine that actually does the upgrade. Cockpit just triggers it
, and when the page loads it checks if there is an already running update .
That runs a long-running command, saves its output somewhere, and if
logged out in the middle, allows the user to reconnect, showing everything
since the last part already seen by the user? Does cockpit have means to help
plugin authors do that, without reinventing the wheel every time?
Is "engine-setup" just a control frontend for some local service that does the
actual setup? Then something similar like Software Updates should be possible.
Or is it all a single CLI that needs to run all the time, and will crash if its
terminal goes away? Then a simple way how to "detach" this is systemd-run(1).
You could use a fixed unit name, like `--unit cockpit-ovirt-engine-setup`,
which will give you that:
* On page load, you check if that unit exists, and if so, you can show
"installation in progress" (the "resume" part). If you want to show
previous logs on the page, you can get it with
`journalctl -u cockpit-ovirt-engine-setup`.
* If that unit does not exist, then there's no running install, and you can
start one. You can then stream the output with
`journalctl -u cockpit-ovirt-engine-setup -f`.
If it helps, we can certainly write an example page that does that. There's
nothing else in cockpit or related projects that starts long-running processes,
so I have no existing examples to point to.
Or is engine-setup by and large an Ansible script? Maybe there is some existing
service out there that can run/control playbooks, kind of like a lightweight
Ansible Tower. If not, systemd-run ansible-playbook is just a special case of
Actually, when we opened it, things were more complex - our long-
command could require interaction with the user (via stdin), and our cockpit
plugin provided means to do that. Now we do not need this anymore, so can
probably do this ourselves.
That certainly helps a lot indeed.
But I think it would be useful if cockpit provides means to reconnect
an interactive command. Basically, screen/tmux -style.
systemd can do all the hard work for that already, but we can certainly provide
some helpers for that. This is just the first time ever that we hear about that
demand, so we don't have a pre-made cake yet, sorry :)