[Tails-dev] Rewrite live-persist as part of Persistent Stora…

Supprimer ce message

Répondre à ce message
Auteur: segfault
À: The Tails public development discussion list, sajolida
Sujet: [Tails-dev] Rewrite live-persist as part of Persistent Storage settings rewrite

as part of the rewrite of the Persistent Storage settings (#17803), I
also want to solve #11529 "Save data to Persistence when it is created
(no need to restart)".
The only way I see to solve this while providing a nice UX is to rewrite
part of live-persist (and the live-boot functions uses by it) to allow
activating/deactivating a single persistence feature (that's the term we
want to use instead of "persistence preset" IIUC).

This is the user flow I envision:
* In the Persistent Storage settings GUI, the user clicks on the switch
   of a  persistence feature to  activate/deactivate it.
* The frontend calls the Activate()/Deactivate() method of the feature's
   D-Bus object.
* The backend checks if any processes are running that must not be
   running when changing this feature (for example for the Thunderbird
   persistence feature, no process with executable "/usr/bin/thunderbird"
   or "/usr/lib/thunderbird/thunderbird" must be running).
   * If any such process is running, the backend sends a signal that it's
     waiting for these processes to exit.
   * The frontend receives the signal and displays a message to the user
     that they have to close the corresponding app ("Thunderbird") to
   * Once all conflicting processes have exited, the backend
     automatically continues activating/deactivating the feature.
* The backend mounts/unmounts the files/directories of that feature.
* The backend adds/removes the corresponding line(s) to/from

live-persist is not able to mount/unmount a a single file/directory
instead of the whole persistence.conf. That's why we need to rewrite
part of it.

I plan to do that in bash, copying the parts from live-persist and
live-boot which we need for that.

During boot, we could still use live-persist, or we completely replace
it with the new script (which means that it should also be able to
activate features from a config file).

What do you think about that plan?