nixpkgs/nixos/doc/manual/release-notes/rl-1903.xml

692 lines
28 KiB
XML
Raw Normal View History

2018-09-02 21:17:59 +00:00
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="sec-release-19.03">
<title>Release 19.03 (“Koi”, 2019/03/??)</title>
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="sec-release-19.03-highlights">
<title>Highlights</title>
<para>
In addition to numerous new and upgraded packages, this release has the
following highlights:
</para>
<itemizedlist>
<listitem>
<para>
The default Python 3 interpreter is now CPython 3.7 instead of CPython 3.6.
2018-11-20 18:46:52 +00:00
</para>
2018-09-02 21:17:59 +00:00
</listitem>
2019-01-24 19:35:45 +00:00
<listitem>
<para>
Added the Pantheon desktop environment.
It can be enabled through <varname>services.xserver.desktopManager.pantheon.enable</varname>.
</para>
<note>
<para>
<varname>services.xserver.desktopManager.pantheon</varname> default enables lightdm
as a display manager and using Pantheon's greeter.
</para>
<para>
This is because of limitations with the screenlocking implementation, whereas the
screenlocker would be non-functional without it.
</para>
<para>
Because of that it is recommended to retain this precaution, however if you'd like to change this set:
</para>
<itemizedlist>
<listitem>
<para>
<option>services.xserver.displayManager.lightdm.enable</option>
</para>
</listitem>
<listitem>
<para>
<option>services.xserver.displayManager.lightdm.greeters.pantheon.enable</option>
</para>
</listitem>
</itemizedlist>
<para>to <literal>false</literal> and enable your preferred display manager.</para>
</note>
</listitem>
<listitem>
<para>
A major refactoring of the Kubernetes module has been completed.
Refactorings primarily focus on decoupling components and enhancing
security. Two-way TLS and RBAC has been enabled by default for all
components, which slightly changes the way the module is configured.
See: <xref linkend="sec-kubernetes"/> for details.
</para>
2019-01-24 19:35:45 +00:00
</listitem>
2018-09-02 21:17:59 +00:00
</itemizedlist>
</section>
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="sec-release-19.03-new-services">
<title>New Services</title>
<para>
The following new services were added since the last release:
</para>
<itemizedlist>
<listitem>
2018-12-02 11:18:47 +00:00
<para>
<literal>./programs/nm-applet.nix</literal>
</para>
2018-09-02 21:17:59 +00:00
</listitem>
<listitem>
<para>
There is a new <varname>security.googleOsLogin</varname> module for using
<link xlink:href="https://cloud.google.com/compute/docs/instances/managing-instance-access">OS Login</link>
to manage SSH access to Google Compute Engine instances, which supersedes
the imperative and broken <literal>google-accounts-daemon</literal> used
in <literal>nixos/modules/virtualisation/google-compute-config.nix</literal>.
</para>
</listitem>
<listitem>
<para>
<literal>./services/misc/beanstalkd.nix</literal>
</para>
</listitem>
<listitem>
<para>
There is a new <varname>services.cockroachdb</varname> module for running
CockroachDB databases. NixOS now ships with CockroachDB 2.1.x as well, available
on <literal>x86_64-linux</literal> and <literal>aarch64-linux</literal>.
</para>
</listitem>
2018-09-02 21:17:59 +00:00
</itemizedlist>
<itemizedlist>
<listitem>
<para>
<literal>./security/duosec.nix</literal>
</para>
</listitem>
<listitem>
<para>
The <link xlink:href="https://duo.com/docs/duounix">PAM module for Duo
Security</link> has been enabled for use. One can configure it using
the <option>security.duosec</option> options along with the
corresponding PAM option in
<option>security.pam.services.&lt;name?&gt;.duoSecurity.enable</option>.
</para>
</listitem>
</itemizedlist>
2018-09-02 21:17:59 +00:00
</section>
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
2018-09-23 20:18:59 +00:00
xml:id="sec-release-19.03-incompatibilities">
<title>Backward Incompatibilities</title>
<para>
When upgrading from a previous release, please be aware of the following
incompatible changes:
</para>
<itemizedlist>
<listitem>
<para>
The minimum version of Nix required to evaluate Nixpkgs is now 2.0.
</para>
<itemizedlist>
<listitem>
<para>
For users of NixOS 18.03 and 19.03, NixOS defaults to Nix 2.0, but
supports using Nix 1.11 by setting <literal>nix.package =
pkgs.nix1;</literal>. If this option is set to a Nix 1.11 package, you
will need to either unset the option or upgrade it to Nix 2.0.
</para>
</listitem>
<listitem>
<para>
For users of NixOS 17.09, you will first need to upgrade Nix by setting
<literal>nix.package = pkgs.nixStable2;</literal> and run
<command>nixos-rebuild switch</command> as the <literal>root</literal>
user.
</para>
</listitem>
<listitem>
<para>
For users of a daemon-less Nix installation on Linux or macOS, you can
upgrade Nix by running <command>curl https://nixos.org/nix/install |
sh</command>, or prior to doing a channel update, running
<command>nix-env -iA nix</command>.
</para>
<para>
If you have already run a channel update and Nix is no longer able to
evaluate Nixpkgs, the error message printed should provide adequate
directions for upgrading Nix.
</para>
</listitem>
<listitem>
<para>
For users of the Nix daemon on macOS, you can upgrade Nix by running
<command>sudo -i sh -c 'nix-channel --update &amp;&amp; nix-env -iA
nixpkgs.nix'; sudo launchctl stop org.nixos.nix-daemon; sudo launchctl
start org.nixos.nix-daemon</command>.
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
The <varname>buildPythonPackage</varname> function now sets <varname>strictDeps = true</varname>
2019-01-05 09:26:57 +00:00
to help distinguish between native and non-native dependencies in order to
improve cross-compilation compatibility. Note however that this may break
user expressions.
</para>
</listitem>
<listitem>
<para>
The <varname>buildPythonPackage</varname> function now sets <varname>LANG = C.UTF-8</varname>
to enable Unicode support. The <varname>glibcLocales</varname> package is no longer needed as a build input.
</para>
</listitem>
<listitem>
<para>
The Syncthing state and configuration data has been moved from
<varname>services.syncthing.dataDir</varname> to the newly defined
<varname>services.syncthing.configDir</varname>, which default to
<literal>/var/lib/syncthing/.config/syncthing</literal>.
This change makes possible to share synced directories using ACLs
without Syncthing resetting the permission on every start.
</para>
</listitem>
<listitem>
<para>
The <literal>ntp</literal> module now has sane default restrictions.
If you're relying on the previous defaults, which permitted all queries
and commands from all firewall-permitted sources, you can set
<varname>services.ntp.restrictDefault</varname> and
<varname>services.ntp.restrictSource</varname> to
<literal>[]</literal>.
</para>
</listitem>
<listitem>
2018-09-30 00:51:11 +00:00
<para>
Package <varname>rabbitmq_server</varname> is renamed to
<varname>rabbitmq-server</varname>.
</para>
</listitem>
<listitem>
2018-10-15 13:48:28 +00:00
<para>
The <literal>light</literal> module no longer uses setuid binaries, but
udev rules. As a consequence users of that module have to belong to the
<literal>video</literal> group in order to use the executable (i.e.
<literal>users.users.yourusername.extraGroups = ["video"];</literal>).
</para>
</listitem>
2017-12-17 04:06:43 +00:00
<listitem>
<para>
Buildbot now supports Python 3 and its packages have been moved to
<literal>pythonPackages</literal>. The options
<option>services.buildbot-master.package</option> and
<option>services.buildbot-worker.package</option> can be used to select
the Python 2 or 3 version of the package.
</para>
</listitem>
<listitem>
<para>
Options
<literal>services.znc.confOptions.networks.<replaceable>name</replaceable>.userName</literal> and
<literal>services.znc.confOptions.networks.<replaceable>name</replaceable>.modulePackages</literal>
were removed. They were never used for anything and can therefore safely be removed.
</para>
</listitem>
<listitem>
<para>
Package <literal>wasm</literal> has been renamed <literal>proglodyte-wasm</literal>. The package
<literal>wasm</literal> will be pointed to <literal>ocamlPackages.wasm</literal> in 19.09, so
make sure to update your configuration if you want to keep <literal>proglodyte-wasm</literal>
</para>
</listitem>
2018-10-23 15:07:17 +00:00
<listitem>
<para>
When the <literal>nixpkgs.pkgs</literal> option is set, NixOS will no
longer ignore the <literal>nixpkgs.overlays</literal> option. The old
behavior can be recovered by setting <literal>nixpkgs.overlays =
lib.mkForce [];</literal>.
</para>
</listitem>
2018-10-23 15:07:17 +00:00
<listitem>
<para>
OpenSMTPD has been upgraded to version 6.4.0p1. This release makes
backwards-incompatible changes to the configuration file format. See
<command>man smtpd.conf</command> for more information on the new file
format.
</para>
</listitem>
<listitem>
<para>
The versioned <varname>postgresql</varname> have been renamed to use
underscore number seperators. For example, <varname>postgresql96</varname>
has been renamed to <varname>postgresql_9_6</varname>.
</para>
</listitem>
<listitem>
<para>
Package <literal>consul-ui</literal> and passthrough <literal>consul.ui</literal> have been removed.
The package <literal>consul</literal> now uses upstream releases that vendor the UI into the binary.
See <link xlink:href="https://github.com/NixOS/nixpkgs/pull/48714#issuecomment-433454834">#48714</link>
for details.
</para>
</listitem>
<listitem>
<para>
Slurm introduces the new option
<literal>services.slurm.stateSaveLocation</literal>,
which is now set to <literal>/var/spool/slurm</literal> by default
(instead of <literal>/var/spool</literal>).
Make sure to move all files to the new directory or to set the option accordingly.
</para>
<para>
The slurmctld now runs as user <literal>slurm</literal> instead of <literal>root</literal>.
If you want to keep slurmctld running as <literal>root</literal>, set
<literal>services.slurm.user = root</literal>.
</para>
<para>
The options <literal>services.slurm.nodeName</literal> and
<literal>services.slurm.partitionName</literal> are now sets of
strings to correctly reflect that fact that each of these
options can occour more than once in the configuration.
</para>
</listitem>
<listitem>
<para>
The <literal>solr</literal> package has been upgraded from 4.10.3 to 7.5.0 and has undergone
some major changes. The <literal>services.solr</literal> module has been updated to reflect
these changes. Please review http://lucene.apache.org/solr/ carefully before upgrading.
</para>
</listitem>
<listitem>
<para>
Package <literal>ckb</literal> is renamed to <literal>ckb-next</literal>,
and options <literal>hardware.ckb.*</literal> are renamed to
<literal>hardware.ckb-next.*</literal>.
</para>
</listitem>
<listitem>
<para>
The option <literal>services.xserver.displayManager.job.logToFile</literal> which was
previously set to <literal>true</literal> when using the display managers
<literal>lightdm</literal>, <literal>sddm</literal> or <literal>xpra</literal> has been
reset to the default value (<literal>false</literal>).
</para>
</listitem>
2018-11-21 22:08:12 +00:00
<listitem>
<para>
Network interface indiscriminate NixOS firewall options
(<literal>networking.firewall.allow*</literal>) are now preserved when also
setting interface specific rules such as <literal>networking.firewall.interfaces.en0.allow*</literal>.
These rules continue to use the pseudo device "default"
(<literal>networking.firewall.interfaces.default.*</literal>), and assigning
to this pseudo device will override the (<literal>networking.firewall.allow*</literal>)
options.
</para>
</listitem>
<listitem>
<para>
2018-12-12 13:49:19 +00:00
The <literal>nscd</literal> service now disables all caching of
<literal>passwd</literal> and <literal>group</literal> databases by
default. This was interferring with the correct functioning of the
<literal>libnss_systemd.so</literal> module which is used by
2018-12-12 13:49:19 +00:00
<literal>systemd</literal> to manage uids and usernames in the presence of
<literal>DynamicUser=</literal> in systemd services. This was already the
default behaviour in presence of <literal>services.sssd.enable =
true</literal> because nscd caching would interfere with
<literal>sssd</literal> in unpredictable ways as well. Because we're
using nscd not for caching, but for convincing glibc to find NSS modules
in the nix store instead of an absolute path, we have decided to disable
caching globally now, as it's usually not the behaviour the user wants and
can lead to surprising behaviour. Furthermore, negative caching of host
lookups is also disabled now by default. This should fix the issue of dns
lookups failing in the presence of an unreliable network.
</para>
<para>
If the old behaviour is desired, this can be restored by setting
the <literal>services.nscd.config</literal> option
with the desired caching parameters.
<programlisting>
services.nscd.config =
''
server-user nscd
threads 1
paranoia no
debug-level 0
enable-cache passwd yes
positive-time-to-live passwd 600
negative-time-to-live passwd 20
suggested-size passwd 211
check-files passwd yes
persistent passwd no
shared passwd yes
enable-cache group yes
positive-time-to-live group 3600
negative-time-to-live group 60
suggested-size group 211
check-files group yes
persistent group no
shared group yes
enable-cache hosts yes
positive-time-to-live hosts 600
negative-time-to-live hosts 5
suggested-size hosts 211
check-files hosts yes
persistent hosts no
shared hosts yes
'';
</programlisting>
See <link xlink:href="https://github.com/NixOS/nixpkgs/pull/50316">#50316</link>
for details.
</para>
</listitem>
<listitem>
<para>
GitLab Shell previously used the nix store paths for the
<literal>gitlab-shell</literal> command in its
<literal>authorized_keys</literal> file, which might stop working after
garbage collection. To circumvent that, we regenerated that file on each
startup. As <literal>gitlab-shell</literal> has now been changed to use
<literal>/var/run/current-system/sw/bin/gitlab-shell</literal>, this is
not necessary anymore, but there might be leftover lines with a nix store
path. Regenerate the <literal>authorized_keys</literal> file via
<command>sudo -u git -H gitlab-rake gitlab:shell:setup</command> in that
case.
</para>
security.pam: make pam_unix.so required, not sufficient Having pam_unix set to "sufficient" means early-succeeding account management group, as soon as pam_unix.so is succeeding. This is not sufficient. For example, nixos modules might install nss modules for user lookup, so pam_unix.so succeeds, and we end the stack successfully, even though other pam account modules might want to do more extensive checks. Other distros seem to set pam_unix.so to 'required', so if there are other pam modules in that management group, they get a chance to do some validation too. For SSSD, @PsyanticY already added a workaround knob in https://github.com/NixOS/nixpkgs/pull/31969, while stating this should be the default anyway. I did some thinking in what could break - after this commit, we require pam_unix to succeed, means we require `getent passwd $username` to return something. This is the case for all local users due to the passwd nss module, and also the case for all modules installing their nss module to nsswitch.conf - true for ldap (if not explicitly disabled) and sssd. I'm not so sure about krb5, cc @eqyiel for opinions. Is there some nss module loaded? Should the pam account module be placed before pam_unix? We don't drop the `security.pam.services.<name?>.sssdStrictAccess` option, as it's also used some lines below to tweak error behaviour inside the pam sssd module itself (by changing it's 'control' field). This is also required to get admin login for Google OS Login working (#51566), as their pam_oslogin_admin accounts module takes care of sudo configuration.
2018-12-12 13:03:13 +00:00
</listitem>
<listitem>
<para>
The <literal>pam_unix</literal> account module is now loaded with its
control field set to <literal>required</literal> instead of
<literal>sufficient</literal>, so that later PAM account modules that
security.pam: make pam_unix.so required, not sufficient Having pam_unix set to "sufficient" means early-succeeding account management group, as soon as pam_unix.so is succeeding. This is not sufficient. For example, nixos modules might install nss modules for user lookup, so pam_unix.so succeeds, and we end the stack successfully, even though other pam account modules might want to do more extensive checks. Other distros seem to set pam_unix.so to 'required', so if there are other pam modules in that management group, they get a chance to do some validation too. For SSSD, @PsyanticY already added a workaround knob in https://github.com/NixOS/nixpkgs/pull/31969, while stating this should be the default anyway. I did some thinking in what could break - after this commit, we require pam_unix to succeed, means we require `getent passwd $username` to return something. This is the case for all local users due to the passwd nss module, and also the case for all modules installing their nss module to nsswitch.conf - true for ldap (if not explicitly disabled) and sssd. I'm not so sure about krb5, cc @eqyiel for opinions. Is there some nss module loaded? Should the pam account module be placed before pam_unix? We don't drop the `security.pam.services.<name?>.sssdStrictAccess` option, as it's also used some lines below to tweak error behaviour inside the pam sssd module itself (by changing it's 'control' field). This is also required to get admin login for Google OS Login working (#51566), as their pam_oslogin_admin accounts module takes care of sudo configuration.
2018-12-12 13:03:13 +00:00
might do more extensive checks are being executed.
Previously, the whole account module verification was exited prematurely
in case a nss module provided the account name to
<literal>pam_unix</literal>.
The LDAP and SSSD NixOS modules already add their NSS modules when
enabled. In case your setup breaks due to some later PAM account module
security.pam: make pam_unix.so required, not sufficient Having pam_unix set to "sufficient" means early-succeeding account management group, as soon as pam_unix.so is succeeding. This is not sufficient. For example, nixos modules might install nss modules for user lookup, so pam_unix.so succeeds, and we end the stack successfully, even though other pam account modules might want to do more extensive checks. Other distros seem to set pam_unix.so to 'required', so if there are other pam modules in that management group, they get a chance to do some validation too. For SSSD, @PsyanticY already added a workaround knob in https://github.com/NixOS/nixpkgs/pull/31969, while stating this should be the default anyway. I did some thinking in what could break - after this commit, we require pam_unix to succeed, means we require `getent passwd $username` to return something. This is the case for all local users due to the passwd nss module, and also the case for all modules installing their nss module to nsswitch.conf - true for ldap (if not explicitly disabled) and sssd. I'm not so sure about krb5, cc @eqyiel for opinions. Is there some nss module loaded? Should the pam account module be placed before pam_unix? We don't drop the `security.pam.services.<name?>.sssdStrictAccess` option, as it's also used some lines below to tweak error behaviour inside the pam sssd module itself (by changing it's 'control' field). This is also required to get admin login for Google OS Login working (#51566), as their pam_oslogin_admin accounts module takes care of sudo configuration.
2018-12-12 13:03:13 +00:00
previosuly shadowed, or failing NSS lookups, please file a bug. You can
get back the old behaviour by manually setting
<literal><![CDATA[security.pam.services.<name?>.text]]></literal>.
</para>
</listitem>
<listitem>
<para>
The <literal>pam_unix</literal> password module is now loaded with its
control field set to <literal>sufficient</literal> instead of
<literal>required</literal>, so that password managed only
by later PAM password modules are being executed.
Previously, for example, changing an LDAP account's password through PAM
was not possible: the whole password module verification
was exited prematurely by <literal>pam_unix</literal>,
preventing <literal>pam_ldap</literal> to manage the password as it should.
</para>
</listitem>
2018-12-28 21:14:14 +00:00
<listitem>
<para>
<literal>fish</literal> has been upgraded to 3.0.
It comes with a number of improvements and backwards incompatible changes.
See the <literal>fish</literal> <link xlink:href="https://github.com/fish-shell/fish-shell/releases/tag/3.0.0">release notes</link> for more information.
</para>
</listitem>
<listitem>
<para>
The ibus-table input method has had a change in config format, which
causes all previous settings to be lost. See
<link xlink:href="https://github.com/mike-fabian/ibus-table/commit/f9195f877c5212fef0dfa446acb328c45ba5852b">this commit message</link>
for details.
</para>
</listitem>
<listitem>
<para>
Support for NixOS module system type <literal>types.optionSet</literal> and
<literal>lib.mkOption</literal> argument <literal>options</literal> is removed.
Use <literal>types.submodule</literal> instead.
(<link xlink:href="https://github.com/NixOS/nixpkgs/pull/54637">#54637</link>)
</para>
</listitem>
<listitem>
<para>
<literal>matrix-synapse</literal> has been updated to version 0.99. It will
<link xlink:href="https://github.com/matrix-org/synapse/pull/4509">no longer generate a self-signed certificate on first launch</link>
and will be <link xlink:href="https://matrix.org/blog/2019/02/05/synapse-0-99-0/">the last version to accept self-signed certificates</link>.
As such, it is now recommended to use a proper certificate verified by a
root CA (for example Let's Encrypt).
</para>
</listitem>
<listitem>
<para>
<literal>mailutils</literal> now works by default when
<literal>sendmail</literal> is not in a setuid wrapper. As a consequence,
the <literal>sendmailPath</literal> argument, having lost its main use, has
been removed.
</para>
</listitem>
2019-03-02 16:42:26 +00:00
<listitem>
<para>
<literal>graylog</literal> has been upgraded from version 2.* to 3.*. Some setups making use of extraConfig (especially those exposing Graylog via reverse proxies) need to be updated as upstream removed/replaced some settings. See <link xlink:href="http://docs.graylog.org/en/3.0/pages/upgrade/graylog-3.0.html#simplified-http-interface-configuration">Upgrading Graylog</link> for details.
</para>
</listitem>
</itemizedlist>
</section>
2018-09-02 21:17:59 +00:00
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="sec-release-19.03-notable-changes">
<title>Other Notable Changes</title>
<itemizedlist>
<listitem>
<para>
The <option>services.matomo</option> module gained the option
<option>services.matomo.package</option> which determines the used
Matomo version.
</para>
<para>
The Matomo module now also comes with the systemd service <literal>matomo-archive-processing.service</literal>
and a timer that automatically triggers archive processing every hour.
This means that you can safely
<link xlink:href="https://matomo.org/docs/setup-auto-archiving/#disable-browser-triggers-for-matomo-archiving-and-limit-matomo-reports-to-updating-every-hour">
disable browser triggers for Matomo archiving
</link> at <literal>Administration > System > General Settings</literal>.
</para>
<para>
Additionally, you can enable to
<link xlink:href="https://matomo.org/docs/privacy/#step-2-delete-old-visitors-logs">
delete old visitor logs
</link> at <literal>Administration > System > Privacy</literal>,
but make sure that you run <literal>systemctl start matomo-archive-processing.service</literal>
at least once without errors if you have already collected data before,
so that the reports get archived before the source data gets deleted.
</para>
2018-09-02 21:17:59 +00:00
</listitem>
<listitem>
<para>
<literal>composableDerivation</literal> along with supporting library functions
has been removed.
</para>
</listitem>
<listitem>
<para>
The deprecated <literal>truecrypt</literal> package has been removed
and <literal>truecrypt</literal> attribute is now an alias for
<literal>veracrypt</literal>. VeraCrypt is backward-compatible with
TrueCrypt volumes. Note that <literal>cryptsetup</literal> also
supports loading TrueCrypt volumes.
</para>
</listitem>
<listitem>
<para>
The Kubernetes DNS addons, kube-dns, has been replaced with CoreDNS.
This change is made in accordance with Kubernetes making CoreDNS the official default
starting from
<link xlink:href="https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md#sig-cluster-lifecycle">Kubernetes v1.11</link>.
Please beware that upgrading DNS-addon on existing clusters might induce
minor downtime while the DNS-addon terminates and re-initializes.
Also note that the DNS-service now runs with 2 pod replicas by default.
The desired number of replicas can be configured using:
<option>services.kubernetes.addons.dns.replicas</option>.
</para>
</listitem>
<listitem>
<para>
The quassel-webserver package and module was removed from nixpkgs due to the lack
of maintainers.
</para>
</listitem>
<listitem>
<para>
The astah-community package was removed from nixpkgs due to it being discontinued and the downloads not being available anymore.
</para>
</listitem>
<listitem>
<para>
The httpd service now saves log files with a .log file extension by default for
easier integration with the logrotate service.
</para>
</listitem>
<listitem>
<para>
The owncloud server packages and httpd subservice module were removed
from nixpkgs due to the lack of maintainers.
</para>
</listitem>
<listitem>
<para>
It is possible now to uze ZRAM devices as general purpose ephemeral block devices,
not only as swap. Using more than 1 device as ZRAM swap is no longer recommended,
but is still possible by setting <literal>zramSwap.swapDevices</literal> explicitly.
</para>
<para>
ZRAM algorithm can be changed now.
</para>
<para>
Changes to ZRAM algorithm are applied during <literal>nixos-rebuild switch</literal>,
so make sure you have enough swap space on disk to survive ZRAM device rebuild. Alternatively,
use <literal>nixos-rebuild boot; reboot</literal>.
</para>
</listitem>
<listitem>
<para>
Flat volumes are now disabled by default in <literal>hardware.pulseaudio</literal>.
This has been done to prevent applications, which are unaware of this feature, setting
their volumes to 100% on startup causing harm to your audio hardware and potentially your ears.
</para>
<note>
<para>
With this change application specific volumes are relative to the master volume which can be
adjusted independently, whereas before they were absolute; meaning that in effect, it scaled the
device-volume with the volume of the loudest application.
</para>
</note>
</listitem>
2019-02-04 20:47:13 +00:00
<listitem>
<para>
The <link xlink:href="https://github.com/DanielAdolfsson/ndppd"><literal>ndppd</literal></link> module
now supports <link linkend="opt-services.ndppd.enable">all config options</link> provided by the current
upstream version as service options. Additionally the <literal>ndppd</literal> package doesn't contain
the systemd unit configuration from upstream anymore, the unit is completely configured by the NixOS module now.
</para>
</listitem>
<listitem>
<para>
New installs of NixOS will default to the Redmine 4.x series unless otherwise specified in
<literal>services.redmine.package</literal> while existing installs of NixOS will default to
the Redmine 3.x series.
</para>
</listitem>
<listitem>
<para>
The <link linkend="opt-services.grafana.enable">Grafana module</link> now supports declarative
<link xlink:href="http://docs.grafana.org/administration/provisioning/">datasource and dashboard</link>
provisioning.
</para>
</listitem>
<listitem>
<para>
The use of insecure ports on kubernetes has been deprecated.
Thus options:
<varname>services.kubernetes.apiserver.port</varname> and
<varname>services.kubernetes.controllerManager.port</varname>
has been renamed to <varname>.insecurePort</varname>,
and default of both options has changed to 0 (disabled).
</para>
</listitem>
<listitem>
<para>
Note that the default value of
<varname>services.kubernetes.apiserver.bindAddress</varname>
has changed from 127.0.0.1 to 0.0.0.0, allowing the apiserver to be
accessible from outside the master node itself.
If the apiserver insecurePort is enabled,
it is strongly recommended to only bind on the loopback interface. See:
<varname>services.kubernetes.apiserver.insecurebindAddress</varname>.
</para>
</listitem>
<listitem>
<para>
The option <varname>services.kubernetes.apiserver.allowPrivileged</varname>
and <varname>services.kubernetes.kubelet.allowPrivileged</varname> now
defaults to false. Disallowing privileged containers on the cluster.
</para>
</listitem>
<listitem>
<para>
The kubernetes module does no longer add the kubernetes package to
<varname>environment.systemPackages</varname> implicitly.
</para>
</listitem>
<listitem>
<para>
The <literal>intel</literal> driver has been removed from the default list of
<link linkend="opt-services.xserver.videoDrivers">X.org video drivers</link>.
The <literal>modesetting</literal> driver should take over automatically,
it is better maintained upstream and has less problems with advanced X11 features.
This can lead to a change in the output names used by <literal>xrandr</literal>.
Some performance regressions on some GPU models might happen.
Some OpenCL and VA-API applications might also break
(Beignet seems to provide OpenCL support with
<literal>modesetting</literal> driver, too).
Users who need this functionality more than multi-output XRandR are advised
to add `intel` to `videoDrivers` and report an issue (or provide additional
details in an existing one)
</para>
</listitem>
<listitem>
<para>
Openmpi has been updated to version 4.0.0, which removes some deprecated MPI-1 symbols.
This may break some older applications that still rely on those symbols.
An upgrade guide can be found <link xlink:href="https://www.open-mpi.org/faq/?category=mpi-removed">here</link>.
</para>
2019-02-23 08:43:36 +00:00
<para>
The nginx package now relies on OpenSSL 1.1 and supports TLS 1.3 by default. You can set the protocols used by the nginx service using <xref linkend="opt-services.nginx.sslProtocols"/>.
</para>
</listitem>
<listitem>
<para>
A new subcommand <command>nixos-rebuild edit</command> was added.
</para>
</listitem>
2018-09-02 21:17:59 +00:00
</itemizedlist>
</section>
</section>