The host id value gets generated by reading a 32-bit value from
/dev/urandom.
This makes programs that rely on a correct host id more reliable.
It also makes using ZFS more seamless, as you don't need to configure
the hostId manually; instead, it becomes part of your config from the
moment you install NixOS.
The old boot.spl.hostid option was not working correctly due to an
upstream bug.
Instead, now we will create the /etc/hostid file so that all applications
(including the ZFS kernel modules, ZFS user-space applications and other
unrelated programs) pick-up the same system-wide host id. Note that glibc
(and by extension, the `hostid` program) also respect the host id configured in
/etc/hostid, if it exists.
The hostid option is now mandatory when using ZFS because otherwise, ZFS will
require you to force-import your ZFS pools if you want to use them, which is
undesirable because it disables some of the checks that ZFS does to make sure it
is safe to import a ZFS pool.
The /etc/hostid file must also exist when booting the initrd, before the SPL
kernel module is loaded, so that ZFS picks up the hostid correctly.
The complexity in creating the /etc/hostid file is due to having to
write the host ID as a 32-bit binary value, taking into account the
endianness of the machine, while using only shell commands and/or simple
utilities (to avoid exploding the size of the initrd).
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
Also remove custom zfs services from NixOS. This makes NixOS more aligned with
upstream.
More importantly, it prepares the way for NixOS to use ZED (the ZFS event
daemon). This service will automatically be enabled but it is not possible to
configure it via configuration.nix yet.
The dnscrypt-proxy service relays regular DNS queries to
a DNSCrypt enabled upstream resolver.
The traffic between the client and the upstream resolver is
encrypted and authenticated, which may mitigate the risk of
MITM attacks and third-party snooping (assuming a trustworthy
upstream).
Though dnscrypt-proxy can run as a standalone DNS client,
the recommended setup is to use it as a forwarder for a
caching DNS client.
To use dnscrypt-proxy as a forwarder for dnsmasq, do
```nix
{
# ...
networking.nameservers = [ "127.0.0.1" ];
networking.dhcpcd.extraConfig = "nohook resolv.conf";
services.dnscrypt-proxy.enable = true;
services.dnscrypt-proxy.localAddress = "127.0.0.1";
services.dnscrypt-proxy.port = 40;
services.dnsmasq.enable = true;
services.dnsmasq.extraConfig = ''
no-resolv
server=127.0.0.1#40
listen-address=127.0.0.1
'';
# ...
}
```
Perl seems to write the file in latin1 independent of the actual input
encoding. This can corrupt the "description" field of /etc/passwd. By
setting "binmode" to ":utf8" Perl can be forced to write UTF-8. Ideally
the program would simply read/write the fields by value without any
changes in encoding. However, assuming/enforcing UTF-8 is a lot better
than using an obsolete coding like latin1.
Regression introduced in f496c3cbe4.
Previously when we used security.initialRootPassword, the default
priority for this option was 1001, because it was a default value set by
the option itself.
With the mentioned commit, it is no longer an option default but a
mkDefault, which is priority 1000.
I'm setting this to 150 now, as test-instrumentation.nix is using this
for overriding other options and because I think it still makes it
possible to simple-override it, because if no priority is given, we get
priority 100.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
In this case, they're equivalent to setting ‘password’ and
‘hashedPassword’ (since there is no distinction between an initial and
non-initial user account state).
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.
from sudoers (5):
When multiple entries match for a user, they are applied in order.
Where there are multiple matches, the last match is used (which is not necessarily the most specific match).
I'm not sure what exactly this user is needed for, i.e. under what circumstances
it must exist or not, but creating it unconditionally seems like the wrong thing
to do. I complained to @offlinehacker about this on Github, but got no response
for a week or so. I'm disabling the extraUsers bit to put out the fire, and now
hope that someone who actually knows about Graphite implements a proper solution
later.
I.e. don't call "passwd" to update /etc/shadow from the "password"
option. This has the side-effect of not updating the password if
mutableUsers = true (since the code path for "hashedPassword" has a
check for mutableUsers).
Fixes#4747.
images. Root disks are now SSD backed and 20GB by default, both on hvm and pv-grub
(previously was 8GB for HVM). Added new eu-central region to the locations to copy images
to. Also the root disk for HVM instances was not deleted on termination with previous
images, this is fixed as well.
Partially and temporarily addresses NixOS/nixops#228.
We now have an up-to-date version of Blivet and a bunch of its dependen-
cies as well as the old nixpart 0.4 with all its old and crappy
dependencies, which should fix _simple_ partitioning layouts for NixOps.
Also, nixpart 1.0 is now marked as broken, because it is not yet
released and this branch is more of a preparation and "damage control"
in case I shouldn't manage to finish nixpart + nixos-assimilate in time
for the next NixOS release.
Once nixpart 1.0 is released we then only need to delete one single
directory rather than searching for needles in a haystack, that is, all
of <nixpkgs>. Also, it keeps my sanity at an almost healthy level.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Quite a mess but at least the mdraid tests succeed now. However, the
lvm2 tests are still failing, so we need to bring back a few more old
crap :-(
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm really not sure whether these tests are actually run upstream,
because there are quite a few oddities which either are my fault by just
missing something important or upstream really doesn't bother to run
those tests.
One example of this are testDiskChunk1 and testDiskChunk2, which create
two non-existing partitions and tries to allocate them. Now, in
allocatePartitions(), the partedPartition attributes are reset to None
and shortly afterwards a for loop is expecting it to be NOT None.
So, for now I'm disabling these tests and will see if we stumble on them
during work on nixpart 1.0, so we're really sure whether it's my fault
or a real bug in blivet.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm not using JFS, but this is to mainly make jfsutils available if you
have defined a JFS filesystem in your configuration.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Put a copy of old version 0.17 expression into 0.17.nix and update the
pointers from nixpart0 accordingly.
This also means, that plain nixpart is now way more broken than
nixpart0 (we might want to temporarily fix 0.4 anyway).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This helps in setting a fixed firewall open port for NFS lockd.
Based on:
http://rlworkman.net/howtos/NFS_Firewall_HOWTO
(cherry picked from commit b32ca0616ff70795f71995fa79ea508b82f30b3a)
Conflicts:
nixos/modules/services/network-filesystems/nfsd.nix
This causes some cruft to be uploaded (such as unit files) but it
ensures that every package used by the base system ends up in the
channel, not just environment.systemPackages.
(cherry picked from commit 4dfca8e14a5d1c2e62bb5ad267163a7a32ef872f)
This channel only builds a small subset of Nixpkgs, mostly suitable
for servers. Since the channel update doesn't require thousands of
packages to be built first, it should provide much faster turnaround
in case of security updates.
(cherry picked from commit 2c7acc6731ad4b05b1bbc3e632cdfcad4560ac22)
This option makes the coupling between lighttpd and its sub-services
more "loose".
While the option is a list, its purpose is to provide a "set" of needed
modules to load for lighttpd to function correctly with its config. The
NixOS lighttpd module ensures that lighttpd modules are loaded no more
than once (because lighttpd dislikes that), and in the correct order.
Also add an assertion that all modules listed in .enableModules are
valid.
Any reasonably new version of fontconfig does search that path by default,
and setting this globally causes problems, as 2.10 and 2.11 need
incompatible configs.
Tested: slim+xfce desktop, chrootenv-ed steam.
I have no idea why we were setting the global variable;
e.g., neither Fedora nor Ubuntu does that.
This commit updates the stumpwm to version 0.9.8. Futhermore, it
refactors the expression quite a lot:
* stumpwm has been moved from lisp modules to window-managers.
* stumpwm has been added to the window managers NixOS knows about, this
enables the user to add stumpwm as a default window manager in his
NixOS configuration like with Xmonad or i3.
* the package has been split into stumpwm and stumpwmContrib. This is
due to the fact that development of stumpwm and its extension modules
has been split into two repositories. As of today, the release is the
last one before this split. This split into two packages only reflect
those upcoming upstream changes already.
It is planned to make the addition of the extension modules voluntarily,
like with Xmonads option "enableContribAndExtras". Furthermore it might
be possible to add an option to compile stumpwm with clisp instead of
sbcl.
This allows you to configure extra files that should be appended to your
crontab. Implemented by writing to /etc/crontab when the cron service starts.
Would be nicer to use a cron that supports /etc/cron.d but that would require
us to patch vixie-cron.
This prevents a dependency on liblapack (which randomly fails) and
TeXlive (which is huge).
http://hydra.nixos.org/build/14897240
(cherry picked from commit b9bde98161d09496421efbaafe5219cc84d05f5b)
