Improve Onion Service Usability by Script / GUI

Does Whonix have any example of a Source with multiple Packages that have man pages that need to be installed per package?

Currently, it is installing all man pages for each package. Didn’t find anything searching the web. Just trying to understand how other packages does this.

Edit:
NVM
https://www.debian.org/doc/manuals/maint-guide/dother.en.html#manpages

1 Like

Please add manpages here using the same format:

These I will later use to create the “real” (roff) format using genmkfile manpages.

The Debian packaging “magic” is here:

OnionJuggler is 1 source and multiple packages.
Using:

override_dh_installman:
	dh_installman $(CURDIR)/auto-generated-man-pages/*

doesn’t work because all manual pages will be installed to all packages.

Each package need a debian/PACKAGE_NAME.manpages to install the correct man pages per package.

Anyway, there is already man/ and auto-generated-man-pages/ directories, but it is made by ./configure.sh -m (create man pages).

Does it affect your build? Do you generate man pages for every build or just build the packages?

Because if just building and the man pages are already updated, then no extra effort.

1 Like

Im remembering now I already tried to port my manpage generation from pandoc to ronn, but it didn’t work. Tried again, don’t know how to fix.

The manpages are pretty dense on information, so I need to keep them organized and easy to read, and with pandoc is working. If you can port the manuals to ronn without drawbacks then that is ok.

1 Like

Ah. Yeah. For multiple packages…

https://manpages.debian.org/dh_installman

FILES

debian/package.manpages

Lists man pages to be installed.

  • debian/package1.manpages
  • debian/package2.manpages

File content would be only the path to the autogenerated man pages.

Example:


The ronn / format isn’t too important as long as the final package is alright.

genmkfile manpages is manual when a man page source file was updated (ronn) and the roff needs to be updated. If I remember to do that. Doesn’t seem too useful to automate that during the build process. Would have to check contents are reproducible / deterministic.

Otherwise the build process only automatically takes the files from the autogenerated folder.

1 Like

So you don’t need to worry about manpages. I generate them with a script before pushing (most of the time hehe).

Just fixing lintian warnings and it is pretty much ready for review and trying to break the scripts.

GW should install onionjuggler-cli onionjuggler-cli-auth
WS should install onionjuggler-cli-web

GW or WS can install onionjuggler-tui, it is quite handy, just not “beautiful” because it has to be versatile to check which onionjuggler-cli commands it has.

GW

sudo apt install onionjuggler-cli onionjuggler-cli-auth onionjuggler-tui

WS

sudo apt install onionjuggler-cli-web onionjuggler-tui
1 Like

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.

https://github.com/nyxnor/onionjuggler/blob/main/etc/onionjuggler/anon-workstation.conf
https://github.com/nyxnor/onionjuggler/blob/main/etc/onionjuggler/anon-gateway.conf

Also, as I don’t have a local repo to test, the steps to test are the following:

Build the package as usual, mk-build-deps, dpkg-buildpackage.

Then install first the onionjuggler-lib, then any wanted deb package.

## _apt user can access /tmp
cp ../onionjuggler*.deb /tmp
sudo apt install /tmp/onionjuggler-lib_*.deb

Then, copy the anon configuration files to /etc/onionjuggler/conf.d/

##From inside the git repo: 

## GW
sudo cp etc/onionjuggler/anon-gateway.conf /etc/onionjuggler/conf.d/

## WS
sudo cp etc/onionjuggler/anon-workstation.conf /etc/onionjuggler/conf.d/

1 Like

Why is this required? Will this be required in the final version as a user action?

Yes, such a solution is much better.

Why is this required?

Because it currently ships debian.conf

Will this be required in the final version as a user action?

No, Im hoping anon-apps-config would do this.
But also, as I don’t plan to ship to debian.org. just whonix for now, then I could do two packages, one for GW and one for WS, then the configuration shipped would be correct

Would you prefer onionjuggler-lib-workstation and onionjuggler-lib-gateway to be created instead of relying on anon-apps-config? Then you should drop the standard onionjuggler-lib that uses the debian.conf as default.

Ah. Yes. A pull request for anon-apps-config would be welcome.

Better keeping the number of packages low. Packages with just only 1 file are best avoided in any case (even rejection reason for packages.debian.org).

How will anon-apps-config place the 30_whonix.conf correctly for GW and for WS?

For example, there is a conf file for the WS and one for the GW, where will anon-apps-config detect that?

In postinst?

1 Like

Best to avoid postinst. Just 1 bash snippet which is then looking at the usual marker files and setting different settings accordingly.

1 Like

yes, but where should that be done? I struggling to see where.
[FEATURE REQUEST] whonix support · Issue #54 · nyxnor/onionjuggler · GitHub

My thinking:

anon-apps-config copies every config from etc/* to /etc

There is anon-workstation.conf and anon-gateway.conf, but only one can prevail as /etc/onionjuggler/conf.d/30_whonix.conf

1 Like

Inside the config snippet there could be

if test -f ... ; then
...
elif test -f ... ; then
...
else
...
fi

Therefore the same snippet could be used in different VMs.

I stopped sourcing configuration files directly

  • configuration files are not intended to run commands

After seeing it will not be done by anon-apps-config, I get back to the point of building two onionjuggler-libs, one for WS and one for GW. Would you accept this?
Can’t be because then I’d need to modify the dependencies of other packages to point to the right lib.

I think the best to be done is two onionjuggler packages, one for gw, one for ws.

1 Like

But it works nicely and there is no security reason against it?
It’s quite common too. Examples include:

  • /etc/grub/default file
  • /etc/grub/default.d folder
  • /etc/grub.d folder folder
1 Like

No security reason. It was to parse configuration and print invalid configuration options [FEATURE REQUEST] test configuration options · Issue #58 · nyxnor/onionjuggler · GitHub
but I couldn’t do this in the end.

Didn’t know, thanks for sharing, will revert to source the configuration as before.

1 Like
1 Like