This overhauls the Tor module in a few ways:
- Uses systemd service files, including hardening/config checks
- Removed old privoxy support; users should use the Tor Browser
instead.
- Remove 'fast' circuit/SOCKS port; most users don't care (and it adds
added complexity and confusion)
- Added support for bandwidth accounting
- Removed old relay listenAddress option; taken over by portSpec
- Formatting, description, code cleanups.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Rather than trying to override the 'torsocks' executable in $PATH, the
new module instead properly configures `/etc/tor/torsocks.conf` and puts
the normal `torsocks` executable in $PATH so it can work out of the box.
As a bonus, I think this module actually works now, because the torsocks
configuration has changed a lot from when this was written, it seems...
Signed-off-by: Austin Seipp <aseipp@pobox.com>
'torify' now ships with the tor bundle itself; and using torsocks is
recommended over tsocks (torify will use torsocks automatically.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
From http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
You disable the assignment of fixed names, so that the unpredictable
kernel names are used again. For this, simply mask udev's rule file for
the default policy: ln -s /dev/null
/etc/udev/rules.d/80-net-setup-link.rules (since v209: this file was
called 80-net-name-slot.rules in release v197 through v208)
From http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
You disable the assignment of fixed names, so that the unpredictable
kernel names are used again. For this, simply mask udev's rule file for
the default policy: ln -s /dev/null
/etc/udev/rules.d/80-net-setup-link.rules (since v209: this file was
called 80-net-name-slot.rules in release v197 through v208)
Following the discussion NixOS#5021:
- obsolete the nix.proxy option
- add the networking.proxy option
- open a default no_proxy environment variable
- add a rsync option
- Manual tests ok.
- Automatic tests ok.
Amended by lethalman to simplify the option descriptions.
Using primusrun will work as expected in a multilib environment. Even if the initial program
executes a antoehr program of the another architecture. Assuming the program does not modify
LD_LIBRARY_PATH inappropriately.
This does not update virtualgl for seemless multilib. I was unable to get a mixed 64/32 bit
environment to work with VirtualGL. The mechanism VirtualGL uses to inject the fake GL library would
fail if both 32bit and 64 bit libraries were in the environment. Instead the bumblebee package
creates a optirun32 executable that can be used to run a 32bit executable with optimus on a 64 bit
host. This is not created if the host is 32bit.
For my usage, gaming under wine, the primusrun executable works as expected regardless of
32bit/64bit.
VirtualBox with hardening support requires the main binaries to be
setuid root. Using VBOX_WITH_RUNPATH, we ensure that the RPATHs are
pointing to the libexec directory and we also need to unset
VBOX_WITH_ORIGIN to make sure that the build system is actually setting
those RPATHs.
The hardened.patch implements two things:
* Set the binary directory to the setuid-wrappers dir so that
VboxSVC calls them instead of the binaries from the store path. The
reason behind this is because nothing in the Nix store can have the
setuid flag.
* Excempt /nix/store from the group permission check, because while it
is group-writeable indeed it also has the sticky bit set (and also
the whole store is mounted read-only on most NixOS systems), so we're
checking on that as well.
Right now, the hardened.patch uses /nix/store and /var/setuid-wrappers
directly, so someone would ever want to change those on a NixOS system,
please provide a patch to set those paths on build time. However, for
simplicity, it's best to do it when we _really_ need it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We will simply rename the previous module and add a warning whenever the
module is included directly, pointing the user to the right option and
also enable it as well (in case somebody has missed the option and is
wondering why VirtualBox doesn't work anymore).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Especially new users could be confused by this, so we're now marking
services.virtualbox.enable as obsolete and defaulting to
services.virtualboxGuest.enable instead. I believe this now makes it
clear, that this option is for guest additions only.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
