Tails

#7 Updated by huertanix 2018-02-20 20:53:01

huertanix wrote:
> If there is a way to remove the need to restart, that would vastly improve the experience of creating persistent volumes and keep people from becoming frustrated when they create a persistent volume, set up a bunch of things, then restart only to see that they have to go through it all over again.

Note that even with messaging around the need for a reboot after setting up persistence, we still now see many users in training making the mistake of thinking persistence is active and ready as soon as they finish the initial configuration before rebooting. 100% of the users I train come from a Windows and Mac background where when they see macOS or Windows tell them “you need to reboot” they don’t and experience no consequence and thus, are conditioned to ignore reboot notices unless they’re forced to by someone from tech support.

#12 Updated by intrigeri 2019-01-23 10:32:59

The cheapest possible fix (from a dev perspective) would probably be to lock down the system once persistence is set up, i.e. effectively force users to reboot.

Regarding enabling persistence immediately, that should be doable but:

• It’ll go wrong at least for files that are already open, e.g. if a Pidgin account is started already, we might copy the corresponding files to persistence (and get them back on next boot), but any further change in the Pidgin UI won’t persist. That would create quite confusing UX.
• IIRC some of our session initialization is done differently depending on whether persistence is enabled or not (e.g. the GNOME bookmarks). All this code would need to support being re-triggered and do the right thing when run a 2nd time. Otherwise the user will be left in a session that’s of a 3rd kind, somewhere in between “no persistence unlocked” and “persistence unlocked”, which may be confusing from a UX perspective (once we remove the need to reboot, one would expect the session to of the “persistence unlocked” kind) and increase our maintenance costs (more complex state machine).

I might be overly pessimistic but I’m worried that we won’t do a good enough job at this and we’ll end up setting user expectations we can’t be up to, which would result in poor UX too (probably better than the current state of things, but the marginal UX improvement might not be worth the dev cost).

So at this point I’m very much tempted to lower our ambitions here and only force the user to reboot.

#16 Updated by segfault 2019-04-27 23:32:21

I really want this feature. Mostly because of the very painful UX issue reported by sajolida and huertanix, which often results in accounts/PGP keys etc. being lost (I witnessed this myself multiple times).

But also because now that we have the USB image, IMO having to reboot after setting up persistence is the biggest remaining UX issue we have during setup of a new Tails device. And the setup is the first thing a new user experiences, so IMO we should really give our best to make this a nice experience.

intrigeri wrote:
> Regarding enabling persistence immediately, that should be doable but:
>
> * It’ll go wrong at least for files that are already open, e.g. if a Pidgin account is started already, we might copy the corresponding files to persistence (and get them back on next boot), but any further change in the Pidgin UI won’t persist. That would create quite confusing UX.

We could run a pgrep thunderbird pidgin ... command before starting the persistence setup and ask the user to close all the applications we found a process for.

> * IIRC some of our session initialization is done differently depending on whether persistence is enabled or not (e.g. the GNOME bookmarks). All this code would need to support being re-triggered and do the right thing when run a 2nd time.

Agreed. But how much code is this really? Right now I can only find two places where the persistence_is_enabled* functions from config/chroot_local-includes/usr/local/lib/tails-shell-library/tails-greeter.sh are used:

config/chroot_local-includes/usr/local/lib/add-GNOME-bookmarks

and

config/chroot_local-includes/usr/local/lib/create-tor-browser-directories.

And re-running these after enabling persistence is enough to get into the same state as when booting with persistence. Also, both of these already have a systemd service, so I think we could just create a new unit tails-persistence-is-enabled.target which wants the other two services so we have these dependencies nicely encoded.

I would like to prepare a branch for that.

#17 Updated by segfault 2019-04-28 01:47:54

I got enthusiastic and started working on this, so I’m posting some findings below, but I know that we still have finish the discussion about whether it’s worth to do this at all.

When the persistent partition was just created, the device name of the unlocked volume is different than when the volume was unlocked later. In the first case, the name is luks-$UUID, in the latter TailsData_unlocked.

