[FEATURE REQUEST] whonix support

nyxnor commented 2 years ago

Is your feature request related to a problem? Please describe.

It is missing setting the correct configuration file on https://github.com/nyxnor/onionjuggler/blob/4006a3d249868d7bda8befdc1e18e13d799cca58/configure.sh#L239 it just needs to test if its the GW and if it is the WS, than block it and warn to run on GW.

same flow as was done here basically https://github.com/nyxnor/onionjuggler/blob/4006a3d249868d7bda8befdc1e18e13d799cca58/usr/bin/onionjuggler-cli#L657-L666

Describe the solution you'd like

Describe alternatives you've considered

Additional context

https://github.com/nyxnor/onionjuggler/commit/b645b85e9e10c404ab1d66d70df17bdad22db337 - define target for whonix-gw running on qubes, non-qubes, for itself
http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/improve-onion-service-usability-by-script-gui/9117/8

nyxnor commented 2 years ago

ClientOnionAuthDir should be considered differently. https://github.com/nyxnor/onionjuggler/blob/4006a3d249868d7bda8befdc1e18e13d799cca58/usr/bin/onionjuggler-cli#L928

This expects the configuration to be present on the indicated torrc (tor_conf). But it is not present on 50_user.conf, also, the directory is called auth_dir on Whonix.

As was done on tor-ctrl and onion-wash, onionjuggler-cli should --verify-config and grep from there, not from a single file.

The same applies to every other non HS options, which happens to be only ControlPort and CookieAuthentication for Vanguards. https://github.com/nyxnor/onionjuggler/blob/4006a3d249868d7bda8befdc1e18e13d799cca58/usr/bin/onionjuggler-cli#L1371 https://github.com/nyxnor/onionjuggler/blob/4006a3d249868d7bda8befdc1e18e13d799cca58/usr/bin/onionjuggler-cli#L1376

nyxnor commented 2 years ago

backup

does not apply to whonix and never will because the file needs to be transfered from one vm to another. For this, follow: http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Onion_Services#Step_7:_Backup_the_Tor_Onion_Service_Private_Key

nyxnor commented 2 years ago

modifying user configuration

tor-control-panel has its own configuration file, which really helps avoid user modification.

one example is

https://github.com/nyxnor/onionjuggler/issues/51

the function will fail if there are commented lines or empty lines between the hs options. this is because it only read lines start with HiddenService and it doens't know where to stop, but maybe it should consider empty lines and commented lines but not other configuration options?

Anyway, if the user doesn't mess with the configuration in a way that would break the script, it would be with an extra included file, or I should find a better way for that function to work.

It prints correctly, it just does not delete correctly, leaving the temporary copy in a broken state, tor will show the the configuration is invalid and it won't be replaced. Tor will not reload and no configuration will be modified. This is leaves tor up and not broken, which is great, but still shows problems with the script.

nyxnor commented 2 years ago

Eval does not like the first characters of a variable being a number, and the file is saved to the current dir without the first characters 50_user_conf_tmp becomes 0_user_conf_tmp

./onionjuggler-cli: 1: eval: 50_user_conf_tmp=/tmp/50_user_conf.IMB3eN: not found
Saving a copy of /usr/local/etc/torrc.d/50_user.conf to /tmp/50_user_conf.IMB3eN
Including Hidden Service configuration to 0_user_conf_tmp

nyxnor commented 2 years ago

1436f0772069663e9eddcd89669cedc640702b49 dad2332778b21ca9699e95d28b3c9c796196c9ac

nyxnor commented 2 years ago

Improved safe_edit to be more short.

adf3b05f09b0603bd910da447e711824225662b5 b631e5e422e32a8f81d38a1634c0c03bf924a165 7ee61bfe3753b81b4460369d212993d080c0906c 8d54cf9ca763d27a4efe90b4f39a6efd93deec21 32d78f58d35323b4e374b9cc0e08dd088e5964a9

nyxnor commented 2 years ago

It is now possible to create onion services on the gateway for the workstation with:

onionjuggler-cli --activate -s ssh -p 22

for the gateway itself:

onionjuggler-cli --activate -s ssh -p 22 -g

nyxnor commented 2 years ago

auth-server and auth-client also working.

nyxnor commented 2 years ago

web

Does not work. Webserver is installed by default and I am thinking of removing it because:

