segfault:
> sajolida:
>> segfault:
>>> sajolida:
>>>> 7. Regarding toggling "Persistent" on and off. To simplify things, and
>>>> as anonym pointed out, I would:
>>>>
>>>> - Prevent switching it off if the service is started already.
>>>>
>>>> - Maybe allow switching it on if the service is started already as
>>>> suggested by George. But maybe it's good enough to keep this as a
>>>> future improvement.
>>>>
>>>> - Propose to erase all data related to the service when switching off.
>>>> This is a problem we have with persistence features in general,
>>>> see #8447. But since we're designing something new here, let's not
>>>> duplicate this problem elsewhere.
>>>
>>> I spent some time thinking about anonym's comment on this one. I tried
>>> it with the mumble server and at least with this one it worked perfectly
>>> if I simply moved the config file to the persistence storage when making
>>> it persistent and removing the link and moving the config file back in
>>> place when removing the persistence, without ever restarting the service.
>>>
>>> By the way, I think at least copying the files to the persistence
>>> storage and mounting the persistent directory should also be implemented
>>> in the current persistence assistant. This would remove the necessitiy
>>> of a reboot before the persistence is applied. I witnessed multiple
>>> times that users forgot this reboot while setting up a new Tails device
>>> and they lost they're newly created mail address and PGP keys because
>>> they were not stored persistently.
>>
>> Yeah, I'm aware of this issue and I think it's quite bad. You should
>> chat about this with intrigeri :)
Or with me, since I implemented these back-end bits. :)
For the record, `/usr/local/sbin/live-persist activate` will (I think)
enable any new persistence options added to persistence.conf immediately
(provided that persistence was already enabled, otherwise it will ask
for a passphrase, and I don't think we want to reimplement that part of
Tails Greeter -- conclusion: persitence must be enabled to even have the
option to mark something persistent in Tails server). So at least we
have that for free now. Note that this includes sourcing the persistence
"backing dir" (the on stored on the persistent media) with any files
present in the target directory.
However, I must warn you that what you want to achieve is not easy to do
safely in the general case, mostly since some of our non-Tails server
persistence options affects applications that are already running (e.g.
NetworkManager). So, if we are ever going to implement this for
non-Tails server persistence options, we'd need to investigate each of
them and see if it is reasonable at all, and then probably have a check
that makes sure that the affected application(s) are not running, and
then it enables it live.
But for Tails server's persistence options we won't have this problem,
so I think it should be possible. However, to make things simple, I
strongly suggest that we only allow setting persistence on/off while
adding a service. This would also solve...
>>> But I see that this replacement of config files might cause problems
>>> with other services, so I agree that disabling the persistence switch
>>> while the service is running would be the safest and easiest way.
>>
>> Right, Mumble doesn't rely so much on the files in the file system
>> evolving as the service runs but what would happen for an Etherpad
>> service or a Gobby maybe storing content locally, for example?
... this class of issues, and...
>> I would be very happy if we can find a generic solution that works for
>> every possible service and I don't mind experimenting with it, but we
>> probably anyway need some safe behavior as a fallback.
... work for this.
KISS!
>>>> 8. I'm not 100% convinced by the onion address in the text box but I
>>>> understand your arguments and I'm fine trying it this way.
I'm not sure I agree with the argument. Many of the services we are
considering are useless without the extra info. Not sure if I care
enough to argue for this though.
>>>> 10. Also, I feel like we need to clarify what is the workflow of
>>>> configuring and starting a service. Especially since here we have an
>>>> on/off toggle that can be manipulated independently of the settings button:
>>>>
>>>> - As anonym pointed out, some settings would require restarting the
>>>> service.
>>>>
>>>> - What if a service always requires some configuration before being
>>>> started? For example the password of a Mumble server? Would it work
>>>> to display the settings dialog when toggling on if some settings
>>>> are required?
>>>
>>> I think with Spencer's design we could open a dialog when a new service
>>> is set up with the + sign.
>>
>> I'm not sure about the use of the + sign on Spencer's design.
>> I see two options:
>>
>> A: Plug sign to add a service. By default the list is empty, you click
>> on + to display a list of services and choose one to add it to the list.
>> The disadvantage I see with this is that we need a different and
>> separate dialog for the "list of options". It might also be more
>> annoying for ephemeral services that will always disappear from the list
>> on each reboot. But on the other hand, this seems a more common pattern
>> in the examples I gave from GNOME Settings.
>>
>> B: Display all possible services upfront. The list is already full with
>> all the possible services and the state of each service ("On"/"Off" and
>> "Persistent"/"Ephemeral") is translated by some graphical element in the
>> list. The advantage is that we have only one dialog. The disadvantage is
>> that it might be harder to depict the state of each service and if the
>> list of services gets long the whole thing will get noisy.
>
> I understood the + sign like you described it in A. I don't think the
> additional dialog is very annoying. This way it is clear which services
> are configured and ready to use.
Fully agreed with A (and that was indeed my interpretation). Let's not
always show a lot of useless info, which all inactive services will be
once a user has set up the ones it cares about.
>>>> Maybe in the back end we need to know for each setting if it is required
>>>> on start and if it requires restarting the service if changed.
>>>
>>> Indeed, I think we should create a "RequiresRestart" attribute in the
>>> TailsOptions class. All options which have this set to True would then
>>> be disabled in the GUI (and refuse modification through the CLI) while
>>> the service is running.
>>
>> Yes. Note that I was talking about "each setting" (and not "each
>> service"). Maybe some services allow some settings to be changed on the
>> fly and some other settings to restart. But if you want to simplify and
>> treat the service as a whole as "RequiresRestart" that's fine with me :)
>
> I was also talking about each setting / option, I proposed to add this
> in the TailsOptions class. But I left this out for now. The support of
> "on the fly" options could be future work and they could probably be
> configurable directly in the status panel.
GNOME likes the approach where a configuration change leads to immediate
action, but that could be a bit awkward, perhaps, with services that
require a full restart (which will break existing connections, for
instance).
Perhaps it'd make sense to immediately write the config changes to file,
but (for RequiresRestart options) show a status somewhere saying "The
options won't apply until you restart the service"? Of course, then we'd
have an inconsistency in GUI behaviour between different options, which
is confusing, but perhaps the best we can get.
>>>> Now I'm wondering whether this design and the design of the
>>>> current persistence assistant should be consistent or unified
>>>> somehow (as they are both proposing opt-in persistence features). But
>>>> that sounds scary and out-of-scope for now. Maybe your design can later
>>>> on inspire some improvements to the current persistent assistant :)
>>>
>>> I took a look at the code of the current persistence feature and was
>>> scared so much that I scrapped my plan of implementing the mounting of
>>> non-directory files through persistence.conf, although that feature
>>> would come in very handy for the Tails Server.
>>
>> I'm not sure what you mean by "mounting of non-directory files". You
>> mean mounting regular files? Is this Unix? We have the Dotfiles feature
>> that creates symlinks in the right places and that can be used to do
>> crazy stuff.
>
> Yes, I mean mounting regular files. That's Unix and it works just like
> with directories, i.e. "echo "foo" > foo; echo "bar" > bar; sudo mount
> --bind foo bar; cat bar" outputs "foo". I talked with anonym about this
> being a desired feature of the persistence config. My problem with the
> symlink feature is that it requires a directory containing the files on
> the persistence volume. This way I have to create a unique directory on
> the persistence volume for each location I want to make a regular file
> persistent in.
Note that tails-persistence-setup has nothing to do with anything you'll
have to worry about -- it is a GUI and parser for persistence.conf,
essentially. If you want to support persistence in Tails server, you'll
have to implement your own parser. Luckily it's pretty simple, see `man
persistence.conf` (requires the live-boot package).
>> Ah, and I was talking about the design of the graphical assistant (in
>> Perl), not the back end. I really think that you should reuse the
>> syntax, mounting and symlinking mechanism of persistence.conf, probably
>> from a different but similar file.
>
> I thought it would be sufficient to just define a list of files in the
> respective service file (e.g. services/gobby.py) which should be made
> persistent when the persistence option is enabled. Do you think there
> will be situations in which a user wants to make only some files
> persistent (e.g. the gobby config file but not the documents)?
IMHO such splitting comes with a price -- it's confusing. Worth taking
into account, I think.
Cheers!