live-boot uses the same name for the mountpoint under /live/persistence, which has to be /live/persistence/TailsData_unlocked, we use that path everywhere.

My first idea was to set the name in /etc/crypttab, which is honored by udisks when unlocking an encrypted volume, but unfortunately, that’s not the case when the volume is unlocked as part of Format. I’m thinking about preparing a patch for upstream to fix that (or at least reporting it).

A workaround I found is to use dmsetup rename to rename the device to TailsData_unlocked. After that, live-persist activate works.

#18 Updated by intrigeri 2019-04-28 08:25:35

segfault, I’m glad you’re working on this! It’ll be useful to estimate the actual cost of fixing this problem. Feel free to clock the cheapest prototype you can build as FT work. If you hit stumbling blocks that can’t be addressed cheaply, let’s talk :)

#19 Updated by intrigeri 2019-04-28 09:24:31

In passing, as a side-effect, other advantages of fixing this: make our test suite faster; make most persistence-related dev/doc/UX work easier, more enjoyable, and cheaper.

#23 Updated by intrigeri 2019-04-29 13:28:13

> Another thing that’s missing is that settings which were disabled are also unmounted.

The discussion on Feature #8447 might be relevant.

#25 Updated by segfault 2019-05-12 13:15:30

I’m annoyed that a lot of our configuration is only applied during boot, by live-config, instead of during build.

While working on this ticket, I split some scripts which depend on persistence being set up into two, one for the part which does not depend on persistence and one which does. I would like to make the parts which does not depend on persistence build hooks (i.e. move them to config/chroot_local-hooks), so that we don’t have to create additional systemd services to run them. But I can’t do that because they have to create files as the amnesia user, which is only created by live-config during boot.

I took a look at the journal of a booted Tails and it seems like the whole live-config stuff takes about 15 seconds during boot. I think most of the configuration could be done at build time, which would make things easier and reduce the boot time. What’s the reason why things like creating the amnesia user only happen during boot?

#26 Updated by segfault 2019-05-12 17:12:06

I released t-p-s 2.1.1.1-1 with my changes to be able to test it on the feature branch. I hope that’s OK. I wanted to encode in the version number that the release is only intended for Feature #11529, but the release process documentation and dzil build didn’t like any other characters than [0-9.].

#27 Updated by segfault 2019-05-12 18:04:18

segfault wrote:
> I released t-p-s 2.1.1.1-1 with my changes to be able to test it on the feature branch. I hope that’s OK. I wanted to encode in the version number that the release is only intended for Feature #11529, but the release process documentation and dzil build didn’t like any other characters than [0-9.].

I uploaded the package with dput but it doesn’t get installed on my branch and it’s not in incoming/ on incoming.deb.tails.boum.org. But the distribution name (feature-11529-enable-persistence-immediately) was added to conf/distributions. What did I do wrong?

#28 Updated by intrigeri 2019-05-14 12:55:37

> What’s the reason why things like creating the amnesia user only happen during boot?

I think that’s because this is how Debian Live systems generally work.
I don’t know if anything relies on this.

#29 Updated by intrigeri 2019-05-14 12:57:01

> I released t-p-s 2.1.1.1-1 with my changes to be able to test it on the feature branch. I hope that’s OK. I wanted to encode in the version number that the release is only intended for Feature #11529, but the release process documentation and dzil build didn’t like any other characters than [0-9.].

Having non-official releases with official-looking version numbers is a bit problematic, but no big harm done.

Usually I would instead export a diff to tails.git with something like:

(cd lib && git diff --src-prefix=a/usr/share/perl5/ --dst-prefix=b/usr/share/perl5/ --relative=lib master.. . ) > ~/tails/git/config/chroot_local-patches/tps-16568.diff

#30 Updated by intrigeri 2019-05-14 13:00:27

> I uploaded the package with dput but it doesn’t get installed on my branch and it’s not in incoming/ on incoming.deb.tails.boum.org. But the distribution name (feature-11529-enable-persistence-immediately) was added to conf/distributions. What did I do wrong?