onionjuggler-cli is installed on the gateway, this means nginx would be installed there and it should not. http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Onion_Services#Step_1:_Install_Server_Software
it expects to read the tor_conf, which is on the gateway, not on the workstation, to get the service name and check if it exists, so the web server configuration file can be saved with a intuitive name and it is sure that the service exists before creating a web server config for nothing.

This leads me to think that onionjuggler has to be divided in more scripts, at least separate client options (web, location) from the rest. Still, this does not solve point 2. As the workstation can't see the hs config in the torrc, a workaround needs to be made by providing the target ports for the webserver to listen to.

conclusion

https://forums.whonix.org/t/improve-onion-service-usability-by-script-gui/9117/8

So onionjuggler-cli should be separate in more scripts, the web part depends on a webserver being installed, in this case, nginx. The rest doesn't. On the Workstation, it only makes sense to install location and focus on web. So there will be 2 debian packages for whonix, one will be installed on the WS and one on the GW.

nyxnor commented 2 years ago

todo

Changes marked as complete means that was completed on my local branch, could be still not pushed to github yet.

[x] default target ip alternative for whonix set on configuration file
[x] implement options on --web that does not require it to read the tor configuration file and the parameters will be specified on the cli.
[x] move --web to a separate script
[x] configure.sh install should allow installation of select scripts
[x] do not install webserver on the GW.
[ ] create a second deb package for onionjuggler-cli-web
[x] tui should check which scripts exists to set the main menu, something like command -v onionjuggler-cli-web and add it to the dialog if existent,

nyxnor commented 2 years ago

This is wrong because as the command is ran on the Gateway, it gets the gateway qube ip, not the workstation qube ip.

   elif command -v qubesdb-read >/dev/null; then 
     target_ip_default="$(qubesdb-read /qubes-ip)" ## Qubes-Whonix

....

the default target ip is 127.0.0.1, but this can be made a configuration option so no need to specify the WS qube ip every time to set the target.

on WS:

qubesdb-read /qubes-ip

on GW

echo "tor_hiddenserviceport_target_addr=WS_QUBE_IP" | sudo tee -a /etc/onionjuggler/conf.d/file.conf

cd46fbcc23e448fd1acaa9a5004c8db5f525eac8

nyxnor commented 2 years ago

building separate deb packages

https://askubuntu.com/questions/548662/how-to-create-multiple-debian-packages-using-the-same-debian-directory

https://askubuntu.com/questions/246718/change-environment-variables-in-debian-rules-according-to-debian-control-targets/908351#908351

nyxnor commented 2 years ago

requirements_ws="grep sed nginx whiptail" scripts_ws="onionjuggler-cli-web onionjuggler-cli-location"

requirements_gw="tor grep sed tar openssl basez git python3-stem whiptail" scripts_gw="onionjuggler-cli-auth-server onionjuggler-cli-auth-client onionjuggler-cli-vanguards"

For the separate scripts to work indepdently, each one will need option parsin, so the common functions gotta go to /usr/share so every script can source from there.

adrelanos commented 2 years ago

For the separate scripts to work indepdently, each one will need option parsin, so the common functions gotta go to /usr/share so every script can source from there.

Yes.

building separate deb packages

https://askubuntu.com/questions/548662/how-to-create-multiple-debian-packages-using-the-same-debian-directory

https://askubuntu.com/questions/246718/change-environment-variables-in-debian-rules-according-to-debian-control-targets/908351#908351

This is certainly possible. You'd need multiple .install files.

https://github.com/nyxnor/onionjuggler/blob/main/debian/onionjuggler.install

And additional package would have to be declared in debian/control.

To split into multiple packages, let's consider the source code structure.

/ - root of source package
- /package-one/ - root of package-one
- /package-one/usr - /usr folder of package-one

Good idea? I also wondering about an additional /src folder. Perhaps then auto-generation of the .install file would be simpler.

adrelanos commented 2 years ago

50_user.conf

If auto-generated by a script, better not to use /usr/local/etc/torrc.d/50_user.conf. Example:

/usr/local/etc/torrc.d/40_tor_control_panel.conf

backup

Yes, that seems pretty Whonix (actually VM) specific. Getting an onion service private key out of a VM is certainly non-trivial usability wise. Adding a reminder, link to documentation might be helpful. Other than that, seems pretty difficult and probably best if out of scope of initial implementation. Even later, seems pretty difficult (Qubes qrexec based) to improve upon.

maybe it should consider empty lines and commented lines but not other configuration options?

