I2P client inside Whonix-Workstation Issues

Quote @eyedeekay

Disables the built-in hidden site by default, neither jetty nor the corresponding tunnel will start in this configuration, thereby eliminating the need for all the shipped jetty configuration files. Example config can still be found in /usr/share/i2p/eepsite, if the user wishes to use the built-in hidden site they need only copy those files to /var/lib/i2p/i2p-config and re-enable the site.

Thanks, merged!

Quote @eyedeekay

Disables the built-in hidden site by default, neither jetty nor the corresponding tunnel will start in this configuration, thereby eliminating the need for all the shipped jetty configuration files.

Nice!

Example config can still be found in /usr/share/i2p/eepsite, if the user wishes to use the built-in hidden site they need only copy those files to /var/lib/i2p/i2p-config and re-enable the site.

Could you add this to Whonix wiki please? Something else needs updating in Whonix wiki?

they need only copy those files to /var/lib/i2p/i2p-config and re-enable the site.

Would this also be an option for other I2P default settings? Can we copy/paste them from some template which is already in the disk and then only use str_replace to apply the IP change?

Could you add this to Whonix wiki please? Something else needs updating in Whonix wiki?

Sure

Would this also be an option for other I2P default settings? Can we copy/paste them from some template which is already in the disk and then only use str_replace to apply the IP change?

Yeah I don’t see why not, the only issue is that they need to be there prior to launching the actual I2P router, because if the I2P router detects there is an existing config it won’t create new config files on it’s own. So if there was a script or something which did something along the lines of:

su - i2psvc cp -r /usr/share/i2p/ /var/lib/i2p/i2p-config
find /var/lib/i2p/i2p-config -exec sed -i 's|127.0.0.1|127.0.0.2|g' {} \;

prior to the first run of the router, then you would end up with a configuration which I think would have the necessary modifications.

1 Like

Is there any chance you could either,

A) add a “–create-config” feature to I2P which only creates the config and then exits? Or

B) Even better, ship the default config by default as usual config files as most other packages do (+ support drop-ins “d.” support)?

Probably yeah but how it was implemented would need to be informed by the fact that we do actually ship a default configuration, it’s the one in /usr/share/i2p which gets copied into /var/lib/i2p/i2p-config on the first run. If /usr/share/i2p had a Whonix-modded default config in it already, then the whole config could just be copied over like we normally do. Unfortunately, that would require applying the changes to /usr/share/i2p using anon-apps-config or something like it, which would involve the more extensive changes used the previous PR’s.

So there’s the “Base Config” in /usr/share/i2p/ and the “Working Config” which is in /var/lib/i2p/i2p-config. We do this so that different packages can carry different config options, for instance, Debian and Ubuntu package-installs disable automatic updates in favor of repository-managed updates, and Easy-Install bundles use different update sources than the core distribution. Copying over the wrong defaults could be harmful, so “Base Config” needs to be honored(AFAIK).

I think what would need to happen is that --create-config would copy over any “missing” config files from the Base Config?

1 Like

I see. So it goes back to the need for a .d drop-in folder where simple config overrides can be done.

I’m not sure where we’re disconnecting here, but this already exists. We can put it in /usr/share/i2p/ or /var/lib/i2p/i2p-config. All it takes is putting the config.d files into one of those directories to pre-configure everything. The caveat is that wherever we put it, it must be a complete config at this time for the purposes of whatever Whonix wants to enable. So if it wants to use hostnames, it needs a hosts.txt file to be in the working config directory at runtime, or if it wants to host the built-in website, it needs a jetty configuration. The more we want to enable, the more extensively we have to modify things, the more you have to review, etc.

The difference between /usr/share/i2p and /var/lib/i2p/i2p-config is that if you put it in /usr/share/i2p then it isn’t copied over to the working directory until the first run of the service, but if you put it in /var/lib/i2p/i2p-config then it will exist in the runtime location, prior to running the router.