I see no trace of a 2.1.1.1-1 upload in the logs. I suggest you retry the upload and check /var/log/incoming-tails.log immediately after your upload seemingly succeeds.

#31 Updated by segfault 2019-05-14 20:51:12

Oh, so apparently I forgot to set the hostname parameter of dput to tails when I uploaded the .changes file. So it was uploaded to the default host, which is ftp.upload.debian.org. I have no idea what the consequences of that are or why I’m even permitted to upload to that server.

I now updated my dput.cf to use the tails section by default.

#32 Updated by segfault 2019-05-14 20:56:40

segfault wrote:
> I now updated my dput.cf to use the tails section by default.

We might want to add that to our “Configuring dput” section on https://tails.boum.org/contribute/APT_repository/custom/ (maybe as a hint for non-Debian Maintainers):

[DEFAULT]
default_host_main = tails

#33 Updated by segfault 2019-05-18 16:46:08

intrigeri wrote:

> Usually I would instead export a diff to tails.git with something like:
>
>

 (cd lib && git diff --src-prefix=a/usr/share/perl5/ --dst-prefix=b/usr/share/perl5/ --relative=lib master.. . ) > ~/tails/git/config/chroot_local-patches/tps-16568.diff

Thanks, I used that now instead of releasing new packages.

I made some progress, on an image built from the feature branch, the persistence is now immediately activated, and all scripts which depend on persistence are automatically run after the persistence is activated.

What’s missing is the check for running applications. I started to work on this, but IMO the right place to do this is in t-p-s, and I don’t have the skills to implement that in perl.

#34 Updated by segfault 2019-05-18 16:58:39

> What’s missing is the check for running applications. I started to work on this, but IMO the right place to do this is in t-p-s, and I don’t have the skills to implement that in perl.

Here is what I had planned, but failed to implement:

1. Have a list of process names + corresponding app names per persistent setting
2. Before applying a new persistence config, get a list of all changed settings
3. Check if any affected processes are running
4. Ask the user to close all affected apps before retrying
5. Repeat until no affected processes are running
6. Apply new persistence config and run `live-persist activate`

#35 Updated by segfault 2019-05-18 17:00:21

Something else that’s missing is an updated design documentation (https://tails.boum.org/contribute/design/persistence/)

#36 Updated by segfault 2019-05-18 18:55:38

And tests are missing too.

#37 Updated by intrigeri 2019-05-19 06:22:39

> Oh, so apparently I forgot to set the hostname parameter of dput to tails when I uploaded the .changes file. So it was uploaded to the default host, which is ftp.upload.debian.org.

Ah ah :)

> I have no idea what the consequences of that are

@segfault, I hope this gets cleaned up automatically and no ftp-master had to do it by hand. You could check if your upload is still in the queue there. Also, one can use dcut to cancel an upload.

> why I’m even permitted to upload to that server.

It’s an anonymous FTP upload server. What matters is the OpenPGP signatures, not access control to the upload server.

#38 Updated by intrigeri 2019-06-01 13:12:03

> We might want to add that to our “Configuring dput” section on https://tails.boum.org/contribute/APT_repository/custom/ (maybe as a hint for non-Debian Maintainers):

>

> [DEFAULT]
> default_host_main = tails
> 

@segfault, please go ahead and point me to the corresponding commit once you’ve pushed to master; happy to review this after the fact.

#39 Updated by segfault 2019-06-01 20:18:07

intrigeri wrote:
> > We might want to add that to our “Configuring dput” section on https://tails.boum.org/contribute/APT_repository/custom/ (maybe as a hint for non-Debian Maintainers):
>
> > […]
>
> @segfault, please go ahead and point me to the corresponding commit once you’ve pushed to master; happy to review this after the fact.

Done in d2b8facfbb81e2db12d3206a52df5ba3158a1415.

#40 Updated by intrigeri 2019-06-02 09:45:52

>> @segfault, please go ahead and point me to the corresponding commit once you’ve pushed to master; happy to review this after the fact.

> Done in d2b8facfbb81e2db12d3206a52df5ba3158a1415.

Great!