Why not ignore empty and commented lines? Maybe I don't understand something.

Not sure parsing should be done. Perhaps more robust to just do auto generation of config files?

eval

Are you sure eval is needed? Didn't look closely yet what you're doing but it shouldn't be that complex? Would source work instead? source is great to parse/process config snippets with variables. For example, all of Whonix build script doesn't require eval.

nyxnor commented 2 years ago

This is certainly possible. You'd need multiple .install files. https://github.com/nyxnor/onionjuggler/blob/main/debian/onionjuggler.install

The debian installation is default to using debian.conf, later rethink how to make it use other debian derivatives such as whonix for building specific deb packages.

Good idea? I also wondering about an additional /src folder. Perhaps then auto-generation of the .install file would be simpler.

I don't understand.

If auto-generated by a script, better not to use /usr/local/etc/torrc.d/50_user.conf.

Reminder to change this later, to 45_onionjuggler.conf or somethinkg like it.

maybe it should consider empty lines and commented lines but not other configuration options?

Why not ignore empty and commented lines? Maybe I don't understand something. Not sure parsing should be done. Perhaps more robust to just do auto generation of config files?

Issue #51 https://github.com/nyxnor/onionjuggler/blob/c10a8deea3927435e0801ca1758d1b8d746b4fbf/usr/bin/onionjuggler-cli#L500

Why not ignore?

Because of user modification, if the script is the only modifier of that file, than it is ok.

For example, this would work to delete the lines:

HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22

## 80 for http and 22 for ssh
HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22

But this wouldn't:

HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3

HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22

HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3
## http port
HiddenServicePort 80 127.0.0.1:80
## ssh port
HiddenServicePort 22 127.0.0.1:22

And I don't want it to only break on empty lines between blocks, so this can be valid:

HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22

HiddenServiceDir /var/lib/tor/services/hs2
HiddenServiceVersion 3
HiddenServicePort 8080 127.0.0.1:8080

and this also can be valid:

HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22
HiddenServiceDir /var/lib/tor/services/hs2
HiddenServiceVersion 3
HiddenServicePort 8080 127.0.0.1:8080

and by valid I mean, it will only delete the correct service block, no more, no less.

Comments on top are ignored, the comments will not be deleted, just the configuration lines. Comments in the middle or empty lines will make that function break and in the end no change will be made, which does not break tor because of safe_edit() and verify_config_tor() but still the script would not work as expected

Deleting blocks of lines are difficult, because I am thinking how to would read that file. It understands empty lines between HiddenServicePort lines and it would assign all of them to the last HiddenServiceDir set before those ports lines.

Are you sure eval is needed? Didn't look closely yet what you're doing but it shouldn't be that complex? Would source work instead? source is great to parse/process config snippets with variables. For example, all of Whonix build script doesn't require eval.

Yes and that was not an eval proble, it is a shellscript rule, variables can not start with numbers. Anyway, that problem was fixed. The use of eval is required to assign a variable temporary file to a temporary variable. safe_edit tmp tor_conf gets the tor_conf file, makes a temporary copy, example /tmp/torrc.XXXXXX, then eval ${key}_tmp="/tmp/torrc.XXXX". Eval is needed for that. The only use case right now is for tor_conf, but in the future, it can be used to test webserver configuration for example, if nginx -t fails, then don't apply modifications to /etc/nginx/sites-enabled/.

nyxnor commented 2 years ago

On one hand, I was not wanting to separate script before because

shellcheck warns about unused variables, and using directives for that is a pain for every occurrence
declaring default values per file instead of sourced file is also a pain because later it could lead to different values for the same variable on different files
repeated option parsing and help messages that will need to be updated repeatedly

On the other hand

smaller chunks of code on separate files for new people to the codebase to review
plugin like script instead of --backup inside onionjuggler-cli, the cli will call onionjuggler-cli-backup, so you can modify a onionjuggler-cli-backup just for whonix with a debian patch and not modify upstream.

adrelanos commented 2 years ago

To split into multiple packages, let's consider the source code structure.

/ - root of source package
- /package-one/ - root of package-one
- /package-one/usr - /usr folder of package-one

Or...

/ - root of source package
- /src - src of source package
- /src/package-one/ - root of package-one
- /src/package-one/usr - /usr folder of package-one

The debian installation is default to using debian.conf,

Ok.