So, here’s my thought based on a slightly better understanding of how diverting works in Debian packages than I had a couple weeks ago. When I install anon-apps-config(the old version, with the diverts) I end up with some “extra” files in my /usr/share/i2p directory, which includes both versions of router.config, and a diff between the original and the diverted version. So if I were to change how it works to use /usr/share/i2p/ instead and divert i2ptunnel.config and clients.config with i2ptunnel.config.anondist and clients.config.anondist and all the Jetty XML config files, then it would be easier to review because the diffs would be like, 7 lines or less for each file, most of them would be one line, and the config.d migration would happen and you would end up with a Whonix-modded /var/lib/i2p/i2p-config and an automated way to review the differences between the configs.

Or, if we can use the divert or some other Debian packaging method to delete the i2ptunnel.config and the clients.config file(or move them to a different location, like i2ptunnel.config.old, we could place the migrated config files into the /usr/share/i2p/*.config.d directories and they would be copied over with the base config.

1 Like

That’s the issue.

Does I2P have a feature request to support drop-in snippets only that extend the upstream defaults?

Similar to /etc/default/grub.d folder where settings snippets can be dropped by packages or local system administrators.

1 Like

No definitely not right now, I’m open to it hypothetically but how would that work? Right now the way the config directories work it’s basically one file, one client. Everything in one file is used to configure a single client. We can easily drop files in the config directory to create more clients using the directories, but we can’t easily change existing clients by dropping files into the config directory.

I don’t know for sure how to change this model at the moment. I guess maybe multiple levels of config directory? Like:

i2ptunnel.config.d/00-I2P_HTTP_Proxy-i2ptunnel.config.d/0_tunnel.config
i2ptunnel.config.d/00-I2P_HTTP_Proxy-i2ptunnel.config.d/1_tunnel.config
i2ptunnel.config.d/00-I2P_HTTP_Proxy-i2ptunnel.config.d/2_tunnel.config

in the case of tunnels, and

clients.config.d/00-net.i2p.router.web.RouterConsoleRunner-clients.config/0_clients.config
clients.config.d/00-net.i2p.router.web.RouterConsoleRunner-clients.config/1_clients.config
clients.config.d/00-net.i2p.router.web.RouterConsoleRunner-clients.config/2_clients.config

in the case of client apps? That could be implemented in such a way that properties in 2_*.config files would override properties in 1_*.config files, allowing the desired behavior?

1 Like

That seems basically right. The way you described it would be the way to go for most vendors (such as GNU GRUB) shipping a single application (such as GRUB).

However, since the I2P project ships many applications, that would require multiple .d drop-in configuration folders so that might be quite repetitive (config duplication) which is also non-ideal.

Maybe a global I2P configuration folder that would be parsed by all I2P applications? For example:

/etc/i2p/global.d/30_whonix.conf

listen_interface=127.0.0.2

I suppose the reason why that can’t be is, as far as I know, there’s no definite reason to believe that each client would be listening on the same host. The router console could be on a different host or port than the hidden service manager, and each of the hidden services could be listening on or forwarding to a different host than the hidden service manager. There could be multiple running instances of applications, or embedded versions running in plugins, I just don’t know where we would put it or how we would communicate the default to which tunnel.

The closest I think we could get, maybe, is if the configuration could be edited during the copy of the base config to the working config. It would entail editing the text of the config files after copying them on the first run, to replace 127.0.0.1 with whatever value we want. That way it would only be at the first run and would be applied only to the default clients. Got to figure out how to do it though.

1 Like

A wholly different approach could be to keep I2P configuration as is. Unmodified. Unspecific to I2P / Whonix. And thensomehow duplicate all listening ports:

  • from 127.0.0.1
  • to 127.0.0.2

Does any tool come to mind to easily bridge from .1 to .2?

1 Like

socat or something I suppose, but that seems rather clunky. I went ahead and tried creating a bulk configuration file editor for I2P config files, which seems to work well so far: Bulk Configuration File Editor, expose function allowing developers to determine default directory (!76) · Merge requests · I2P Developers / i2p.i2p · GitLab which we could use to make the required edits in a straightforward and painless way, we’ll see how it goes but maybe something like that can be ready for 2.2.0

1 Like

@Patrick
@eyedeekay
Is there a quick way to update my deafault Whonix installed in August’22 to modifications brought by eyedeekay?
could you create a .deb based on delta which includes these patches?

Package anon-apps-config with the updated configs is available from all
Whonix repositories through the usual update mechanism.