Specifically, this fixes dnsmasq, which failed with
Apr 16 19:00:30 mandark dnsmasq[23819]: dnsmasq: DBus error: Connection ":1.260" is not allowed to own the service "uk.org.thekelleys.dnsmasq" due to security policies in the configuration file
Apr 16 19:00:30 mandark dnsmasq[23819]: DBus error: Connection ":1.260" is not allowed to own the service "uk.org.thekelleys.dnsmasq" due to security policies in the configuration file
after being enabled, due to dbus not being reloaded.
Thanks to @domenkozar for implicitly reminding me that documentation is
probably our biggest issue. And I'm a dumbass for contributing to that
situation, so let's do better than that and document it.
The current changes are only preparation for a bigger change coming real
soon[TM] in Hydra and release-tools, so right now it's still a bit
tedious to create custom channels.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This option causes the specified user to be automatically logged in at
the virtual console.
While at it, refactor and make a helper function for building the getty
command line.
This partially reverts commit 3a4fd0bfc6.
Addresses another concern by @edolstra that users might not want to
update *all* channels. We're now reverting to the old behaviour but
after updating the "nixos" channel, we just check whether the channel
ships with a file called ".update-on-nixos-rebuild" and if it exists, we
update that channel as well.
Other channels than these are not touched anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
My original reason to put it at the beginning of NIX_PATH was to allow
shipping a particular version <nixpkgs> with a channel. But in order to
do that, we can still let the channel expression ship with a custom
version of nixpkgs by something like <channel/nixpkgs> and the builder
of the channel could also rewrite self-references.
So the inconvenience is now shifted towards the maintainer of the
channel rather than the user (which isn't nice, but better err on the
side of the developer rather than on the user), because as @edolstra
pointed out: Having the channels of root at the beginning of NIX_PATH
could have unintended side-effects if there a channel called nixpkgs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Should make it even easier to use custom channels, because whenever the
user does a "nixos-rebuild --upgrade", it will also upgrade possibly
used ("used" as in referenced in configuration.nix) channels besides
"nixos". And if you also ship a channel tied to a particular version of
nixpkgs or even remove the "nixos" channels, you won't run into
unexpected situations where the system is not updating your custom
channels.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is very useful if you want to distribute channels (and thus
expressions as well) in a similar fashion to Debians APT sources (or
PPAs or whatnot).
So, for example if you have a channel with some additional functions
or packages, you simply add that channel with:
sudo nix-channel --add https://example.com/my-nifty-channel foo
And you can access that channel using <foo>, for example in your
configuration.nix:
{
imports = [ <foo/modules/shiny-little-module> ];
environment.systemPackages = with import <foo/pkgs> {}; [ bar blah ];
services.udev.extraRules = import <foo/lib/udev/mkrule.nix> {
kernel = "eth*";
attr.address = "00:1D:60:B9:6D:4F";
name = "my_fast_network_card";
};
}
Within nixpkgs, we shouldn't have <nixos> used anywhere anymore, so we
shouldn't get into conflicts.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
If a kernel without CONFIG_UEVENT_HELPER set is used with NixOS, the file
/proc/sys/kernel/hotplug does not exist. Before writing to it to disable
this deprecated mechanism, we have to ensure it actually exists because
otherwise the activation script will fail.
This updates rdnssd to the following:
* Using the systemd interfaces directly
* Using the rdnssd user instead of the root user
* Integrating with resolvconf instead of writing directly to /etc/resolv.conf
The i686-linux test has never worked and I wrote the VM test only on
x86_64-linux to verify whether hardening mode works. I don't know why it
fails on i686-linux, but that might be because the inner VirtualBox VM
we're starting during the VM test doesn't use hardware virtualization.
Closes#5708.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Sometimes, keys aren't properly recognized the first time, so in order
to make sure they get through, always resend the key again on retry.
In this case the worst that could happen is that the VM is started over
and over again, but never in parallel, so that's fine because we're
checking for successful startup 10 seconds after the keypress.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It's not nice to send the escape key over and over again just to ensure
the popup is closed, because even *if* it fails to close the popup 4
times in a row it's just very unlikely that it will be closed. But in
order to make really sure, we might need to do a screenshot and detect
visual changes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is essentially what's been done for the official NixOS build slaves
and I'm using it as well for a few of my machines and my own Hydra
slaves.
Here's the same implementation from the Delft server configurations:
f47c2fc7f8/delft/common.nix (L91-L101)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Many bus clients get hopelessly confused when dbus-daemon is
restarted. So let's not do that.
Of course, this is not ideal either, because we end up stuck with a
possibly outdated dbus-daemon. But that issue will become irrelevant
in the glorious kdbus-based future.
Hopefully this also gets rid of systemd getting stuck after
dbus-daemon is restarted:
Apr 01 15:37:50 mandark systemd[1]: Failed to register match for Disconnected message: Connection timed out
Apr 01 15:37:50 mandark systemd[1]: Looping too fast. Throttling execution a little.
Apr 01 15:37:51 mandark systemd[1]: Looping too fast. Throttling execution a little.
...
It has been removed by 71a197bc6e.
I'm reintroducing the test mainly because it actually *is* useful,
because right now, machines with mdraid will not boot. In order to
prevent such things from happening in the future, we should *not* remove
this VM test again.
If it really goes back to failing randomly, we should really try to fix
it instead of removing it again.
Of course it fails right now because of the mdraid bump in 7719f7f.
Also, if you want to have additional info about the reasons, have a look
at the commit message of 666cf992f0.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm increasing it to 100MB to make sure, any bootloader will fit with
all its stages. Of course, right now the reason why GRUB doesn't fit
into the partition is because of mdadm 3.3.2 and thus the initrd taking
all the space, but in order to avoid confusion on why the *boot* loader
fails in the VM tests, I've increased the size.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
