The radicale version is no longer chosen automatically based on
system.stateVersion because that gave the impression that old versions
are still supported.
Follow RFC 42 by having a settings option that is
then converted into an unbound configuration file
instead of having an extraConfig option.
Existing options have been renamed or kept if
possible.
An enableRemoteAccess has been added. It sets remote-control setting to
true in unbound.conf which in turn enables the new wrapping of
unbound-control to access the server locally. Also includes options
'remoteAccessInterfaces' and 'remoteAccessPort' for remote access.
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
The last bits to prevent babeld from running unprivileged was its
kernel_setup_interface routine, that wants to set per interface
rp_filter. This behaviour has been disabled in a patch that has been
submitted upstream at https://github.com/jech/babeld/pull/68 and reuses
the skip-kernel-setup config option.
→ Overall exposure level for babeld.service: 1.7 OK 🙂
Remove old CUDA toolkits (and corresponding CuDNN versions).
- Not supported by upstream anymore.
- We do not use them in nixpkgs.
- We do not test or actively maintain them.
- Anything but ancient GPUs is supported by newer toolkits.
Fixes#107131.
As the only consequence of isSystemUser is that if the uid is null then
it's allocated below 500, if a user has uid = something below 500 then
we don't require isSystemUser to be set.
Motivation: https://github.com/NixOS/nixpkgs/issues/112647
The 5.10 series is the next longterm version of the linux kernel and
I've been using it on multiple x86_64 machines ever since it came out.
I think it is time to switch over the default now, so we get some
additional testing in time for NixOS 21.05.
- Write a `mkDerivation` and `mkDerivationWith` function for gnuradio,
like qt5.
- qradiolink, gqrx: Use gnuradio's callPackage and mkDerivation.
- Use gnuradio.callPackage to define all gnuradio.pkgs.
- Move all gnuradio packages expressions to pkgs/development/gnuradio-modules/ -
modeled after Python's.
- Add more paths to gnuradio's wrapper - add the extra packages as
python modules, and add their executables with proper env vars
wrapping.
Co-authored-by: Frederik Rietdijk <fridh@fridh.nl>
Change the default SMTP port to `25`, to better match the default
address `localhost`. This gets rid of some error outputs in the test,
where it fails to connect to localhost:465.
Also, don't enable postfix by default unless it's actually useful to
us.
ChangeLog: https://nextcloud.com/changelog/#latest21
* Packaged 21.0.0, test-deployed it to my personal instance and tested
the most basic functionality (`davfs2`-mount, {card,cal}dav sync, file
management).
* Bumped the default version for unstable/21.05 to `nextcloud21`. Since
`nextcloud20` was added after the release of 20.09 (and thus the
default on 20.09 is still `nextcloud19`), it's now needed to upgrade
across two majors.
This is not a problem though since it's possible to upgrade to v20 on
20.09 already and if not, the module will guard the administrator
through the upgrade with eval warnings as it's the case since 20.03.
* Dropped `nextcloud17` attribute and marked `nextcloud18` as EOL.
The NixOS 21.03 release has been delayed to 21.05. See NixOS/rfcs#80.
There are two instances of 21.03 which have been left as is, since they
are in stateVersion comparisons. This will ensure that existing user
configurations which refer to 21.03 will continue to work.
Important changes:
- The 'isync' compatibility wrapper was removed.
- The Master/Slave configuration keywords where deprecated and should be
replaced with Far/Near. All users should update their configuration
file accordingly. It's a trivial change and the old Master/Slave
keywords will still work for now but result in the following message:
Notice: Master/Slave are deprecated; use Far/Near instead.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
By default, restic determines the location of the cache based on the XDG
base dir specification, which is `~/.cache/restic` when the environment
variable `$XDG_CACHE_HOME` isn't set.
As restic is executed as root by default, this resulted in the cache being
written to `/root/.cache/restic`, which is not quite right for a system
service and also meant, multiple backup services would use the same cache
directory - potentially causing issues with locking, data corruption,
etc.
The goal was to ensure, restic uses the correct cache location for a
system service - one cache per backup specification, using `/var/cache`
as the base directory for it.
systemd sets the environment variable `$CACHE_DIRECTORY` once
`CacheDirectory=` is defined, but restic doesn't change its behavior
based on the presence of this environment variable.
Instead, the specifier [1] `%C` can be used to point restic explicitly
towards the correct cache location using the `--cache-dir` argument.
Furthermore, the `CacheDirectoryMode=` was set to `0700`, as the default
of `0755` is far too open in this case, as the cache might contain
sensitive data.
[1] https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Specifiers
OSS Emulation is considered incomplete so disabling it by default.
Using user level alsa-oss library (nix-env -iA nixos.alsaOss) over
this kernel module is recommended.
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
androidenv did not previously write license files, which caused certain
gradle-based Android tools to fail. Restructure androidenv's list of
Android packages into a single repo.json file to prevent duplication
and enable us to extract the EULA texts, which we then hash with
builtins.hashString to produce the license files that Android gradle
tools look for.
Remove includeDocs and lldbVersions, as these have been removed
from the Android package repositories.
Improve documentation and examples.
* Content of `programlisting` shouldn't be indented, otherwise it's
weirdly indented in the output.
* Use `<xref linkend=.../>` in the release notes: then users can
directly go to the option documentation when reading release notes.
* Don't use docbook tags in `mkRemovedOptionModule`: it's only used
during evaluation where docbook isn't rendered.
Since slurm-20.11.0.1 the dbd server requires slurmdbd.conf to be
in mode 600 to protect the database password. This change creates
slurmdbd.conf on-the-fly at service startup and thus avoids that
the database password ends up in the nix store.
It's very surprising that services.tor.client.enable would set
services.privoxy.enable. This violates the principle of least
astonishment, because it's Privoxy that can integrate with Tor, rather
than the other way around.
So this patch moves the Privoxy Tor integration to the Privoxy module,
and it also disables it by default. This change is documented in the
release notes.
Reported-by: V <v@anomalous.eu>
configuration.nix(1) states
users.extraUsers.<name>.createHome
[...] If [...] the home directory already exists but is not
owned by the user, directory owner and group will be changed to
match the user.
i.e. ownership would change only if the user mismatched; the code
however ignores the owner, it is sufficient to enable `createHome`:
if ($u->{createHome}) {
make_path($u->{home}, { mode => 0700 }) if ! -e $u->{home};
chown $u->{uid}, $u->{gid}, $u->{home};
}
Furthermore, permissions are ignored on already existing directories and
therefore may allow others to read private data eventually.
Given that createHome already acts as switch to not only create but
effectively own the home directory, manage permissions in the same
manner to ensure the intended default and cover all primary attributes.
Avoid yet another configuration option to have administrators make a
clear and simple choice between securely managing home directories
and optionally defering management to own code (taking care of custom
location, ownership, mode, extended attributes, etc.).
While here, simplify and thereby fix misleading documentation.
Mailman can now work with MTAs other than Postfix. You'll have to configure
it yourself using the options in `services.mailman.settings.mta`.
This addition is reflected in the release notes for 21.03.
A big jump, but the structure hasn't changed much.
This recipe is still based on a binary release provided by upstream.
(It might be interesting to start doing our own builds at some point,
to split client from server, and/or to create packages for removed
"contribs" such as 'zooInspector'. Upstream intends to further slim
down its release tarballs as most deployments only need specific assets.)
See https://www.redhat.com/sysadmin/fedora-31-control-group-v2 for
details on why this is desirable, and how it impacts containers.
Users that need to keep using the old cgroup hierarchy can re-enable it
by setting `systemd.unifiedCgroupHierarchy` to `false`.
Well-known candidates not supporting that hierarchy, like docker and
hidepid=… will disable it automatically.
Fixes#73800
Note that it made into 2 entries, one about new options in the first section.
Another in the breaking compatibility section due to the openFirewall option
which changes the behavior.
This reverts commit fb6d63f3fd.
I really hope this finally fixes#99236: evaluation on Hydra.
This time I really did check basically the same commit on Hydra:
https://hydra.nixos.org/eval/1618011
Right now I don't have energy to find what exactly is wrong in the
commit, and it doesn't seem important in comparison to nixos-unstable
channel being stuck on a commit over one week old.
Please note that this is only for 21.03 since `nextcloud19` is intended
to be the default for the already feature-frozen 20.09 (the bump itself
is supposed to get backported however).
Conform to RFC 1123 [0], specifically to "2.1 Host Names and Numbers",
which allow starting host name with alphanumerical instead of alphabetical characters.
RFC 1123 updates RFC 952 [1], which is referenced in "man 5 hosts".
[0]: https://tools.ietf.org/html/rfc1123
[1]: https://tools.ietf.org/html/rfc952
Both packages will get EOLed within the lifetime of 20.09. `nextcloud17`
can be removed entirely (the attribute-path is kept however to provide
meaningful errors), however `nextcloud18` must be kept as `insecure` to
make sure that users from `nextcloud17` can properly upgrade to
`nextcloud19` on NixOS 20.09.
This removes the `services.dbus.socketActivated` and
`services.xserver.startDbusSession` options. Instead the user D-Bus
session is always socket activated.
Now allows applying external overlays either in form of
.dts file, literal dts context added to store or precompiled .dtbo.
If overlays are defined, kernel device-trees are compiled with '-@'
so the .dtb files contain symbols which we can reference in our
overlays.
Since `fdtoverlay` doesn't respect `/ compatible` by itself
we query compatible strings of both `dtb` and `dtbo(verlay)`
and apply only if latter is substring of the former.
Also adds support for filtering .dtb files (as there are now nearly 1k
dtbs).
Co-authored-by: georgewhewell <georgerw@gmail.com>
Co-authored-by: Kai Wohlfahrt <kai.wohlfahrt@gmail.com>
Right now the UX for installing NixOS on a headless system is very bad.
To enable sshd without physical steps users have to have either physical
access or need to be very knowledge-able to figure out how to modify the
installation image by hand to put an `sshd.service` symlink in the
right directory in /nix/store. This is in particular a problem on ARM
SBCs (single board computer) but also other hardware where network is
the only meaningful way to access the hardware.
This commit enables sshd by default. This does not give anyone access to
the NixOS installer since by default. There is no user with a non-empty
password or key. It makes it easy however to add ssh keys to the
installation image (usb stick, sd-card on arm boards) by simply mounting
it and adding a keys to `/root/.ssh/authorized_keys`.
Importantly this should not require nix/nixos on the machine that
prepare the installation device and even feasiable on non-linux systems
by using ext4 third party drivers.
Potential new threats: Since this enables sshd by default a
potential bug in openssh could lead to remote code execution. Openssh
has a very good track-record over the last 20 years, which makes it
far more likely that Linux itself would have a remote code execution
vulnerability. It is trusted by millions of servers on many operating
systems to be exposed to the internet by default.
Co-authored-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
readd perl (used in shell scripts), rsync (needed for NixOps) and strace (common debugging tool)
they where previously removed in https://github.com/NixOS/nixpkgs/pull/91213
Co-authored-by: Timo Kaufmann <timokau@zoho.com>
Co-authored-by: 8573 <8573@users.noreply.github.com>
Use StateDirectory to create necessary directories and hardcode some
paths. Also drop file based audit logs, they can be found in the
journal. And add module option deprecation messages.
`sslCACert` was used for trust store of client and server certificates. Since `smtpd_tls_ask_ccert` defaults to no the setup of `smtpd_tls_CApath` was removed.
>By default (see smtpd_tls_ask_ccert), client certificates are not requested, and smtpd_tls_CApath should remain empty.
see http://www.postfix.org/postconf.5.html#smtpd_tls_CAfile
Keeping the VM state test across several run sometimes lead to subtle
and hard to spot errors in practice. We delete the VM state which
contains (among other things) the qcow volume.
We also introduce a -K (--keep-vm-state) flag making VM state to
persist after the test run. This flag makes test-driver.py to match
its previous behaviour.
Enhance the heuristics to make sure that a user doesn't accidentally
upgrade across two major versions of Nextcloud (e.g. from v17 to v19).
The original idea/discussion has been documented in the nixpkgs manual[1].
This includes the following changes:
* `nextcloud19` will be selected automatically when having a stateVersion
greater or equal than 20.09. For existing setups, the package has to
be selected manually to avoid accidental upgrades.
* When using `nextcloud18` or older, a warning will be thrown which recommends
upgrading to `nextcloud19`.
* Added a brief paragraph about `nextcloud19` in the NixOS 19.09 release
notes.
* Restart `phpfpm` if the Nextcloud-package (`cfg.package`) changes[2].
[1] https://nixos.org/nixos/manual/index.html#module-services-nextcloud-maintainer-info
[2] https://github.com/NixOS/nixpkgs/pull/89427#issuecomment-638885727
Specifying mailboxes as a list isn't a good approach since this makes it
impossible to override values. For backwards-compatibility, it's still
possible to declare a list of mailboxes, but a deprecation warning will
be shown.
Since cd1dedac67 systemd-networkd has it's
netlink socket created via a systemd.socket unit. One might think that
this doesn't make much sense since networkd is just going to create it's
own socket on startup anyway. The difference here is that we have
configuration-time control over things like socket buffer sizes vs
compile-time constants.
For larger setups where networkd has to create a lot of (virtual)
devices the default buffer size of currently 128MB is not enough.
A good example is a machine with >100 virtual interfaces (e.g.,
wireguard tunnels, VLANs, …) that all have to be brought up during
startup. The receive buffer size will spike due to all the generated
message from the new interfaces. Eventually some of the message will be
dropped since there is not enough (permitted) buffer space available.
By having networkd start through / with a netlink socket created by
systemd we can configure the `ReceiveBufferSize` parameter in the socket
options without recompiling networkd.
Since the actual memory requirements depend on hardware, timing, exact
configurations etc. it isn't currently possible to infer a good default
from within the NixOS module system. Administrators are advised to
monitor the logs of systemd-networkd for `rtnl: kernel receive buffer
overrun` spam and increase the memory as required.
Note: Increasing the ReceiveBufferSize doesn't allocate any memory. It
just increases the upper bound on the kernel side. The memory allocation
depends on the amount of messages that are queued on the kernel side of
the netlink socket.
udev gained native support to handle FIDO security tokens, so we don't
need a module which only added the now obsolete udev rules.
Fixes: https://github.com/NixOS/nixpkgs/issues/76482
This fixes the output of "hostname --fqdn" (previously the domain name
was not appended). Additionally it's now possible to use the FQDN.
This works by unconditionally adding two entries to /etc/hosts:
127.0.0.1 localhost
::1 localhost
These are the first two entries and therefore gethostbyaddr() will
always resolve "127.0.0.1" and "::1" back to "localhost" [0].
This works because nscd (or rather the nss-files module) returns the
first matching row from /etc/hosts (and ignores the rest).
The FQDN and hostname entries are appended later to /etc/hosts, e.g.:
127.0.0.2 nixos-unstable.test.tld nixos-unstable
::1 nixos-unstable.test.tld nixos-unstable
Note: We use 127.0.0.2 here to follow nss-myhostname (systemd) as close
as possible. This has the advantage that 127.0.0.2 can be resolved back
to the FQDN but also the drawback that applications that only listen to
127.0.0.1 (and not additionally ::1) cannot be reached via the FQDN.
If you would like this to work you can use the following configuration:
```nix
networking.hosts."127.0.0.1" = [
"${config.networking.hostName}.${config.networking.domain}"
config.networking.hostName
];
```
Therefore gethostbyname() resolves "nixos-unstable" to the FQDN
(canonical name): "nixos-unstable.test.tld".
Advantages over the previous behaviour:
- The FQDN will now also be resolved correctly (the entry was missing).
- E.g. the command "hostname --fqdn" will now work as expected.
Drawbacks:
- Overrides entries form the DNS (an issue if e.g. $FQDN should resolve
to the public IP address instead of 127.0.0.1)
- Note: This was already partly an issue as there's an entry for
$HOSTNAME (without the domain part) that resolves to
127.0.1.1 (!= 127.0.0.1).
- Unknown (could potentially cause other unexpected issues, but special
care was taken).
[0]: Some applications do apparently depend on this behaviour (see
c578924) and this is typically the expected behaviour.
Co-authored-by: Florian Klink <flokli@flokli.de>
The `network-link-${i.name}` units raced with other things trying to
configure the interface, or ran before the interface was available.
Instead of running our own set of shell scripts on boot, and hoping
they're executed at the right time, we can make use of udev to configure
the interface *while they appear*, by providing `.link` files in
/etc/systemd/network/*.link to set MACAddress and MTUBytes.
This doesn't require networkd to be enabled, and is populated properly
on non-networkd systems since
https://github.com/NixOS/nixpkgs/pull/82941.
This continues clean-up work done in
https://github.com/NixOS/nixpkgs/pull/85170 for the scripted networking
stack.
The only leftover part of the `network-link-${i.name}` unit (bringing
the interface up) is moved to the beginning of the
`network-addresses-${i.name}` unit.
Fixes: https://github.com/NixOS/nixpkgs/issues/74471
Closes: https://github.com/NixOS/nixpkgs/pull/87116
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
This follows upstreams change in documentation. While the `[DHCP]`
section might still work it is undocumented and we should probably not
be using it anymore. Users can just upgrade to the new option without
much hassle.
I had to create a bit of custom module deprecation code since the usual
approach doesn't support wildcards in the path.
Systemd upstream has deprecated CriticalConnection with v244 in favor of
KeepConnection as that seems to be more flexible:
The CriticalConnection= setting in .network files is now deprecated,
and replaced by a new KeepConfiguration= setting which allows more
detailed configuration of the IP configuration to keep in place.
Rework withExtensions / buildEnv to handle currently enabled
extensions better and make them compatible with override. They now
accept a function with the named arguments enabled and all, where
enabled is a list of currently enabled extensions and all is the set
of all extensions. This gives us several nice properties:
- You always get the right version of the list of currently enabled
extensions
- Invocations chain
- It works well with overridden PHP packages - you always get the
correct versions of extensions
As a contrived example of what's possible, you can add ImageMagick,
then override the version and disable fpm, then disable cgi, and
lastly remove the zip extension like this:
{ pkgs ? (import <nixpkgs>) {} }:
with pkgs;
let
phpWithImagick = php74.withExtensions ({ all, enabled }: enabled ++ [ all.imagick ]);
phpWithImagickWithoutFpm743 = phpWithImagick.override {
version = "7.4.3";
sha256 = "wVF7pJV4+y3MZMc6Ptx21PxQfEp6xjmYFYTMfTtMbRQ=";
fpmSupport = false;
};
phpWithImagickWithoutFpmZip743 = phpWithImagickWithoutFpm743.withExtensions (
{ enabled, all }:
lib.filter (e: e != all.zip) enabled);
phpWithImagickWithoutFpmZipCgi743 = phpWithImagickWithoutFpmZip743.override {
cgiSupport = false;
};
in
phpWithImagickWithoutFpmZipCgi743
It currently says that everything will be backward compatible between lego and simp-le certificates, but it’s not.
(cherry picked from commit 21c4a33cee)
According to my analysis the last critical fix went into v5.4.23, I have
confirmed this by running WebGL over night and haven't seen a single
i915 GPU hang. Lets remove the notes from the release notes.
(cherry picked from commit da764d22ce)
This is an backward incompatible change from upstream dhcpcd [0], as
this could have easily locked me out of my box.
As dhcpcd doesn't allow to use only a blacklist (denyinterfaces in
dhcpcd.conf) of devices and use all remaining devices, while explicitly
allowing some interfaces like bridges, I think the best option would be
to not change anything about it and just educate the users here about
that edge case and how to solve it.
[0] https://roy.marples.name/archives/dhcpcd-discuss/0002621.html
(cherry picked from commit eeeb2bf803)
Also removed `pkgs.hydra-flakes` since flake-support has been merged
into master[1]. Because of that, `pkgs.hydra-unstable` is now compiled
against `pkgs.nixFlakes` and currently requires a patch since Hydra's
master doesn't compile[2] atm.
[1] https://github.com/NixOS/hydra/pull/730
[2] https://github.com/NixOS/hydra/pull/732
Some changes might require manual migration steps:
"Due to changes to the way in which Gollum handles filenames, you may
have to change some links in your wiki when migrating from gollum 4.x.
See the release notes [0] for more details. You may find the
bin/gollum-migrate-tags script helpful to accomplish this. Also see the
--lenient-tag-lookup option for making tag lookup backwards compatible
with 4.x, though note that this will decrease performance on large wikis
with many tags." (source: [1])
[0]: https://github.com/gollum/gollum/wiki/5.0-release-notes
[1]: https://github.com/gollum/gollum/blob/v5.0.0/HISTORY.md
So now we have only packages for human interaction in php.packages and
only extensions in php.extensions. With this php.packages.exts have
been merged into the same attribute set as all the other extensions to
make it flat and nice.
The nextcloud module have been updated to reflect this change as well
as the documentation.
Upgrades Hydra to the latest master/flake branch. To perform this
upgrade, it's needed to do a non-trivial db-migration which provides a
massive performance-improvement[1].
The basic ideas behind multi-step upgrades of services between NixOS versions
have been gathered already[2]. For further context it's recommended to
read this first.
Basically, the following steps are needed:
* Upgrade to a non-breaking version of Hydra with the db-changes
(columns are still nullable here). If `system.stateVersion` is set to
something older than 20.03, the package will be selected
automatically, otherwise `pkgs.hydra-migration` needs to be used.
* Run `hydra-backfill-ids` on the server.
* Deploy either `pkgs.hydra-unstable` (for Hydra master) or
`pkgs.hydra-flakes` (for flakes-support) to activate the optimization.
The steps are also documented in the release-notes and in the module
using `warnings`.
`pkgs.hydra` has been removed as latest Hydra doesn't compile with
`pkgs.nixStable` and to ensure a graceful migration using the newly
introduced packages.
To verify the approach, a simple vm-test has been added which verifies
the migration steps.
[1] https://github.com/NixOS/hydra/pull/711
[2] https://github.com/NixOS/nixpkgs/pull/82353#issuecomment-598269471
It's impossible to move two major-versions forward when upgrading
Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16)
and trying to upgrade to 20.03 (using Nextcloud 18 by default).
This patch implements the measurements discussed in #82056 and #82353 to
improve the update process and to circumvent similar issues in the
future:
* `pkgs.nextcloud` has been removed in favor of versioned attributes
(currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that
approach we can safely backport major-releases in the future to
simplify those upgrade-paths and we can select one of the
major-releases as default depending on the configuration (helpful to
decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be
used on 20.03 and `master` atm).
* If `system.stateVersion` is older than `20.03`, `nextcloud17` will be
used (which is one major-release behind v16 from 19.09). When using a
package older than the latest major-release available (currently v18),
the evaluation will cause a warning which describes the issue and
suggests next steps.
To make those package-selections easier, a new option to define the
package to be used for the service (namely
`services.nextcloud.package`) was introduced.
* If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to
provide more recent Nextcloud versions on older NixOS-releases), an
evaluation error will be thrown by default: this is to make sure that
`services.nextcloud.package` doesn't use an older version by accident
after checking the state-version. If `pkgs.nextcloud` is added
manually, it needs to be declared explicitly in
`services.nextcloud.package`.
* The `nixos/nextcloud`-documentation contains a
"Maintainer information"-chapter which describes how to roll out new
Nextcloud releases and how to deal with old (and probably unsafe)
versions.
Closes#82056
Dropbear lags behind OpenSSH significantly in both support for modern
key formats like `ssh-ed25519`, let alone the recently-introduced
U2F/FIDO2-based `sk-ssh-ed25519@openssh.com` (as I found when I switched
my `authorizedKeys` over to it and promptly locked myself out of my
server's initrd SSH, breaking reboots), as well as security features
like multiprocess isolation. Using the same SSH daemon for stage-1 and
the main system ensures key formats will always remain compatible, as
well as more conveniently allowing the sharing of configuration and
host keys.
The main reason to use Dropbear over OpenSSH would be initrd space
concerns, but NixOS initrds are already large (17 MiB currently on my
server), and the size difference between the two isn't huge (the test's
initrd goes from 9.7 MiB to 12 MiB with this change). If the size is
still a problem, then it would be easy to shrink sshd down to a few
hundred kilobytes by using an initrd-specific build that uses musl and
disables things like Kerberos support.
This passes the test and works on my server, but more rigorous testing
and review from people who use initrd SSH would be appreciated!
This mirrors the behaviour of systemd - It's udev that parses `.link`
files, not `systemd-networkd`.
This was originally applied in 36ef112a47,
but was reverted due to 1115959a8d causing
evaluation errors on hydra.
* Linkify all service options used in the code-examples.
* Demonstrated the use of `riot-web.override {}`.
* Moved the example how to configure a postgresql-database for
`matrix-synapse` to this document from the 20.03 release-notes.
...even when networkd is disabled
This reverts commit ce78f3ac70, reversing
changes made to dc34da0755.
I'm sorry; Hydra has been unable to evaluate, always returning
> error: unexpected EOF reading a line
and I've been unable to reproduce the problem locally. Bisecting
pointed to this merge, but I still can't see what exactly was wrong.
On servers especially, phantomjs2 pulls graphical dependencies which is unecessary.
This pathes enable the package to be linked/installed without
phantomjs2. Phantomjs2 is disabled by default since it has been deprecated in grafana https://grafana.com/docs/grafana/latest/guides/whats-new-in-v6-4/
In 0945178b3c we decided that Perl-based
VM tests should be deprecated and will be removed between 20.03 and
20.09. So let's switch `nixos-build-vms(8)` to python as well (which is
entirely interactive, so other scripts won't break).
In my experience, the test-driver isn't used most of the time, so this
patch is mainly supposed to get rid of the (probably misleading)
deprecation warning when running `nixos-build-vms`. Apart from that, the
interface for python's test-driver is way nicer.
XML error introduced with merge commit 4e0fea3fe2.
This was probably because of wrong conflict resolution, because the
actual change (d8e697b4fc) had the close
tag of the <para/> element, but the merge commit didn't.
Signed-off-by: aszlig <aszlig@nix.build>
Package is marked as broken for >2 years and used a fairly old
snapshot from the gcc7-branch, so I fairly doubt that this is
somewhere used (and is also pretty misleading as you don't expect a
random snapshot from gcc7 at `pkgs.gcc-snapshot`).
