On 02.04.20 12:02, Martin Pitt wrote: > Hello Yedidyah, > > 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.
Hmmm. I don't understand why we would do that. The security exectation is that any UI (such as GNOME or Windows) where a terminal and/or browser are shown have a lock screen. Why would each session in a terminal or browser need to implement locking themselves? And even if so, why would it be a default? Can we make Cockpit no log out by default, while still providing the option to configure it? Stef > 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 > their laptops. > >>> The engine-setup process should not depend on cockpit session being around. >>> 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 >> does 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 > [1], and when the page loads it checks if there is an already running update > [2]. > > [1] > https://github.com/cockpit-project/cockpit/blob/master/pkg/packagekit/updates.jsx#L760 > [2] > https://github.com/cockpit-project/cockpit/blob/master/pkg/packagekit/updates.jsx#L536 > >> That runs a long-running command, saves its output somewhere, and if being >> 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 the > 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 > the above. > >> Actually, when we opened it, things were more complex - our long- running >> 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 also to >> 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 :) > > Thanks! > > Martin > _______________________________________________ > cockpit-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > _______________________________________________ cockpit-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
