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>
Fixes#6795.
This was co-authored with @bobvanderlinden.
(cherry picked from commit e19ac248ae59fd327c32b1ae3e37792c22a7c7ac)
Signed-off-by: Domen Kožar <domen@dev.si>
Conflicts:
nixos/modules/installer/cd-dvd/iso-image.nix
There are a number of hidden restrictions on the syslinux
configuration file that come into play when UNetbootin
compatiblity is desired. With this commit these are documented.
This changes the bootloader for iso generation from Grub to
syslinux. In addition this adds USB booting support, so that
"dd" can be used to burn the generated ISO to USB thumbdrives
instead of needing applications like UnetBootin.
The group is specified using a singleton list, so the loaOf merging is
done by iterating through the list items with imap, so it enumerates
every element and sets that as the default "name" attribute.
From lib/types:143:
name = elem.name or "unnamed-${toString defIdx}.${toString elemIdx}";
So, people get groups like "unnamed-X.Y" instead of "mpd".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: devhell <"^"@regexmail.net>
Tested-by: devhell <"^"@regexmail.net>
It now strictly evaluates all remaining attributes, preventing
unevaluated thunks that cannot be garbage-collected. It's also applied
to all jobs in Nixpkgs' release.nix.
This reduces hydra-eval-jobs' memory consumption on the 14.12
release-combined jobset from 5.1 GB to 2.0 GB.
Fixes the useless collisions in the system path.
The 64bit and 32bit variants have the same files, hence
it's pointless to put the 32bit pulseaudio in systemPackages.
The nixbld group doesn't need read permission, it only needs write and
execute permission.
(cherry picked from commit 066758758e7c0768ff8da51d208cdae0f33b368c)
Rather than using openssl to hash the password at build time, and hence
leaving the plaintext password world-readable in the nix store, we can
instead hash the password in the nix expression itself using
builtins.hashString.
This patch resolves all uid/gid conflicts except for nobody/nogroup (seems
to make sense that these are the same).
All conflicts where determined mechanically, but resolutions were manual.
This patch also marks uids/gids with no corresponding group/user as "unused"
(aka. reserved).
Briefly,
- tss group conflicts with dhcpcd
The tss group id conflicts with dhcpcd: assign
a new number and add a corresponding tss user.
- elasticsearch uid conflicts with haproxy gid
- resolve firebird/munin conflict
- fix fourstorehttp{,d} typo
- fix ghostOne typo: the service module refers to gids.ghostone, so use that
in ids
- memcached uid conflicts with users gid
- nagios uid conflicts with disks gid
- nscd uid conflicts with wheel gid
- ntp uid conflicts with tty gid
- resolve postfix/postdrop id uid
- redis uid conflicts with keys gid
- sshd uid conflicts with kmem gid
- tcryptd uid conflicts with openldap gid
- unifi uid conflicts with docker gid
- uptimed uid conflicts with utmp gid
- zope2 uid conflicts with connman gid
- tomcat uid/gid mismatch
