20/11/12 16:02, Lukasz Dobrogowski wrote:
> Hello there,
>
> today I stumbled upon
> https://tails.boum.org/todo/remember_installed_packages/ and decided I'd
> like to try my hand at the problem.
Awesome! :)
> So, according to the current todo page, there are proposed 2 approaches
> to the persistent packages problem:
>
> 1. an applet asking about installation of cached apt packages upon
> login, probably by looking at stored *.deb files.
> 2. writing down the autoinstall package list in a configuration file
> alike to live-persistence.conf, or even in it itself, and install them
> upon booting without user interaction.
>
> I have to say that the 2nd idea appeals to me much more, since the goal
> of server edition is to make the system bootable with as little
> interaction as possible.
Approach 1 (well, some kind of GUI approach) and 2 are not mutually
exclusive. For instance, the applet described in 1 could generate the
list described in 2. That would actually fit nicely with how we're
currently thinking about implementing Tails Server Edition: if you want
to re-configure it, you boot it in a graphical mode with X starting +
GUIs (like 1) that will save the configurations; if you want to boot it
in server mode, it won't start X, it will just set up services defined
in existing configurations (like 2).
Another thing to think about for 2 is whether the list would contain
only the "leaf" packages, or if it also would have to list all dependencies.
> To be honest, I can't think of many use cases
> that would require disabling different packages you installed on your
> persistent volume every boot.
I think the question is more about making it easy (= user-friendly) to
manipulate the list of packages to install in the first place. And for
that I believe a GUI is necessary.
> As I see it, that's the only flexibility lost by 2nd solution compared
> to the 1st one.
Flexibility, perhaps, but what about usability? A GUI wins for people
uncomfortable with adding arcane package names into a file, and these
are part of Tails target audience.
> Also, there is this point: "The security implications of this whole idea
> needs to be researched before diving in the code.". I am afraid I am
> unable to research this to deeply... since the cached APT packages are
> hand picked by the user, security will depend on these packages and
> security of the persistent volume where the *.deb are going to be
> stored. Am I missing something here?
Perhaps not... :)
I think we need to make you conclusion above part of the design and
security model, i.e. it's up to which packages the user installs. Us
investigating every package and black-list ones that e.g. screws up the
firewall isn't sustainable. We would of course document some general
guidelines about which type of packages that could be risky to install.
> As for the sources of packages (persistence cache / web mirrors) the
> only sensible way is IMHO to use the cached versions, since we can't
> assume internet connection.
That depends on when the packages are to be installed. But I tend to
agree that it'd be best if this happened before GNOME etc. starts, and
then you're correct about us being able to assume an Internet connection.
> To make sure the packages are updated, a
> mechanism to check for updates once internet connection is available
> could be put in place. (something similar to the one launching the Tor
> Browser Bundle only after WLAN connection is successful)
You mean something like running `apt-get upgrade $LIST_OF_APPS`? Sounds
ok. The upgrade list presented by apt-get should be parsed and displayed
in some GUI, though. Or maybe existing apt upgrading GUIs can be used?
Can they be limited to only deal with a subset of installed packages?
> I was warned that I should ask for opinion before delving into code, so:
> what do you think?
Let's wait for some more input. In general I think you need to think
more about GUIs so this feature in the end can benefit non-experts.
However, implementing just 2 first (hence only making this available to
advanced users) and waiting with the GUI + upgrade support would be a
good and natural first step. But there's still some thinking left to be
done on that level too.
Cheers!
