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_replaceto 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.
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?
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.
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.
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?
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.2I 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.
A wholly different approach could be to keep I2P configuration as is. Unmodified. Unspecific to I2P / Whonix. And thensomehow duplicate all listening ports:
127.0.0.1
127.0.0.2
Does any tool come to mind to easily bridge from .1 to .2?
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
@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.
Having new issues @Patrick
With a freshly setup and updated Whonix Template whonix-ws-16 following the instructions on Invisible Internet Project (I2P) and starting I2P manually on the AppVM anon-whonix-I2P withsystemctl start i2p as configuration through
dpkg-reconfigure in Whonix Template whonix-ws-16 does not take effect to start I2P on startup in the AppVM anon-whonix-I2P.
Issue #1
After configuring the Tor browser adjustments according to the Whonix wiki opening an I2P page e.g. http://i2p-projekt.i2p results in the behavior that Tor browser adds https:// before the address so that you receive the message Hmm. We're having trouble finding that site.
Only after changing the setting dom.security.https_only_mode_pbm to false in the Tor browser this does not happen anymore. But this setting is not described in the wiki (the wiki refers only to change dom.security.https_only_mode).
Could you please clarify this?
Issue #2
Also the setting network.proxy.socks_remote_dns, which has to be set to false according to the wiki changes to true again after restarting Tor browser which need to be changes after each Tor browser restart manually.
Issue #3
Anyway, despite these changes I still get the message The proxy server is refusing connections when openen an I2P site. On the I2P Router Console there is no state about succesful connections. The state is stucked on Network: Testing.
Issue #4
Additionally, you still need to change the ip address in /var/lib/i2p/i2p-config/clients.config.d/00-net.i2p.router.web.RouterConsoleRunner-clients.config from 127.0.0.1 to 127.0.0.2 which is not anymore described in the wiki to get the I2P Router Console running.
Are there maybe other settings which need to be changed additionally? I appreciate any support to get I2p up and running again.
It needs to be resolved as per Self Support First Policy for Kicksecure ā¢ and/or Generic Bug Reproduction.
updated i2p instructions in the wiki, please recheck the steps.
Following instructions in a new Whonix 17 Workstation succeeds, but results in two separate i2p nodes. One node at 192.0.0.1:7657 and one at 192.0.0.2:7657. You can stop one and the other will continue and can have different settings between the two. I donāt know why there are two?
Possibly related: Applications trying to connect to the i2p node are having issues connecting via the I2CP settings. They will show up as tunnels in the i2p node, but bootstrapping fails (malformed reply from socks server).
Where did you read in the current instructions that there is 127.0.0.2?
(there is no 192. unless you manually changed that)