Bug 50740 - Send screen lock to clients at regular intervals
Send screen lock to clients at regular intervals
Status: CLOSED FIXED
Product: UCS@school
Classification: Unclassified
Component: UMC - Computer room
UCS@school 4.4
Other Linux
: P5 normal (vote)
: UCS@school 4.4 v4-errata
Assigned To: Ole Schwiegert
Sönke Schwardt-Krummrich
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-01-27 10:06 CET by Ole Schwiegert
Modified: 2020-02-13 21:42 CET (History)
1 user (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted after Product Owner Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ole Schwiegert univentionstaff 2020-01-27 10:06:40 CET
Title:
===
As a teacher, I would like computers that have a screen lock (intentionally) restarted to automatically receive a screen lock again to prevent users from using this to bypass the screen lock.

Description:
===
1. send "lock screen" again at regular time intervals, provided it is still selected in the computer room module
2. is not only relevant in case of intentional misbehaviour but in practice not all iTalc clients always get the "Lock Screen" signal.
3. time intervals configurable via UCR (default: every 5sec)


Release:
===
* As errata

acceptance criteria:
===
* Assuming I'm in the computer room module, lock one computer, then the computer is locked again at regular intervals until I actively unlock it.
* The signal for the new lock is implemented in the UMC module - here the signal is resent by timer. If the UMC module is closed, the signal is not sent any further.
Comment 1 Ole Schwiegert univentionstaff 2020-02-04 10:40:05 CET
The following solution was implemented on oschwieg/4.4/50740:

An interval is started in the browser of the teacher that triggers every x seconds, where x is the value configured in ucsschool/umc/computerroom/screenlock/interval

If the value is <1 the feature is disabled. If unset (default) the value is 5 seconds.

On every interval the following happens: It is checked, if all computers, that are marked as locked, are indeed locked. If that is not the case the UMCP command to trigger the lock is send again.

There are some caveats: If the computers are checked before the new status reached the UMC, a lock signal might be send again, resulting in a flicker on the target system. That should happen very rarely and only in the seconds after initially locking a computer.
In very rare cases it can also happen that a teacher unlocks a computer, but a status update arrives marking it still as locked, which would result in the logic to lock it again.

I did not find a solution yet for these two problems. Both of which can be drastically reduced by increasing the interval time to a sufficent amount.

One proposal: Merge the updateComputers and lockingInterval logic into one (with one UCRV to configure the interval time).

The problem is mentioned in the manual addition for administrators.

Please QA and REOPEN for merge or adaption.
Comment 2 Ole Schwiegert univentionstaff 2020-02-04 10:40:42 CET
The product tests were also modified to include this feature in future checks: https://hutten.knut.univention.de/mediawiki/index.php/Produkttests_UCS@school_4.4_UMC_Module#Computerraum
Comment 3 Ole Schwiegert univentionstaff 2020-02-04 12:10:10 CET
In very rare cases it can also happen that a teacher unlocks a computer, but a status update arrives marking it still as locked, which would result in the logic to lock it again.

-- This was a thought problem on my side. It can logically not happen since the updateRoom function only delivers changes.

Bug can be QA'ed.
Comment 4 Ole Schwiegert univentionstaff 2020-02-10 09:02:57 CET
Package: ucs-school-umc-computerroom
Version: 11.0.0-16A~4.4.0.202002100902
Branch: ucs_4.4-0
Scope: ucs-school-4.4

Can be tested. Automatic test follows asap
Comment 5 Sönke Schwardt-Krummrich univentionstaff 2020-02-10 23:09:57 CET
My findings so far:

1) UCR variable description: s/Type: str/Type: int/

2) Possible inconsistency from user perspective: if the room is changed back and forth or the browser is closed and reopened, the "auto screen lock" is no longer active. This is not transparent to the user.

3) Possible confusion from user perspective: if the same room is opened by the same user in 2 different browser instances and the screens are locked by browser1, any unlock action of browser2 is reverted a short time after by browser1.

4) Currently only screens are automatically relocked; the auto-relock does not apply to input devices.

