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! _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.