later rethink how to make it use other debian derivatives such as whonix for building specific deb packages.

Whonix package anon-apps-config would drop a config snippet into a config.d folder, i.e. /etc/onionjuggler/conf.d/30_whonix.conf.

Since you already created a whonix.conf it would also be great to keep/maintain that file upstream, here. Then it could be moved to /usr/share/doc/onionjuggler or so. In that case, Whonix package anon-apps-config would just add a symlink.

Or since the config is sourceed it could auto-detect Whonix and only set these changes if Whonix was detected.

nyxnor commented 2 years ago

To split into multiple packages, let's consider the source code structure.

Now I get it. I am currently separating the scripts, so after I commit, we should review this.

Whonix package anon-apps-config would drop a config snippet into a config.d folder, i.e. /etc/onionjuggler/conf.d/30_whonix.conf. Since you already created a whonix.conf it would also be great to keep/maintain that file upstream, here. Then it could be moved to /usr/share/doc/onionjuggler or so. In that case, Whonix package anon-apps-config would just add a symlink. Or since the config is sourceed it could auto-detect Whonix and only set these changes if Whonix was detected.

Yes.

nyxnor commented 2 years ago

Scripts separated https://github.com/nyxnor/onionjuggler/tree/main/usr/bin Functions on https://github.com/nyxnor/onionjuggler/tree/main/usr/share/onionjuggler Configuration separated for

Major eac796782bef6f2d1780ad8267a66ba93ef2ffdb Patches 3930f2f2f9ca1e2f2fb78dff8262190c97109419 3d71915c50caee0384eddedd48d655d51a962cb9 159eba5507f318298309eec663fc05ea34a93f66

nyxnor commented 2 years ago

https://github.com/nyxnor/onionjuggler/issues/54#issuecomment-1044868681 Now, after separating the scripts and configuration, I can see better on how to separate the debian packages. But I don't know which would be the best approach?

Consider every plugin a deb package?
Default package installs everything or no plugins?

nyxnor commented 2 years ago

This is what I am thinking:

Package: onionjuggler
Architecture: all
Depends: tor, sudo, grep, sed, whiptail, qrencode

Package: onionjuggler-auth
Architecture: all
Depends: onionjuggler, openssl, basez,

Package: onionjuggler-web
Architecture: all
Depends: onionjuggler, nginx | apache2,

Package: onionjuggler-vanguards
Architecture: all
Depends: onionjuggler, python3, python3-stem, git

Package: onionjuggler-auth
Architecture: all
Depends: onionjuggler, tar,

All the plugins have dependency on the main configuration because the functions will be installed from the main onionjuggler package. Of course this could be removed but I don't see a reason right now, as you would be able to activate and deactivate a service without the main config.

Renaming from plugins to modules because:

plugins are normally a piece of software that you can plug into an application to provide new functionality
while module adds features to a specific application.

That is why your download prosody-modules (module) and pidin-otr (plugin).

nyxnor commented 2 years ago

The debian packages will take some time for me to learn how to properly separate them with https://github.com/nyxnor/onionjuggler/issues/54#issuecomment-1044868681

But if installing from git, the ws and the gw have their own conf now, so running:

sudo ./configure.sh -i

will install correctly on each host.

adrelanos commented 2 years ago

nyxnor:

https://github.com/nyxnor/onionjuggler/issues/54#issuecomment-1044868681 Now, after separating the scripts and configuration, I can see better on how to separate the debian packages. But I don't know which would be the best approach?

Consider every plugin a deb package?

If it's sufficiently complex, yes.

Default package installs everything or no plugins?

Can be a plugin strucutre but a small number of packages or even just 1 package is better than many packages.

Because one thing is for sure. Debian FTP master don't like 1 file = 1 package. Each package adds overhead to packages.debian.org. Therefore minuscule packages are discouraged.

nyxnor commented 2 years ago

Consider every plugin a deb package? If it's sufficiently complex, yes.

Lets take onionjuggler-cli-web for example. It is not complex but it should not be installed on the gateway, as the webserver will be installed as a dependency.

The other dependencies of the other packages are very light, but normally installing webservers comes with a lot of security concerns.

Can be a plugin strucutre but a small number of packages or even just 1 package is better than many packages.

Can you suggest how you'd separate onionjuggler? This was my model, but haven't done anything yet.

Another possibility is installed core onionjuggler and then onionjuggler-modules with all the plugins/modules, but this would install the webserver on the GW which is unwanted.

