16/02/14 03:30, Kill Your TV wrote:
>
> Please pull the updated I2P packages (0.9.11) into the the Tails repo
> for inclusion into Tails v0.23.
Thanks! I'll try to import these shortly.
> Also, if acceptable, please consider merging the following to add
> I2P to the persistence GUI.
>
> http://repo.or.cz/w/tails/kytv.git/shortlog/refs/heads/feature/i2p-persistence
I've had a look. Indeed, adding a preset for I2P is the only thing this
branch does. Here are my remarks:
TL;DR: Just look at section 3 below, which makes a merge of this
doubtful without quite a bit of further effort.
# 1. Which path to make persistent?
This new "I2P router configuration" preset makes the complete
`/var/lib/i2p/` directory persistent. However, the actual I2P router
configuration lives in the `/var/lib/i2p/i2p-config/` sub-directory; are
there reasons to think that other directories can be added in the future
to `/var/lib/i2p/` (possibly by other I2P-related packages) that we not
necessarily want to include in *this* preset (for instance, we may want
separate presets)? Does it make sense to change the preset to only make
`/var/lib/i2p/i2p-config/` persistent?
# 2. Potential future issue: i2psnark and user hosted eepsites
The preset includes
`/var/lib/i2p/i2p-config/{i2psnartk,eepsite/docroot}` and as have been
discussed before in the "Reviewing kytv:feature/i2p-0.9.8.1" thread,
these directories are of interest to the Live user. Currently not even
readable by it except if an administrative password is set, which at
least is documented, but this is nevertheless something we may want to
improve at some point.
I'm not sure exactly what sort of permissions game is suitable for that.
Perhaps something like a symlink `/var/lib/i2p/i2p-config/i2psnark ->
/var/lib/i2psnark`, where `/var/lib/i2p/i2psnark` is readable by the
Live user and read-write for `i2psvc`? That'd also require to change the
permissions of `/var/lib/i2p`, to make it readable by the Live user.
With this setup it'd also make sense to make all of `/var/lib/i2p`
persistent like in your original patch. Note that it would be
inconvenient if we first shipped the preset as I suggest in 1, and then
like this, as changes in existing presets are not really something we
can deal with nicely between Tails releases. Whatever, I'm getting ahead
of myself. :)
Any way, my point is that if someone makes `/var/lib/i2p/i2p-config/`
persistent *now*, all such future permission/symlinking changes we may
want to introduce are lost until the source directory is removed from
the persistent media. This is of course something we could instruct
users to migrate through as a one time thing, but it'd be great to get
it right from the beginning if possible.
Also, I'm not exactly sure if this would be a problem if ACLs were used
instead. However, note that, AFAIK, aufs doesn't support ACLs so e.g.
`setfacl` would fallback to emulating the ACLs via standard permissions,
which perhaps is impossible.
# 3. Potential future issue: changes to the global router.config
We set the Tails-specific default settings in the global I2P config
(`/usr/share/i2p/router.config`), which are loaded the first time I2P is
started and written to the "local" configuration
(`/var/lib/i2p/i2p-config/router.config`) and, AFAIK, never looked upon
again (right?). Hence, any changes we make to the the global config in
future Tails releases will not be applied to persistent local
configurations which may break stuff for users of this feature.
This is, BTW, the same reason why we're vary of users making torrc
persistent. At least the future torrc.d feature may make that possible
to deal with for Tor.
What about solutions? I tried a quick fix, which was to remove the local
`router.config` from an already bootstrapped router configuration, and
then start I2P again in hope that it would reimport the global config
and still be able to restore the cached netDB etc. It turns out it
didn't even reimport the settings from the global config for some reason.
A slightly more involved potential solution would be, I suppose, to make
our custom I2P start script (in the Tails Git repo) to check if a local
`router.config` exists, and if so modify it so that all settings from
the global config are restored, leaving the other settings intact so I2P
won't discard the existing cached stuff or user-set stuff (the latter
may be bad, so we may only keep the minimum amount of local settings for
it to work). I haven't done a manual test but this approach actually
looks like it could work, even though it may be a bit messy.
# Merge status
1 is easy to fix, if needed. I don't want to block this obvious
improvement (e.g. not having to do a full bootstrap each Tails session
is pretty awesome) because of something that we *may* implement
*eventually*, like 2. However, if we fail to solve 3 I don't think we
can merge this. :/
Would you like to try fixing 3, KYTV, possibly with the solution I
proposed? Otherwise you can reassign ticket #5544 to me (currently
assigned to you for other reasons as well), but then this feature
definitely won't make it in time for the 0.23 release, so you might
unset the Target version field as well.
Cheers!
