Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Start updater at boot, remove existing svs-disp backgound updater #415

Closed
emkll opened this issue Jan 22, 2020 · 3 comments · Fixed by #470
Closed

Start updater at boot, remove existing svs-disp backgound updater #415

emkll opened this issue Jan 22, 2020 · 3 comments · Fixed by #470

Comments

@emkll
Copy link
Contributor

emkll commented Jan 22, 2020

In #396, we have introduced a launcher to provide a way for users to control the update process. We would like the checks to happen as soon as the system boots to desktop.

We should re-use the autostart logic provided in [1] by replacing the background dispvm template update script (securedrop-login) by the QT application introduced in #396

[1] https://github.com/freedomofpress/securedrop-workstation/pull/355/files#diff-19fc9e35327834b65d0d380e0da1a89bR19

@eloquence
Copy link
Member

eloquence commented Jan 22, 2020

This could be split into three iterations:

  • first iteration: remove securedrop-login
  • second iteration: launch preflight updater upon login
  • third iteration: ensure that only one updater can be launched

@eloquence
Copy link
Member

Regarding launching the preflight updater upon login, I admit to being somewhat ambivalent. Having two dueling paths to launch the app (login & desktop icon) could be confusing, and having the client login window pop up in every session feels a bit constraining for future use cases that may be independent of the client app.

That said, since it's best to ensure that the workstation is up-to-date regardless of what the user does with it, I agree this is the way to go at this time. Adding the first two iterations to the sprint.

@eloquence
Copy link
Member

eloquence commented Feb 13, 2020

third iteration: ensure that only one updater can be launched

This was actually done in #445. We don't check whether the client itself is running, which could be a good follow-up. The client does have its own "only one at a time" check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants