[FEATURE REQUEST] whonix support

[nyxnor]

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

It is missing setting the correct configuration file on

onionjuggler/configure.sh

Line 239 in 4006a3d

"Debian"*|*"buntu"*|"Armbian"*|"Rasp"*|"Tails"*|"Linux Mint"*|"LinuxMint"*|"mint"*) . "${topdir}"/etc/onionjuggler/debian.conf;;

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

onionjuggler/usr/bin/onionjuggler-cli

Lines 657 to 666 in 4006a3d

	if test -f /usr/share/anon-gw-base-files/gateway; then ## Whonix Gateway
	if [ "${whonix_gateway_service}" = "1" ]; then
	target_ip_default="127.0.0.1" ## Service should use Gateway ip (127.0.0.1)
	elif command -v qubesdb-read >/dev/null; then
	target_ip_default="$(qubesdb-read /qubes-ip)" ## Qubes-Whonix
	else
	target_ip_default=10.152.152.11 ## Non-Qubes-Whonix
	fi
	elif test -f /usr/share/anon-ws-base-files/workstation; then ## Whonix Workstation
	error_msg "Create onion services on Whonix Gateway, not on Whonix Workstation"

Describe the solution you'd like

Describe alternatives you've considered

Additional context

• b645b85 - 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]

ClientOnionAuthDir should be considered differently.

onionjuggler/usr/bin/onionjuggler-cli

Line 928 in 4006a3d

grep -q "ClientOnionAuthDir" "${tor_conf_tmp}" && { printf %s"\nClientOnionAuthDir ${tor_data_dir_auth}\n\n" | tee -a "${tor_conf_tmp}"; }

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.

onionjuggler/usr/bin/onionjuggler-cli

Line 1371 in 4006a3d

if ! grep -q "ControlPort ${tor_control_port}" "${tor_conf_tmp}" && ! grep -q "ControlSocket" "${tor_conf_tmp}"; then

onionjuggler/usr/bin/onionjuggler-cli

Line 1376 in 4006a3d

if ! grep -q "CookieAuthentication 1" "${tor_conf_tmp}" && ! grep -q "HashedControlPassword" "${tor_conf_tmp}"; then

[nyxnor]

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]

modifying user configuration

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

one example is

• [BUG] read the tor file completely to get hs info to delete or print #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]

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]

1436f07
dad2332

[nyxnor]

Improved safe_edit to be more short.

adf3b05
b631e5e
7ee61bf
8d54cf9
32d78f5

[nyxnor]

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]

auth-server and auth-client also working.

[nyxnor]

web

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

1. 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
2. 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]

todo

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

• default target ip alternative for whonix set on configuration file
• implement options on --web that does not require it to read the tor configuration file and the parameters will be specified on the cli.
• move --web to a separate script
• configure.sh install should allow installation of select scripts
• do not install webserver on the GW.
• create a second deb package for onionjuggler-cli-web
• 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]

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

cd46fbc

[nyxnor]

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]

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]

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]

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]

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

onionjuggler/usr/bin/onionjuggler-cli

Line 500 in c10a8de

service_block(){

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]

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]

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]

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]

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

• GW https://github.com/nyxnor/onionjuggler/blob/main/etc/onionjuggler/whonix-gateway.conf
• WS https://github.com/nyxnor/onionjuggler/blob/main/etc/onionjuggler/whonix-workstation.conf

Major eac7967
Patches 3930f2f 3d71915 159eba5

[nyxnor]

#54 (comment)
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]

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]

The debian packages will take some time for me to learn how to properly separate them with #54 (comment)

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]

nyxnor:

#54 (comment) 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]

• 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]

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]

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/

1. The debian package is ready
2. The debian package installs everything on the gateway and on the workstation, which is unwanted.
3. I haven't found a way to make the same deb package for debian and whonix
4. I don't want to submit a debian package that wouldn't work on whonix, because I am using whonix daily now.
5. 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.

[nyxnor]

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]

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/30_whonix.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]

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 edd5051

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]

bf01fd0
08d0dc3

[nyxnor]

what is missing:

• [FEATURE REQUEST] separate scripts to different deb packages #68
• make the tui work on WS, be able to create services without checking service and selecting port
• [FEATURE REQUEST] distro should be a variable on the conf file #71
• [FEATURE REQUEST] add authorizations files that already exist #48
• improve verify_config_tor() parser and safe_edit() file mangement #66 - non-blocker but highly useful
• configuring whonix_firewall
• rename torrc from 45 to 40
• 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]

Whonix/anon-apps-config#2

[nyxnor]

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]

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]

cc2380c

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]

Sounds perfect!