I think pam_lastlog is the only thing that writes to these files in
practice on a modern Linux system, so in a configuration that doesn't
use that module, we don't need to create these files.
I used tmpfiles.d instead of activation snippets to create the logs.
It's good enough for upstream and other distros; it's probably good
enough for us.
Nix 2.0 no longer uses these directories.
/run/nix/current-load was moved to /nix/var/nix/current-load in 2017
(Nix commit d7653dfc6dea076ecbe00520c6137977e0fced35). Anyway,
src/build-remote/build-remote.cc will create the current-load directory
if it doesn't exist already.
/run/nix/remote-stores seems to have been deprecated since 2014 (Nix
commit b1af336132cfe8a6e4c54912cc512f8c28d4ebf3) when the documentation
for $NIX_OTHER_STORES was removed, and support for it was dropped
entirely in 2016 (Nix commit 4494000e04122f24558e1436e66d20d89028b4bd).
The default value for journald's Storage option is "auto", which
determines whether to log to /var/log/journal based on whether that
directory already exists. So NixOS has been unconditionally creating
that directory in activation scripts.
However, we can get the same behavior by configuring journald.conf to
set Storage to "persistent" instead. In that case, journald will create
the directory itself if necessary.
Previously, the activation script was responsible for ensuring that
/etc/machine-id exists. However, the only time it could not already
exist is during stage-2-init, not while switching configurations,
because one of the first things systemd does when starting up as PID 1
is to create this file. So I've moved the initialization to
stage-2-init.
Furthermore, since systemd will do the equivalent of
systemd-machine-id-setup if /etc/machine-id doesn't have valid contents,
we don't need to do that ourselves.
We _do_, however, want to ensure that the file at least exists, because
systemd also uses the non-existence of this file to guess that this is a
first-boot situation. In that case, systemd tries to create some
symlinks in /etc/systemd/system according to its presets, which it can't
do because we've already populated /etc according to the current NixOS
configuration.
This is not necessary for any other activation script snippets, so it's
okay to do it after stage-2-init runs the activation script. None of
them declare a dependency on the "systemd" snippet. Also, most of them
only create files or directories in ways that obviously don't need the
machine-id set.
As far as I can tell, the systemd snippet hasn't depended on groups
being initialized since 5d02c02a9bfd6912e4e0f700b1b35e76d1d6bd3f in
2015, when a `setfacl` call was removed.
Changes the evaluation order in that it evaluates assertions before
warnings, so that eg. the following would work:
{ config, lib, ... }:
{
options.foo = lib.mkOption {
type = lib.types.bool;
default = true;
description = "...";
};
options.bar = lib.mkOption {
type = lib.types.bool;
default = false;
description = "...";
};
config = lib.mkMerge [
(lib.mkIf config.bar {
system.build.bar = "foobar";
})
(lib.mkIf config.foo {
assertions = lib.singleton {
assertion = config.bar;
message = "Bar needs to be enabled";
};
systemd.services.foo = {
description = "Foo";
serviceConfig.ExecStart = config.system.build.bar;
};
})
];
}
This is because the systemd module includes definitions for warnings
that would trigger evaluation of the config.system.build.bar definition.
The original pull request references a breakage due to the following:
{
services.nixosManual.enable = false;
services.nixosManual.showManual = true;
}
However, changing the eval order between asserts and warnings clearly is
a corner case here and it only happens because of the aforementioned
usage of warnings in the systemd module and needs more discussion.
Nevertheless, this is still useful because it lowers the evaluation time
whenever an assertion is hit, which is a hard failure anyway.
Introduced by 0f3b89bbedc1a33cc1fc3c142e235da2c64614c3.
If services.nixosManual.showManual is enabled and
documentation.nixos.enable is not, there is no
config.system.build.manual available, so evaluation fails. For example
this is the case for the installer tests.
There is however an assertion which should catch exactly this, but it
isn't thrown because the usage of config.system.build.manual is
evaluated earlier than the assertions.
So I split the assertion off into a separate mkIf to make sure it is
shown appropriately and also fixed the installation-device profile to
enable documentation.nixos.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @oxij
- Use socket-activated epmd - that way there won't be any trouble when
more than one erlang system is used within a single host.
- Use new automation-friendly configuration file format
- Use systemd notifications instead of buggy 'rabbitmqctl wait' for
confirming successful server startup.
'wait' bug: https://github.com/rabbitmq/rabbitmq-server/issues/463
- Use 'rabbitmqctl shutdown' instead of 'stop', because it's not
pid-file based
- Use sane systemd unit defaults from RabbitMQ repo:
https://github.com/rabbitmq/rabbitmq-server/blob/master/docs/rabbitmq-server.service.example
- Support for external plugins
This reverts commit f777d2b719be0db4cb7819d5b6dbdd121db29a37.
cc #34409
This breaks evaluation of the tested job:
attribute 'diskInterface' missing, at /nix/store/5k9kk52bv6zsvsyyvpxhm8xmwyn2yjvx-source/pkgs/build-support/vm/default.nix:316:24
Most importantly, this sets PrivateTmp, ProtectHome, and ProtectSystem
so that Chrony flaws are mitigated, should they occur.
Moving to ProtectSystem=full however, requires moving the chrony key
files under /var/lib/chrony -- which should be fine, anyway.
This also ensures ConditionCapability=CAP_SYS_TIME is set, ensuring
that chronyd will only be launched in an environment where such a
capability can be granted.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
or else at least the following config will fail with an evaluation error
instead of an assert
```
{
services.nixosManual.enable = false;
services.nixosManual.showManual = true;
}
```
This reverts commit 67c8c4917799496dcf2ad6a500441fbbaeb918c9.
'nix run nixos.firefox' is *not* supposed to work - the Nix 2.x
interface attempts to standardize on nixpkgs.*, to get rid of the
nixos/nixpkgs confusion that existed with the channels interface. So
let's not bring that confusion back.
Because when I see "config.system.build.manual.manual" after I forgot
what it means I ask "Why do I need that second `.manual` there again?".
Doesn't happen with `config.system.build.manual.manualHTML`.
Without this the graphical installer has no way to open the manual.
You can fix it yourself by installing any HTML browser but this might
be unfamiliar to users new to NixOS and without any other way to open
the manual. The downside is it will also increase download sizes.
Fixes#46537
/run/rmilter is set by systemd, and have root:root ownership, which
prevent pid file to write.
This fix suggested to be promoted to 18.09 branch.
(Although rmilter itself is deprecated, and I plan to remove it, after
18.09 would be released)