pkg onionjuggler

onionjuggler-tui
onionjuggler-cli
functions
configurations

pkg onionjuggler-modules

onionjuggler-cli-auth
onionjuggler-cli-web
onionjuggler-cli-vanguards
onionjuggler-cli-backup

But backup will not work on whonix and web should not be installed on the GW because of webserver. So if you know and alternative for this, pls share.

adrelanos commented 2 years ago

These are good questions. I don't know and would suggest Debian Mentors. Lots of search results. Then either asking Debian Mentors on IRC and/or the Debian Mentors mailing list.

https://mentors.debian.net/

https://wiki.debian.org/DebianMentors

https://lists.debian.org/debian-mentors/

nyxnor commented 2 years ago

on IRC they sent me this introduction https://mentors.debian.net/intro-maintainers/ after my questions. So it feels like I have to submit the package before asking questions about how to organize it. This will take some time to process.

I should submit via https://www.debian.org/devel/wnpp/

The debian package is ready
The debian package installs everything on the gateway and on the workstation, which is unwanted.
I haven't found a way to make the same deb package for debian and whonix
I don't want to submit a debian package that wouldn't work on whonix, because I am using whonix daily now.
Another possibility is whonix hosting a different deb package for onionjuggler, ws and gw.

You don't need to respond, sometimes I write things just so I can remember why some actions were taken or not and why that direction.

adrelanos commented 2 years ago

Seems like there's a solution...

Debian package: Primarily for Debian.

How to make it Whonix compatible? Maybe a solution by Whonix? Idea...

Perhaps see https://github.com/Kicksecure/kicksecure-meta-packages/blob/master/debian/control and look for textual string:

dummy-dependency

A new dependency could be invented named: dummy-dependency-webserver

Which would Provides: nginx, apache2.

(Similar to the other already existing dummy-dependency packages.)

That would fit to be added here: https://github.com/Whonix/anon-meta-packages/blob/master/debian/control

Then in Whonix, any unwanted dependency wouldn't be installed thanks to dummy-dependency-webserver or even if needed more generally dummy-dependency-tor-ctrl or even dummy-dependency-anon-gateway.

Let me know if you need help with the dummy-dependency, I should be able to get that done soonish if a good way forward.

The last step would be either:

the script refusing the run in the gateway and explaining why (if [ -e /usr/share/anon-gw-base-files/gateway ]; then) (preferably?),
or anon-gw-anonymizer-conf using config-package-dev hide any scripts unwanted on the gateway.

I don't want to submit a debian package that wouldn't work on whonix, because I am using whonix daily now.

Great to know!

You don't need to respond, sometimes I write things just so I can remember why some actions were taken or not and why that direction.

Alright. :)

nyxnor commented 2 years ago

dummy-dependency-weberser seems to be the solution.

the script refusing the run in the gateway and explaining why (if [ -e /usr/share/anon-gw-base-files/gateway ]; then) (preferably?),

There are 5-6 scripts now, I would need to repeat that code inside every script. I am thinking of introducing an onionjuggler.conf configuration block (as is prohibit) from running specified script, the script would detect if it should be run or not from the configuration, not per system base.

Thanks for the help, hope to get this working on Whonix.

adrelanos commented 2 years ago

That sounds great!

nyxnor commented 2 years ago

Debian/Whonix

sudo apt install -y devscripts
sudo mk-build-deps --remove --install -y
sudo dpkg-buildpackage -b --no-sign
sudo dpkg -i ../onionjuggler_*.deb

Debian (end) Whonix (continue)

whonix-gateway.conf

whonix-workstation.conf

if test -f /usr/share/anon-ws-base-files/workstation; then
sudo cp WS_CONF /etc/onionjuggler/conf.d/whonix-workstation.conf
elif test -f /usr/share/anon-gw-base-files/gateway; then
sudo cp GW_CONF /etc/onionjuggler/conf.d/whonix-gateway.conf
fi

nyxnor commented 2 years ago

so what I did is the following:

onionjuggler_plugin conf. If empty, all plugins are enabled, if any specified, example, web, then that script will error out saying it is disabled in settings.

All the scripts will be installed, but only those allowed to run will be run.

I think I finished the work for whonix , but of course I need to test and retest on the GW and WS cause there are a lot of functionality. Anyway, treat this repository on a disposable GW and WS.

adrelanos commented 2 years ago

