Otherwise it will try to guess the log directory, and the guess might
not be the same if chroot builds are enabled or not.
The gruesome details from m4/sudo.m4:
````
dnl
dnl Where the I/O log files go, use /var/log/sudo-io if
dnl /var/log exists, else /{var,usr}/adm/sudo-io
dnl
AC_DEFUN([SUDO_IO_LOGDIR], [
AC_MSG_CHECKING(for I/O log dir location)
if test "${with_iologdir-yes}" != "yes"; then
iolog_dir="$with_iologdir"
elif test -d "/var/log"; then
iolog_dir="/var/log/sudo-io"
elif test -d "/var/adm"; then
iolog_dir="/var/adm/sudo-io"
else
iolog_dir="/usr/adm/sudo-io"
fi
if test "${with_iologdir}" != "no"; then
SUDO_DEFINE_UNQUOTED(_PATH_SUDO_IO_LOGDIR, "$iolog_dir")
fi
AC_MSG_RESULT($iolog_dir)
])dnl
````
Adding this package to environment.systemPackages stops the
"Add new printer" button in gnome-control-center from being grayed out
and stops it from printing:
(gnome-control-center:16664): printers-cc-panel-WARNING **: Your system does not have the cups-pk-helper's policy "org.opensuse.cupspkhelper.mechanism.all-edit" installed. Please check your installation
But completing the printer setup requires some additional packaging
work. This is what happens when trying to _add_ a printer:
(gnome-control-center:18733): printers-cc-panel-WARNING **: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.fedoraproject.Config.Printing was not provided by any .service files
(gnome-control-center:18733): printers-cc-panel-WARNING **: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.PackageKit was not provided by any .service files
This commit adds the options --build-host and --target-host to nixos-rebuild.
--build-host instructs nixos-rebuild to perform all nix builds on the
specified host (via ssh). Build results are then copied back to the
local machine and used when activating the system.
--build-target instructs nixos-rebuild to activate the configuration
not on the local machine but on the specified remote host. Build
results are copied to the target machine and then activated there (via ssh).
It is possible to combine the usage of --build-host and --target-host,
in which case you can perform the build on one remote machine and deploy
the configuration to another remote machine. The only requirement is that
the build host has a working ssh connection to the target host (if the
target is not local), and that the local machine can connect to both
the target and the build host. Also, your user must be allowed to copy
nix closures between the local machine and the target and host machines.
At no point in time are the configuration sources (the nix files) copied
anywhere. Instead, nix evaluation always happens locally
(with nix-instantiate). The drv-file is then copied and realised remotely
(with nix-store).
As a convenience, if only --target-host is specified, --build-host is
implicitly set to that host too. So if you want to build locally and deploy
remotely you have to explicitly set "--build-host localhost".
To activate (test, boot or switch) you need to have root access to the
target host. You can specify this by "--target-host root@myhost".
I have tested the obvious scenarios and they are working. Some of the
combinations of --build-host and --target-host and the various actions might
not make much sense, and should maybe be forbidden (like setting a remote
target host when building a VM), and some combinations might not work at all.
