Platform support: x86_64-linux and x86_64-darwin as always. Support for aarch64-linux is as with the previous releases, not equivalent to the x86-64-linux release, but with efforts to reach parity.
User channels are now in the default <literal>NIX_PATH</literal>, allowing users to use their personal <command>nix-channel</command> defined channels in <command>nix-build</command> and <command>nix-shell</command> commands, as well as in imports like <code>import <mychannel></code>.
The <varname>services.cassandra</varname> module has been reworked and was rewritten from scratch. The service has succeeding tests for the versions 2.1, 2.2, 3.0 and 3.11 of <link
There is a new <varname>services.foundationdb</varname> module for deploying <linkxlink:href="https://www.foundationdb.org">FoundationDB</link> clusters.
When enabled the <literal>iproute2</literal> will copy the files expected by ip route (e.g., <filename>rt_tables</filename>) in <filename>/etc/iproute2</filename>. This allows to write aliases for routing tables for instance.
<varname>services.strongswan-swanctl</varname> is a modern replacement for <varname>services.strongswan</varname>. You can use either one of them to setup IPsec VPNs but not both at the same time.
<varname>services.strongswan-swanctl</varname> uses the <linkxlink:href="https://wiki.strongswan.org/projects/strongswan/wiki/swanctl">swanctl</link> command which uses the modern <linkxlink:href="https://github.com/strongswan/strongswan/blob/master/src/libcharon/plugins/vici/README.md">vici</link><emphasis>Versatile IKE Configuration Interface</emphasis>. The deprecated <literal>ipsec</literal> command used in <varname>services.strongswan</varname> is using the legacy <linkxlink:href="https://github.com/strongswan/strongswan/blob/master/README_LEGACY.md">stroke configuration interface</link>.
The <literal>clementine</literal> package points now to the free derivation. <literal>clementineFree</literal> is removed now and <literal>clementineUnfree</literal> points to the package which is bundled with the unfree <literal>libspotify</literal> package.
The <literal>netcat</literal> package is now taken directly from OpenBSD's <literal>libressl</literal>, instead of relying on Debian's fork. The new version should be very close to the old version, but there are some minor differences. Importantly, flags like -b, -q, -C, and -Z are no longer accepted by the nc command.
The <varname>services.docker-registry.extraConfig</varname> object doesn't contain environment variables anymore. Instead it needs to provide an object structure that can be mapped onto the YAML configuration defined in <linkxlink:href="https://github.com/docker/distribution/blob/v2.6.2/docs/configuration.md">the <varname>docker/distribution</varname> docs</link>.
<literal>gnucash</literal> has changed from version 2.4 to 3.x. If you've been using <literal>gnucash</literal> (version 2.4) instead of <literal>gnucash26</literal> (version 2.6) you must open your Gnucash data file(s) with <literal>gnucash26</literal> and then save them to upgrade the file format. Then you may use your data file(s) with Gnucash 3.x. See the upgrade <linkxlink:href="https://wiki.gnucash.org/wiki/FAQ#Using_Different_Versions.2C_Up_And_Downgrade">documentation</link>. Gnucash 2.4 is still available under the attribute <literal>gnucash24</literal>.
<varname>services.munge</varname> now runs as user (and group) <literal>munge</literal> instead of root. Make sure the key file is accessible to the daemon.
<varname>dockerTools.buildImage</varname> now uses <literal>null</literal> as default value for <varname>tag</varname>, which indicates that the nix output hash will be used as tag.
The ELK stack: <varname>elasticsearch</varname>, <varname>logstash</varname> and <varname>kibana</varname> has been upgraded from 2.* to 6.3.*. The 2.* versions have been <linkxlink:href="https://www.elastic.co/support/eol">unsupported since last year</link> so they have been removed. You can still use the 5.* versions under the names <varname>elasticsearch5</varname>, <varname>logstash5</varname> and <varname>kibana5</varname>.
The elastic beats: <varname>filebeat</varname>, <varname>heartbeat</varname>, <varname>metricbeat</varname> and <varname>packetbeat</varname> have had the same treatment: they now target 6.3.* as well. The 5.* versions are available under the names: <varname>filebeat5</varname>, <varname>heartbeat5</varname>, <varname>metricbeat5</varname> and <varname>packetbeat5</varname>
The ELK-6.3 stack now comes with <linkxlink:href="https://www.elastic.co/products/x-pack/open">X-Pack by default</link>. Since X-Pack is licensed under the <linkxlink:href="https://github.com/elastic/elasticsearch/blob/master/licenses/ELASTIC-LICENSE.txt">Elastic License</link> the ELK packages now have an unfree license. To use them you need to specify <literal>allowUnfree = true;</literal> in your nixpkgs configuration.
Fortunately there is also a free variant of the ELK stack without X-Pack. The packages are available under the names: <varname>elasticsearch-oss</varname>, <varname>logstash-oss</varname> and <varname>kibana-oss</varname>.
Options <literal>boot.initrd.luks.devices.<replaceable>name</replaceable>.yubikey.ramfsMountPoint</literal><literal>boot.initrd.luks.devices.<replaceable>name</replaceable>.yubikey.storage.mountPoint</literal> were removed. <literal>luksroot.nix</literal> module never supported more than one YubiKey at a time anyway, hence those options never had any effect. You should be able to remove them from your config without any issues.
<literal>stdenv.system</literal> and <literal>system</literal> in nixpkgs now refer to the host platform instead of the build platform. For native builds this is not change, let alone a breaking one. For cross builds, it is a breaking change, and <literal>stdenv.buildPlatform.system</literal> can be used instead for the old behavior. They should be using that anyways for clarity.
<literal>dockerTools.pullImage</literal> relies on image digest instead of image tag to download the image. The <literal>sha256</literal> of a pulled image has to be updated.
The <literal>pkgs</literal> argument to NixOS modules can now be set directly using <literal>nixpkgs.pkgs</literal>. Previously, only the <literal>system</literal>, <literal>config</literal> and <literal>overlays</literal> arguments could be used to influence <literal>pkgs</literal>.
This benefits evaluation performance, lets you write Nixpkgs packages that depend on NixOS images and is consistent with a deployment architecture that would be centered around Nixpkgs overlays.
The attribute <literal>lib.nixpkgsVersion</literal> has been deprecated in favor of <literal>lib.version</literal>. Please refer to the discussion in <linkxlink:href="https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745">NixOS/nixpkgs#39416</link> for further reference.
<literal>lib.recursiveUpdateUntil</literal> was not acting according to its specification. It has been fixed to act according to the docstring, and a test has been added.
Puts the generated Diffie-Hellman parameters into the Nix store instead of managing them in a stateful manner in <filenameclass="directory">/var/lib/dhparams</filename>.
The path to the actual generated parameter files should now be queried using <literal>config.security.dhparams.params.<replaceable>name</replaceable>.path</literal> because it might be either in the Nix store or in a directory configured by <option>security.dhparams.path</option>.
Module implementers should not set a specific bit size in order to let users configure it by themselves if they want to have a different bit size than the default (2048).
The Kubernetes package has been bumped to major version 1.11. Please consult the <linkxlink:href="https://github.com/kubernetes/kubernetes/blob/release-1.11/CHANGELOG-1.11.md">release notes</link> for details on new features and api changes.
The option <varname>services.kubernetes.apiserver.admissionControl</varname> was renamed to <varname>services.kubernetes.apiserver.enableAdmissionPlugins</varname>.
Recommended way to access the Kubernetes Dashboard is via HTTPS (TLS) Therefore; public service port for the dashboard has changed to 443 (container port 8443) and scheme to https.
The option <varname>services.kubernetes.apiserver.address</varname> was renamed to <varname>services.kubernetes.apiserver.bindAddress</varname>. Note that the default value has changed from 127.0.0.1 to 0.0.0.0.
The option <varname>services.kubernetes.addons.dashboard.enableRBAC</varname> was renamed to <varname>services.kubernetes.addons.dashboard.rbac.enable</varname>.
The Kubernetes Dashboard now has only minimal RBAC permissions by default. If dashboard cluster-admin rights are desired, set <varname>services.kubernetes.addons.dashboard.rbac.clusterAdmin</varname> to true. On existing clusters, in order for the revocation of privileges to take effect, the current ClusterRoleBinding for kubernetes-dashboard must be manually removed: <literal>kubectl delete clusterrolebinding kubernetes-dashboard</literal>
The <varname>programs.screen</varname> module provides allows to configure <literal>/etc/screenrc</literal>, however the module behaved fairly counterintuitive as the config exists, but the package wasn't available. Since 18.09 <literal>pkgs.screen</literal> will be added to <literal>environment.systemPackages</literal>.
<varname>s6Dns</varname>, <varname>s6Networking</varname>, <varname>s6LinuxUtils</varname> and <varname>s6PortableUtils</varname> renamed to <varname>s6-dns</varname>, <varname>s6-networking</varname>, <varname>s6-linux-utils</varname> and <varname>s6-portable-utils</varname> respectively.
The config activation script of <literal>nixos-rebuild</literal> now <linkxlink:href="https://www.freedesktop.org/software/systemd/man/systemctl.html#Manager%20Lifecycle%20Commands">reloads</link> all user units for each authenticated user.
NixOS option descriptions are now automatically broken up into individual paragraphs if the text contains two consecutive newlines, so it's no longer necessary to use <code></para><para></code> to start a new paragraph.
Top-level <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and <literal>targetPlatform</literal> in Nixpkgs are deprecated. Please use their equivalents in <literal>stdenv</literal> instead: <literal>stdenv.buildPlatform</literal>, <literal>stdenv.hostPlatform</literal>, and <literal>stdenv.targetPlatform</literal>.