if test -f /usr/share/anon-ws-base-files/workstation; then
  sudo cp WS_CONF /etc/onionjuggler/conf.d/whonix-workstation.conf
elif test -f /usr/share/anon-gw-base-files/gateway; then
  sudo cp GW_CONF /etc/onionjuggler/conf.d/whonix-gateway.conf
fi

Where would that be added?

Ideally, declarative programming (declarative vs imperative) should be preferred. What I mean, during Debian packaging it's preferable to place the files where they belong using folder/.install file instead of scripting in postinst. That is because declarative style is easier to understand by others, later on.

So instead of need for sudo cp somewhere (or other auto-generated files), would be preferably if this could be more static (less scripting).

For the separate scripts to work indepdently, each one will need option parsin, so the common functions gotta go to /usr/share so every script can source from there.

Sounded nice for that.

nyxnor commented 2 years ago

Where would that be added?

I was thinking of this: _Whonix package anon-apps-config would drop a config snippet into a config.d folder, i.e. /etc/onionjuggler/conf.d/30whonix.conf.

Because if I package for debian.org, than anon-apps-config could manage to make onionjuggler work on whonix, but to put on the debian.install, I need to see how dh-exec would work with that, and this means for the time being you would package the package directly for whonix.

Edit: text above is horrible, let me try again:

If I submit the package for debian, then anon-apps-config would need to take care of adding those configuration files to conf.d
even if I submit my package for debian, but your prefer to package and host on deb.whonix.org for whaterver reason (faster updates, keep the software in check), then I'd need help on how to make that work with debian/onionjuggler.install.
from my debian experience, updates take ages if the debian sponsor does not care much or if the process hangs.

Sounded nice for that.

Already done :)

nyxnor commented 2 years ago

onionjuggler-tui does not have yet a --gateway option to say the service if for the gateway, not for the workstation.

[x] add gateway flag on the tui if detected that the script is being run on the GW.
[x] block gateway from using unix sockets, only allow tcp.

finished on https://github.com/nyxnor/onionjuggler/commit/edd5051d047c652ede9c72d5af355756755e0618

nyxnor commented 2 years ago

First run fails on gateway service creation if I use a non existent file, it won't be created as of not, it just fails

$ sudo onionjuggler-tui 
grep: /usr/local/etc/torrc.d/45_onionjuggler.conf: No such file or directory
Saving a copy of /usr/local/etc/torrc.d/45_onionjuggler.conf to /tmp/45_onionjuggler.conf.jQFJBS
cp: cannot stat '/usr/local/etc/torrc.d/45_onionjuggler.conf': No such file or directory
Including Hidden Service configuration to /tmp/45_onionjuggler.conf.jQFJBS

