By default, restic determines the location of the cache based on the XDG
base dir specification, which is `~/.cache/restic` when the environment
variable `$XDG_CACHE_HOME` isn't set.
As restic is executed as root by default, this resulted in the cache being
written to `/root/.cache/restic`, which is not quite right for a system
service and also meant, multiple backup services would use the same cache
directory - potentially causing issues with locking, data corruption,
etc.
The goal was to ensure, restic uses the correct cache location for a
system service - one cache per backup specification, using `/var/cache`
as the base directory for it.
systemd sets the environment variable `$CACHE_DIRECTORY` once
`CacheDirectory=` is defined, but restic doesn't change its behavior
based on the presence of this environment variable.
Instead, the specifier [1] `%C` can be used to point restic explicitly
towards the correct cache location using the `--cache-dir` argument.
Furthermore, the `CacheDirectoryMode=` was set to `0700`, as the default
of `0755` is far too open in this case, as the cache might contain
sensitive data.
[1] https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Specifiers
The built-in default for unknown MIME-Types is `text/plain` whereas the
upstream default config changes it to `application/octet-stream`. By
changing the default tpye, unknown files will be downloaded by browsers
instead of being displayed.
Define systemd-socket activation using the upstream configuration
files as a reference. The "rsyncd" systemd unit has been renamed
to "rsync" for consistency with upstream.
Since release 20.09 `rngd.enable` defaults to false, so this setting is redundant.
Also fix the `qemu-quest` section of the manual that incorrectly claimed
that `rngd` was enabled.
OSS Emulation is considered incomplete so disabling it by default.
Using user level alsa-oss library (nix-env -iA nixos.alsaOss) over
this kernel module is recommended.
Without this patch merging options like
services.xserver.windowManager.xmonad.extraPackages
results in the evaluation error:
error: value is a list while a set was expected, at nixpkgs/lib/options.nix:77:23
With this patch we get the desired merging behaviour that just concatenates the
resulting package lists.
(cherry picked from commit 6e99f9fdecb1f28308c8e0aed0fc851737354864)
Co-Authored-By: Silvan Mosberger <contact@infinisil.com>
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
Declaring them as lists enables the concatenation, supporting
lib.mkBefore, lib.mkOrder, etc.
This is useful when you need to extend a service with a pre-start
script that needs to run as root.
Judging from `"${pkgs.element-web}/config.sample.json"`,
this needs be a URL starting with `https://`; without it one gets:
Your Element is misconfigured
Invalid base_url for m.homeserver
Use new command-line flags of release 0.3.0 and always answer with the
expected XML in the VM test instead of using a test-specific fixed path.
Co-authored-by: ajs124 <git@ajs124.de>
In the default configuration we have timers for creating and deleting
snapper snapshots, and it looks like if we just create configs with
correct mountpoints we will get automatic snapshots (which either
used to be true, or seems to be only true on Archlinux according to
their wiki). In default snapper configuration TIMELINE_CREATE and
TIMELINE_CLEANUP are set to "no", so just providing configs won't
be enough for having automatic backups, which are the main usecase
for snapper. In other linux distributions you would use `snapper
create-config` to generate configs for partitions and you'd have a
chance to notice that TIMELINE_CREATE is set to no. Also, my guess is
that it might be set to no by default for safety reasons in regular distros,
so that the config won't be actioned upon until the user finishes
customizing it.
If the machine is powered off when the zpool-trim timer is supposed to
trigger (usually around midnight) then the timer will be skipped
outright in favor of the next instance.
For desktop systems which are usually powered off at this time, zpool
trimming will never be run which can degrade SSD performance.
By marking the timer as `Persistent = yes` we ensure that it will run at
the first possible opportunity after the trigger date is reached.
Minimal ISO:
1m21 -> 2m25
625M -> 617M
Plasma5 ISO:
2m45 -> 5m18
1.4G -> 1.3G
Decompression speed stays about the same. It's just a few seconds for the whole
image anyways and, with that kind of speed, you're going to be bottlenecked by
IO long before the CPU.
The socketActivation option was removed, but later on socket activation
was added back without the option to disable it. The description now reflects
that socket activation is used unconditionally in the current setup.
Added JWT_SECRET and INTERNAL_TOKEN to be persistent, like SECRET_KEY and LFS_JWT_SECRET do. Also renamed some vars belonging to SECRET_KEY and LFS_JWT_SECRET to get a consistent naming scheme over all secrets.
Since the introduction of option `containers.<name>.pkgs`, the
`nixpkgs.*` options (including `nixpkgs.pkgs`, `nixpkgs.config`, ...) were always
ignored in container configs, which broke existing containers.
This was due to `containers.<name>.pkgs` having two separate effects:
(1) It sets the source for the modules that are used to evaluate the container.
(2) It sets the `pkgs` arg (`_module.args.pkgs`) that is used inside the container
modules.
This happens even when the default value of `containers.<name>.pkgs` is unchanged, in which
case the container `pkgs` arg is set to the pkgs of the host system.
Previously, the `pkgs` arg was determined by the `containers.<name>.config.nixpkgs.*` options.
This commit reverts the breaking change (2) while adding a backwards-compatible way to achieve (1).
It removes option `pkgs` and adds option `nixpkgs` which implements (1).
Existing users of `pkgs` are informed by an error message to use option
`nixpkgs` or to achieve only (2) by setting option `containers.<name>.config.nixpkgs.pkgs`.
The comment at the top of git-and-tools/default.nix said:
/* All git-relates tools live here, in a separate attribute set so that users
* can get a fast overview over what's available.
but unfortunately that hasn't actually held up in practice.
Git-related packages have continued to be added to the top level, or
into gitAndTools, or sometimes both, basically at random, so having
gitAndTools is just confusing. In fact, until I looked as part of
working on getting rid of gitAndTools, one program (ydiff) was
packaged twice independently, once in gitAndTools and once at the top
level (I fixed this in 98c3490196).
So I think it's for the best if we move away from gitAndTools, and
just put all the packages it previously contained at the top level.
I've implemented this here by just making gitAndTools an alias for the
top level -- this saves having loads of lines in aliases.nix. This
means that people can keep referring to gitAndTools in their
configuration, but it won't be allowed to be used within Nixpkgs, and
it won't be presented to new users by e.g. nix search.
The only other change here that I'm aware of is that
appendToName "minimal" is not longer called on the default git
package, because doing that would have necessitated having a private
gitBase variable like before. I think it makes more sense not to do
that anyway, and reserve the "minimal" suffix only for gitMinimal.
Now that smtp_tls_security_level is using mkDefault, and therefore can
be overridden, there's no need for an option for overriding it to a
specific value.
I run Postfix on my workstation as a smarthost, where it only ever
talks to my SMTP server. Because I know it'll only ever connect to
this server, and because I know this server supports TLS, I'd like to
set smtp_tls_security_level to "encrypt" so Postfix won't fall back to
an unencrypted connection.
With libcap 2.41 the output of cap_to_text changed, also the original
author of code hoped that this would never happen.
To counter this now the security-wrapper only relies on the syscall
ABI, which is more stable and robust than string parsing. If new
breakages occur this will be more obvious because version numbers will
be incremented.
Furthermore all errors no make execution explicitly fail instead of
hiding errors behind debug environment variables and the code style was
more consistent with no goto fail; goto fail; vulnerabilities (https://gotofail.com/)