5) Suggestion for manual section:
Ab Version 4.4v4 prüft das Computerraum-Modul von UCS@school in der Standardeinstellung regelmäßig, ob alle gesperrten Rechner weiterhin noch gesperrt sind,
um z.B. Rechner nach deren Neustart wieder in den gesperrten Zustand zu versetzen.
Das Intervall, in dem die Überprüfung läuft, kann durch die &ucsUCR;-Variable <envar>ucsschool/umc/computerroom/screenlock/interval</envar>
konfiguriert werden. In der Standardkonfiguration wird die Prüfung alle 5 Sekunden durchgeführt. Wird der Wert der Variable auf 0 gesetzt, wird die Prüfung abgeschaltet.
Bei der Verwendung der Rechnersperre ist folgendes zu beachten:
Damit das automatische Wiedersperren von Rechnern funktioniert, darf die UMC zwischen dem Sperren von Rechnern und dem Entsperren der Rechner nicht geschlossen werden und zusätzlich darf innerhalb des Computerraum-Moduls der Raum nicht gewechselt werden.


Besides the items above, it worked for me.
Comment 6 Ole Schwiegert univentionstaff 2020-02-11 08:53:57 CET
To 1.: Will be fixed in the next build

To 2.: This should not be the case. If a teacher opens a computerroom and there are locked screens, the frontend should be notified about that in the updateRoom function (computerroom.js line 1298). Only if the computers are actually not locked anymore a newly opened frontend has no way anymore of knowing if a computer should be locked or not.

To 3.: This problem cannot be fixed to my knowledge. The frontend code in the two browsers are independent of each other. Also both browsers communicate with a separate UMC module process. There is now defined way of these two browser windows to communicate over the status of the computer room other than with the update UMCP command. Since these updates are polling (every 2 seconds per timer) I do not know how we could avoid this problem. The only suitable solution for this I know is real time communication via websockets.

To 4.: The User Story mentioned specifically screen lock and not input lock. I was not aware this should work for the input lock as well in this US.

Too 5.: Will be applied with the next build
Comment 7 Sönke Schwardt-Krummrich univentionstaff 2020-02-11 13:07:20 CET
(In reply to Ole Schwiegert from comment #6)
> To 2.: This should not be the case. If a teacher opens a computerroom and
> there are locked screens, the frontend should be notified about that in the
> updateRoom function (computerroom.js line 1298). Only if the computers are
> actually not locked anymore a newly opened frontend has no way anymore of
> knowing if a computer should be locked or not.

You are right. It worked for me, too. Looks like I tested it yesterday the wrong way. So one problem less.
 
> To 3.: This problem cannot be fixed to my knowledge. The frontend code in
> the two browsers are independent of each other. Also both browsers
> communicate with a separate UMC module process. There is now defined way of
> these two browser windows to communicate over the status of the computer
> room other than with the update UMCP command. Since these updates are
> polling (every 2 seconds per timer) I do not know how we could avoid this
> problem. The only suitable solution for this I know is real time
> communication via websockets.

I think this is only a minor problem in a seldom scenario.

> To 4.: The User Story mentioned specifically screen lock and not input lock.
> I was not aware this should work for the input lock as well in this US.

According to Michel, this is ok for this userstory.
Comment 8 Sönke Schwardt-Krummrich univentionstaff 2020-02-11 13:17:19 CET
REOPEN: the YAML entry is missing
Comment 9 Ole Schwiegert univentionstaff 2020-02-11 15:29:39 CET
Package: ucs-school-umc-computerroom
Version: 11.0.0-17A~4.4.0.202002111527
Branch: ucs_4.4-0
Scope: ucs-school-4.4

UCRV to int
Manual adapted
YAML added
Comment 10 Sönke Schwardt-Krummrich univentionstaff 2020-02-12 10:01:21 CET
(In reply to Ole Schwiegert from comment #9)
> Package: ucs-school-umc-computerroom
> Version: 11.0.0-17A~4.4.0.202002111527
> Branch: ucs_4.4-0
> Scope: ucs-school-4.4
> 
> UCRV to int
> Manual adapted
> YAML added

OK: code change
OK: installation
OK: update
OK: changelog entry
OK: advisory
OK: functional change
OK: package built and installable
Comment 11 Sönke Schwardt-Krummrich univentionstaff 2020-02-13 21:42:36 CET
UCS@school 4.4 v4 has been released.

https://docs.software-univention.de/changelog-ucsschool-4.4v4-de.html

If this error occurs again, please clone this bug.