HiddenServiceDir /var/lib/tor/services/ssh
HiddenServiceVersion 3
error: Please set the Workstation Qube IP address using the option 'tor_hiddenserviceport_target_addr' on /etc/onionjuggler/conf.d/*.conf

Exiting script onionjuggler-cli
Deleting /tmp/45_onionjuggler.conf.jQFJBS
Press ENTER to return to the TUI!

Edit:

corrected with 63ca7d5 and 285a8c1

adrelanos commented 2 years ago

nyxnor:

Where would that be added?

I was thinking of this: _Whonix package anon-apps-config would drop a config snippet into a config.d folder, i.e. /etc/onionjuggler/conf.d/30whonix.conf.

Ah. Yes. That is nicely mostly static/declarative.

Note: anon-apps-config is installed on both workstation and gateway. But that is good enough. The config snippet itself could check where it's running (the usual marker files) and only apply gateway config to gateway and workstation config to workstation.

Bonus wish: onion-juggler pointing out by using a config comment somewhere or so the Whonix snippet by anon-apps-config to make it easier to grasp for others how Whonix support was implemented.

nyxnor commented 2 years ago

Bonus wish: onion-juggler pointing out by using a config comment somewhere or so the Whonix snippet by anon-apps-config to make it easier to grasp for others how Whonix support was implemented.

Edit: done in https://github.com/nyxnor/onionjuggler/commit/edd5051d047c652ede9c72d5af355756755e0618

There is not much secret, I can include some comments later, but here is a sketch:

Mostly configs default to debian.

Except on WS:

## web is the only useful plugin for the WS
onionjuggler_plugin="web"
## requirements only used if installing with configure.sh
requirements="grep sed qrencode ${dialog_box} ${webserver}"

Except on GW:

## only allow plugins that are useful and works on the gateway
## backup not possible because of VMs
## web should be on the WS
## vanguards maybe could be included but it is installed from git, not from deb pkg
onionjuggler_plugin="auth-server,auth-client"
## webserver does not matter of web plugin is disabled
webserver="nginx"
## removed webserver from GW requirements
## requirements does not affect if building the debian package
## it is only used by configure.sh
requirements="tor grep sed tar openssl basez qrencode ${dialog_box}"
## included directory
tor_conf_dir="/usr/local/etc/torrc.d"
## select unique torrc for the script
tor_conf="${tor_conf_dir}/45_onionjuggler.conf"
## default ClientOnionAuthDir
tor_data_dir_auth="${tor_data_dir}/authdir"

So, building the deb package has very minimal dependencies:

Depends: tor, grep, sed,
  whiptail,
  openssl, basez,
  tar,
  git, python3, python3-stem,
  nginx | apache2 | dummy-dependency-webserver,
Recommends: qrencode,

tor, grep, sed - just to be sure (used in every script)
whiptail - because it is debian default, but can also be dialog (onionjuggler-tui)
openssl, basez - onion authentication, debian comes with openssl but not basez (onionjuggler-cli-auth-client and onionjuggler-cli-auth-server)
tar - backup, don't know if already installed on debian or whonix (onionjuggler-cli-backup)
git, python3, python3-stem - vanguards. Even though it is not going to be installed on whonix, python3 and python3-stem are already installed, so extraneous dependency is git (onionjuggler-cli-vanguards)
nginx | apache2 | dummy-dependency-webserver - solved by dummy dependency for the GW. (onionjuggler-cli-web)
qrencode - only used if installed, that is why it is on the recommended list.

nyxnor commented 2 years ago

bf01fd0ac559fcc3eec73b5f8cf41f618270d60e 08d0dc35640747fb74df9939e9185d6ba9e2902e

nyxnor commented 2 years ago

what is missing:

[x] https://github.com/nyxnor/onionjuggler/issues/68
[x] make the tui work on WS, be able to create services without checking service and selecting port
[x] https://github.com/nyxnor/onionjuggler/issues/71
[x] https://github.com/nyxnor/onionjuggler/issues/48
[x] https://github.com/nyxnor/onionjuggler/issues/66 - non-blocker but highly useful
[x] configuring whonix_firewall
[x] rename torrc from 45 to 40
[x] change when possible from Whonix to Anon, from ws to workstation, from gw to gateway. https://forums.whonix.org/t/rename-to-qubes-whonix-templates-to-whonix-gateway-17-whonix-workstation-17/14515

nyxnor commented 2 years ago

https://github.com/Whonix/anon-apps-config/pull/2

nyxnor commented 2 years ago

whonix is supported, some scripts can run on the workstation and most of them on the gateway.

closing as completed.

If bugs appear for Whonix in the future, better to create a new issue because this got too long.

nyxnor commented 2 years ago

still related to implementation, there is a simple problem to be solved for qubes whonix:

the configuration file persistence.

Currently, it is only checking /etc/, not /usr/loca/etc.

For me to also read. https://www.whonix.org/wiki/Qubes#Qubes_Persistence

I am thinking of

shipping everything to /etc/onionjuggler as I am the vendor, this directory will be read first
manual page saying for qubes-whonix users to use /usr/local/etc/onionjuggler/conf.d/50_user.conf
- I want them to use the conf.d in all cases so there is no mess of using /usr/local/etc/onionjuggler/50_user.conf directly.

Else they would need to bind /etc/onionjuggler in the app qube.

I didn't notice this before because I use the defaults, and didn't notice of loosing a conf.d configuration because that was only used for testing.

nyxnor commented 2 years ago

cc2380c06b7ff958b21073f4b2cc6767304afa5f

The project ships /etc/onionjuggler/onionjuggler.conf. Packages ships /etc/onionjuggler/conf.d/*.conf. User modifies /usr/local/etc/onionjuggler/onionjuggler.conf and/or /usr/local/etc/onionjuggler/conf.d/*.conf.

Also, insluded and excluded files are shown when running with the --getconf option so user can better understand the order files are parsed and which ones where included and which ones were excluded because didn't meet the requirements of file name.

adrelanos commented 2 years ago

Sounds perfect!

nyxnor / onionjuggler