`doas` is a lighter alternative to `sudo` that "provide[s] 95% of the
features of `sudo` with a fraction of the codebase" [1]. I prefer it to
`sudo`, so I figured I would add a NixOS module in order for it to be
easier to use. The module is based off of the existing `sudo` module.
[1] https://github.com/Duncaen/OpenDoas
- Use floating points instead of strings, which Nix now supports
- Make the type of picom.settings option recursive
- Add a meaningful description of both the option and its type
Add extraConfig option for the muc submodule.
Also move the global extraConfig before all components and
virtualhosts, because the manual states:
The configuration is divided into two parts. The first part is known as
the "global" section. All settings here apply to the whole server, and
are the default for all virtual hosts.
The second half of the file is a series of VirtualHost and Component
definitions. Settings under each VirtualHost or Component line apply
only to that host.
Before, if at least one muc was defined, or uploadHttp enabled, the
global extraConfig would end up after "muc" or "http_upload" component
making it apply to that component only and not globally.
We add a Prosody entry to the NixOS manual showing how to setup a
basic XEP-0423 compliant Prosody service. This example also showcase
how to generate the associated ACME certificates.
Note: The <programlisting> body might look poorly indented, but trust
me, it's necessary. If we try to increase their indentation level, the
HTML output will end up containing a lot of unecesseray heading spaces
breaking the formatting...
This reverts commit 764c8203b8.
While this is desireable in principle, some of our modules and services
fail during service startup if no network is available don't currently
properly set Wants=network-online.target.
If nothing pulls in this target anymore, systemd won't try to reach it.
We have many VM tests waiting for `network-online.target`, and after
764c8203b8 fail with the following error
message:
```
error: unit "network-online.target" is inactive and there are no pending jobs
```
Most likely, test scripts shouldn't wait for `network-online.target` in
first place (as `network-online.target` says nothing about whether a
service has been started), but instead, the script should wait for the
network ports of the corresponding service to be open.
Let's revert this for now, and re-apply in a draft PR, fixing the tests
before merging it back in.
The output file is found and handled by thelounge itself [1], leaving
the user free to override THELOUNGE_HOME in the environment if they
choose, but having a sensible default to make `thelounge` generally
usable in most cases.
This solution follows discussion on #70318.
[1] 9ef5c6c67e/src/command-line/utils.js (L56)
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.
You can now specify option for the `[DHCPv6]` section with
`systemd.network.<name>.dhcpV6Config.…`. Previously you could only use
the combined legacy DHCP configuration.
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.
We are leveraging the systemd sandboxing features to prevent the
service accessing locations it shouldn't do. Most notably, we are here
preventing the prosody service from accessing /home and providing it
with a private /dev and /tmp.
Please consult man systemd.exec for further informations.
Setting up a XMPP chat server is a pretty deep rabbit whole to jump in
when you're not familiar with this whole universe. Your experience
with this environment will greatly depends on whether or not your
server implements the right set of XEPs.
To tackle this problem, the XMPP community came with the idea of
creating a meta-XEP in charge of listing the desirable XEPs to comply
with. This meta-XMP is issued every year under an new XEP number. The
2020 one being XEP-0423[1].
This prosody nixos module refactoring makes complying with XEP-0423
easier. All the necessary extensions are enabled by default. For some
extensions (MUC and HTTP_UPLOAD), we need some input from the user and
cannot provide a sensible default nixpkgs-wide. For those, we guide
the user using a couple of assertions explaining the remaining manual
steps to perform.
We took advantage of this substential refactoring to refresh the
associated nixos test.
Changelog:
- Update the prosody package to provide the necessary community
modules in order to comply with XEP-0423. This is a tradeoff, as
depending on their configuration, the user might end up not using them
and wasting some disk space. That being said, adding those will
allow the XEP-0423 users, which I expect to be the majority of
users, to leverage a bit more the binary cache.
- Add a muc submodule populated with the prosody muc defaults.
- Add a http_upload submodule in charge of setting up a basic http
server handling the user uploads. This submodule is in is
spinning up an HTTP(s) server in charge of receiving and serving the
user's attachments.
- Advertise both the MUCs and the http_upload endpoints using mod disco.
- Use the slixmpp library in place of the now defunct sleekxmpp for
the prosody NixOS test.
- Update the nixos test to setup and test the MUC and http upload
features.
- Add a couple of assertions triggered if the setup is not xep-0423
compliant.
[1] https://xmpp.org/extensions/xep-0423.html
Not all systems need to be online to boot up. So, don’t pull
network-online.target into multi-user.target. Services that need
online network can still require it.
This increases my boot time from ~9s to ~5s.
It's `lib.versions`, not `lib.version`. Also I'm really sure that it's
supposed to be the current version of Gutenprint, not Cups, as thats
what `lpinfo -m` says on my system.
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
Instead of hardcoding all nss modules that are added into nsswitch,
there are now options exposed.
This allows users to add own nss modules (I had this issue with
winbindd, for example).
Also, nss modules could be moved to their NixOS modules which would
make the nsswitch module slimmer.
As the lists are now handled by the modules system, we can use mkOrder
to ensure a proper order as well as mkForce to override one specific
database type instead of the entire file.
nix build should store it's temporary files on target filesystem.
This should fix 'No space left on device' on systems
with low amount of RAM when there is a need to build something
like Linux kernel
Fixes this warning at ibus-daemon startup:
(ibus-dconf:15691): dconf-WARNING **: 21:49:24.018: unable to open file '/etc/dconf/db/ibus': Failed to open file ?/etc/dconf/db/ibus?: open() failed: No such file or directory; expect degraded performance
Fixes#858001d61efb7f1 accidentially changed the
restartTriggers of `datadog-agent.service` to point to the attribute
name (in this case, a location relative to `/etc`), instead of the
location of the config files in the nix store.
This caused datadog to not get restarted on activation of new
config, if the file name hasn't changed.
Fix this, by pointing this back to the location in the nix store.
1d61efb7f1 accidentially changed the
restartTriggers of systemd-networkd.service` to point to the attribute
name (in this case, a location relative to `/etc`), instead of the
location of the network-related unit files in the nix store.
This caused systemd-networkd to not get restarted on activation of new
networking config, if the file name hasn't changed.
Fix this, by pointing this back to the location in the nix store.
What's happening now is that both cri-o and podman are creating
/etc/containers/policy.json.
By splitting out the creation of configuration files we can make the
podman module leaner & compose better with other container software.
For imports, it is better to use ‘modulesPath’ than rely on <nixpkgs>
being correctly set. Some users may not have <nixpkgs> set correctly.
In addition, when ‘pure-eval=true’, <nixpkgs> is unset.
Context: discussion in https://github.com/NixOS/nixpkgs/pull/82630
Mesa has been supporting S3TC natively without requiring these libraries
since the S3TC patent expired in December 2017.
Use types.str instead of types.path to exclude private information from
the derivation.
Add a warinig about the contents of acl beeing included in the nix
store.
Enables multi-site configurations.
This break compatibility with prior configurations that expect options
for a single dokuwiki instance in `services.dokuwiki`.
linux-hardened sets kernel.unprivileged_userns_clone=0 by default; see
anthraxx/linux-hardened@104f44058f.
This allows the Nix sandbox to function while reducing the attack
surface posed by user namespaces, which allow unprivileged code to
exercise lots of root-only code paths and have lead to privilege
escalation vulnerabilities in the past.
We can safely leave user namespaces on for privileged users, as root
already has root privileges, but if you're not running builds on your
machine and really want to minimize the kernel attack surface then you
can set security.allowUserNamespaces to false.
Note that Chrome's sandbox requires either unprivileged CLONE_NEWUSER or
setuid, and Firefox's silently reduces the security level if it isn't
allowed (see about:support), so desktop users may want to set:
boot.kernel.sysctl."kernel.unprivileged_userns_clone" = true;
* nixos/k3s: simplify config expression
* nixos/k3s: add config assertions and trim unneeded bits
* nixos/k3s: add a test that k3s works; minor module improvements
This is a single-node test. Eventually we should also have a multi-node
test to verify the agent bit works, but that one's more involved.
* nixos/k3s: add option description
* nixos/k3s: add defaults for token/serveraddr
Now that the assertion enforces their presence, we dont' need to use the typesystem for it.
* nixos/k3s: remove unneeded sudo in test
* nixos/k3s: add to test list
After the recent rewrite, enabled extensions are passed to php programs
through an extra ini file by a wrapper. Since httpd uses shared module
instead of program, the wrapper did not affect it and no extensions
other than built-ins were loaded.
To fix this, we are passing the extension config another way – by adding it
to the service's generated config.
For now we are hardcoding the path to the ini file. It would be nice to add
the path to the passthru and use that once the PHP expression settles down.
Add a distinctive `unit-script` prefix to systemd unit scripts to make
them easier to find in the store directory. Do not add this prefix to
actual script file name as it clutters logs.
Current journal output from services started by `script` rather than
`ExexStart` is unreadable because the name of the file (which journalctl
records and outputs) quite literally takes 1/3 of the screen (on smaller
screens).
Make it shorter. In particular:
* Drop the `unit-script` prefix as it is not very useful.
* Use `writeShellScriptBin` to write them because:
* It has a `checkPhase` which is better than no checkPhase.
* The script itself ends up having a short name.
systemd-tmpfiles will load all files in lexicographic order and ignores rules
for the same path in later files with a warning Since we apply the default rules
provided by systemd, we should load user-defines rules first so users have a
chance to override defaults.
This reverts commit 5532065d06.
As far as I can tell setting RemainAfterExit=true here completely breaks
certificate renewal, which is really bad!
the sytemd timer will activate the service unit every OnCalendar=,
however with RemainAfterExit=true the service is already active! So the
timer doesn't rerun the service!
The commit also broke the actual tests, (As it broke activation too)
but this was fixed later in https://github.com/NixOS/nixpkgs/pull/76052
I wrongly assumed that PR fixed renewal too, which it didn't!
testing renewals is hard, as we need to sleep in tests.
Without this, you can change the list of appended or prepended nameservers in
your NetworkManager config, and nixos-rebuild doesn't cause those changes to
come into effect.
When trying to build a VM using `nixos-build-vms` with a configuration
that doesn't evaluate, an error "at `<unknown-file>`" is usually shown.
This happens since the `build-vms.nix` creates a VM-network of
NixOS-configurations that are attr-sets or functions and don't contain
any file information. This patch manually adds the `_file`-attribute to
tell the module-system which file contained broken configuration:
```
$ cat vm.nix
{ vm.invalid-option = 1; }
$ nixos-build-vms vm.nix
error: The option `invalid-option' defined in `/home/ma27/Projects/nixpkgs/vm.nix@node-vm' does not exist.
(use '--show-trace' to show detailed location information)
```
This commit:
1. Updates the path of the traefik package, so that the out output is
used.
2. Adapts the configuration settings and options to Traefik v2.
3. Formats the NixOS traefik service using nixfmt.
Commit 1d2c3279311e4f03fcf164e1366f2fda9f4bfccf in the upstream kernel
repository removed support for the scalar x86_64 and i586 AES
assembly implementations, since the generic AES implementation generated
by the compiler is faster for both platforms. Remove the modules from
the cryptoModules list. This causes a regression for kernel versions
>=5.4 which include the removal. This should have no negative impact on
AES performance on older kernels since the generic implementation should
be faster there as well since the implementation was hardly touched from
its initial submission.
Fixes#84842
We already set the relevant env vars in the systemd services. That does
not help one when executing any of the executables outside a service,
e.g. when creating a new user.
we use stdenv.hostPlatform.uname.processor, which I believe is just like
`uname -p`.
Example values:
```
(import <nixpkgs> { system = "x86_64-linux"; }).stdenv.hostPlatform.uname.processor
"x86_64"
(import <nixpkgs> { system = "aarch64-linux"; }).stdenv.hostPlatform.uname.processor
aarch64
(import <nixpkgs> { system = "armv7l-linux"; }).stdenv.hostPlatform.uname.processor
"armv7l"
```
The new wording does not assume the user is upgrading.
This is because a user could be setting up a new installation on 20.03
on a server that has a 19.09 or before stateVersion!!
The new wording ensures that confusion is reduced by stating that they
do not have to care about the assumed 16→17 transition.
Then, the wording explains that they should, and how to upgrade to
version 18.
It also reviews the confusing wording about "multiple" upgrades.
* * *
The only thing we cannot really do is stop a fresh install of 17 if
there was no previous install, as it cannot be detected. That makes a
useless upgrade forced for new users with old state versions.
It is also important to state that they must set their package to
Nextcloud 18, as future upgrades to Nextcloud will not allow an uprade
from 17!
I assume future warning messages will exist specifically stating what to
do to go from 18 to 19, then 19 to 20, etc...
This allows to have multiple certificates with the same common name.
Lego uses in its internal directory the common name to name the certificate.
fixes#84409
I've had Netdata crash on me sometimes. Rarely but more than once. And I lost days of data before I noticed.
Let's be nice and restart it on failures by default.
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
Instead of making the configuration less portable by hard coding the number of
jobs equal to the cores we can also let nix set the same number at runtime.
This prevents duplication in cross-compiled nixos machines. The
bootstrapped glibc differs from the natively compiled one, so we get
two glibc’s in the closure. To reduce closure size, just use
stdenv.cc.libc where available.
We have this bug https://github.com/elementary/gala/issues/636
when using notifications in gala. It's likely to not really be fixed
because all development is on the new notifications server.
Them removing cerbere and registering with the SessionManager
should make shutdown very fast. This was even done in plank [0]
which was the last factor outside cerbere causing this.
[0]]: a8d2f255b2
As discussed in https://github.com/NixOS/nixpkgs/pull/73763, prevailing
consensus is to revert that commit. People use the hardened profile on
machines and run nix builds, and there's no good reason to use
unsandboxed builds at all unless you're in a platform that doesn't
support them.
This reverts commit 00ac71ab19.
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.
In 7f838b4dde, we dropped systemd-udev-settle.service from display-manager.service's wants.
Unfortunately, we are doing something wrong since without it both Xorg and Wayland fail to start:
Failed to open gpu '/dev/dri/card0': GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Operation not permitted
Until we sort this out, let's add systemd-udev-settle.service to GDM to unblock the channels.
In contrast to `.service`-units, it's not possible to declare an
`overrides.conf`, however this is done by `generateUnits` for `.nspawn`
units as well. This change breaks the build if you have two derivations
configuring one nspawn unit.
This will happen in a case like this:
``` nix
{ pkgs, ... }: {
systemd.packages = [
(pkgs.writeTextDir "etc/systemd/nspawn/container0.nspawn" ''
[Files]
Bind=/tmp
'')
];
systemd.nspawn.container0 = {
/* ... */
};
}
```
This allows you to specify the system-wide flake registry. One use is
to pin 'nixpkgs' to the Nixpkgs version used to build the system:
nix.registry.nixpkgs.flake = nixpkgs;
where 'nixpkgs' is a flake input. This ensures that commands like
$ nix run nixpkgs#hello
pull in a minimum of additional store paths.
You can also use this to redirect flakes, e.g.
nix.registry.nixpkgs.to = {
type = "github";
owner = "my-org";
repo = "my-nixpkgs";
};
Many options define their example to be a Nix value without using
literalExample. This sometimes gets rendered incorrectly in the manual,
causing confusion like in https://github.com/NixOS/nixpkgs/issues/25516
This fixes it by using literalExample for such options. The list of
option to fix was determined with this expression:
let
nixos = import ./nixos { configuration = {}; };
lib = import ./lib;
valid = d: {
# escapeNixIdentifier from https://github.com/NixOS/nixpkgs/pull/82461
set = lib.all (n: lib.strings.escapeNixIdentifier n == n) (lib.attrNames d) && lib.all (v: valid v) (lib.attrValues d);
list = lib.all (v: valid v) d;
}.${builtins.typeOf d} or true;
optionList = lib.optionAttrSetToDocList nixos.options;
in map (opt: {
file = lib.elemAt opt.declarations 0;
loc = lib.options.showOption opt.loc;
}) (lib.filter (opt: if opt ? example then ! valid opt.example else false) optionList)
which when evaluated will output all options that use a Nix identifier
that would need escaping as an attribute name.
This windowManager and desktopManager doesn't even have
an option to use it. git history suggests to me that there's no way anyone
finds this useful anymore.
* creating a local backup
* creating a borgbackup server
* backing up to a borgbackup server
* hints about the Vorta graphical desktop application
* Added documentation about Vorta desktop client
Tested the examples locally and with my borgbase.com account.
This option allows replacing the tmpfs mounted on / by
the live CD's init script with a physical device
Since nixOS symlinks everything there's no trouble
at all.
That enables the user to easily use a nixOS live CD
as a portable installation.
Note that due to some limitations in how the store is mounted
currently only the non-store things are persisted.
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
After upgrading to NixOS 20.03, I've got the following warning:
nginx: [warn] could not build optimal types_hash, you should increase either types_hash_max_size: 2048 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size
The documentation states that "if nginx emits the message requesting
to increase either hash max size or hash bucket size then the first
parameter should first be increased" (aka types_hash_max_size).
In 19.03, the size of mime.types was around 100 entries. In 20.03, we
are around 900 entries. This is due to ff0148d868 which makes nginx
use mailcap mime.types.
In ff0148d868, nginx configuration was modified to use mime.types
from mailcap package as it is more complete. However, there are two
places where mime.types is included in configuration. When the user
was setting `cfg.httpConfig`, the mime.types from nginx was still
used. This commit fix that by moving the common snippet in a variable
of its own and ensure it is used at both places.
The volumeID will now be in the format of:
nixos-$EDITON-$RELEASE-$ARCH
an example for the minimal image would look like:
nixos-minimal-20.09-x86-64-linux
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
Make it clear that the warning is that updatedb will run as root, not
that locate will only run as root. Also explain how to silence the
warning.
Fixes#30864.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
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!
Running the manual on a TTY is useless in the graphical ISOs and not
particularly useful in non-graphical ISOs (since you can also run
'nixos-help').
Fixes#83157.
* Removed the use of gnome-screensaver (https://gitlab.gnome.org/GNOME/gnome-flashback/issues/18)
* Flashback's menu-related environment variables are now set in the gnome3.nix module instead of gnome-panel to resolve dependency conflict.
While renaming `networking.defaultMailServer` directly to
`services.ssmtp` is shorter and probably clearer, it causes eval errors
due to the second rename (directDelivery -> enable) when using e.g. `lib.mkForce`.
For instance,
``` nix
{ lib, ... }: {
networking.defaultMailServer = {
hostName = "localhost";
directDelivery = lib.mkForce true;
domain = "example.org";
};
}
```
would break with the following (rather confusing) error:
```
error: The option value `services.ssmtp.enable' in `/home/ma27/Projects/nixpkgs/nixos/modules/programs/ssmtp.nix' is not of type `boolean'.
(use '--show-trace' to show detailed location information)
```
Previously, the NixOS ACME module defaulted to using P-384 for
TLS certificates. I believe that this is a mistake, and that we
should use P-256 instead, despite it being theoretically
cryptographically weaker.
The security margin of a 256-bit elliptic curve cipher is substantial;
beyond a certain level, more bits in the key serve more to slow things
down than add meaningful protection. It's much more likely that ECDSA
will be broken entirely, or some fatal flaw will be found in the NIST
curves that makes them all insecure, than that the security margin
will be reduced enough to put P-256 at risk but not P-384. It's also
inconsistent to target a curve with a 192-bit security margin when our
recommended nginx TLS configuration allows 128-bit AES. [This Stack
Exchange answer][pornin] by cryptographer Thomas Pornin conveys the
general attitude among experts:
> Use P-256 to minimize trouble. If you feel that your manhood is
> threatened by using a 256-bit curve where a 384-bit curve is
> available, then use P-384: it will increases your computational and
> network costs (a factor of about 3 for CPU, a few extra dozen bytes
> on the network) but this is likely to be negligible in practice (in a
> SSL-powered Web server, the heavy cost is in "Web", not "SSL").
[pornin]: https://security.stackexchange.com/a/78624
While the NIST curves have many flaws (see [SafeCurves][safecurves]),
P-256 and P-384 are no different in this respect; SafeCurves gives
them the same rating. The only NIST curve Bernstein [thinks better of,
P-521][bernstein] (see "Other standard primes"), isn't usable for Web
PKI (it's [not supported by BoringSSL by default][boringssl] and hence
[doesn't work in Chromium/Chrome][chromium], and Let's Encrypt [don't
support it either][letsencrypt]).
[safecurves]: https://safecurves.cr.yp.to/
[bernstein]: https://blog.cr.yp.to/20140323-ecdsa.html
[boringssl]: https://boringssl.googlesource.com/boringssl/+/e9fc3e547e557492316932b62881c3386973ceb2
[chromium]: https://bugs.chromium.org/p/chromium/issues/detail?id=478225
[letsencrypt]: https://letsencrypt.org/docs/integration-guide/#supported-key-algorithms
So there's no real benefit to using P-384; what's the cost? In the
Stack Exchange answer I linked, Pornin estimates a factor of 3×
CPU usage, which wouldn't be so bad; unfortunately, this is wildly
optimistic in practice, as P-256 is much more common and therefore
much better optimized. [This GitHub comment][openssl] measures the
performance differential for raw Diffie-Hellman operations with OpenSSL
1.1.1 at a whopping 14× (even P-521 fares better!); [Caddy disables
P-384 by default][caddy] due to Go's [lack of accelerated assembly
implementations][crypto/elliptic] for it, and the difference there seems
even more extreme: [this golang-nuts post][golang-nuts] measures the key
generation performance differential at 275×. It's unlikely to be the
bottleneck for anyone, but I still feel kind of bad for anyone having
lego generate hundreds of certificates and sign challenges with them
with performance like that...
[openssl]: https://github.com/mozilla/server-side-tls/issues/190#issuecomment-421831599
[caddy]: 2cab475ba5/modules/caddytls/values.go (L113-L124)
[crypto/elliptic]: 2910c5b4a0/src/crypto/elliptic
[golang-nuts]: https://groups.google.com/forum/#!topic/golang-nuts/nlnJkBMMyzk
In conclusion, there's no real reason to use P-384 in general: if you
don't care about Web PKI compatibility and want to use a nicer curve,
then Ed25519 or P-521 are better options; if you're a NIST-fearing
paranoiac, you should use good old RSA; but if you're a normal person
running a web server, then you're best served by just using P-256. Right
now, NixOS makes an arbitrary decision between two equally-mediocre
curves that just so happens to slow down ECDH key agreement for every
TLS connection by over an order of magnitude; this commit fixes that.
Unfortunately, it seems like existing P-384 certificates won't get
migrated automatically on renewal without manual intervention, but
that's a more general problem with the existing ACME module (see #81634;
I know @yegortimoshenko is working on this). To migrate your
certificates manually, run:
$ sudo find /var/lib/acme/.lego/certificates -type f -delete
$ sudo find /var/lib/acme -name '*.pem' -delete
$ sudo systemctl restart 'acme-*.service' nginx.service
(No warranty. If it breaks, you get to keep both pieces. But it worked
for me.)
* nixos/nixpkgs.nix: Allow just using config in system
This assertion requires system to work properly. We might not have
this in cases where the user just sets config and wants Nixpkgs to
infer system from that. This adds a default for when this happens,
using doubleFromSystem.
* parens
`$toplevel/system` of a system closure with `x86_64` kernel and `i686` userland should contain "x86_64-linux".
If `$toplevel/system` contains "i686-linux", the closure will be run using `qemu-system-i386`, which is able to run `x86_64` kernel on most Intel CPU, but fails on AMD.
So this fix is for a rare case of `x86_64` kernel + `i686` userland + AMD CPU
Previously, systemd.network.links was only respected with networkd
enabled, but it's really udev taking care of links, no matter if
networkd is enabled or not.
With our module fixed, there's no need to manually manage the text file
anymore.
This was originally applied in 3d1079a20d,
but was reverted due to 1115959a8d causing
evaluation errors on hydra.
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.
Broken by 0f973e273c284a97a8dffeab7d9c0b09a88b7139 in #73533
The type of the checkReversePath option allows "strict" and "loose" as
well as boolean values.
If the host network stack is slow to start, the alertmanager fails to
start with this error message:
caller=main.go:256 msg="unable to initialize gossip mesh" err="create memberlist: Failed to get final advertise address: No private IP address found, and explicit IP not provided"
This bug can be reproduced by shutting down the network stack and
restarting the alertmanager.
Note I don't know why I didn't hit this issue with previous
alertmanager releases.
* 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.
Fixes some dependency ordering problems at boot time with services that
require DNS. Without Type=notify these services might be started before
stubby was ready to accept DNS requests.
The v7 series is very different.
This commit introduces the 3 packages: fahclient, fahcontrol and
fahviewer. It also rebuilds the NixOS module to map better with the new
client.
Previously the assertion passed if the kernel had support OR the
filter was *enabled*. In the case of a kernel without support, the
`checkReversePath` option defaulted to false, and then failed the
assertion.
...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.
extraModprobeConfig could be applied too late i.e. if the driver has been
loaded in initrd, while the harddrive is still encrypted.
Using a kernelParams works in all cases however.
To quote the XDG specification:
There is a single base directory relative to which user-specific
data files should be written. This directory is defined by the\
environment variable $XDG_DATA_HOME.
Rather than adding another directory to $HOME, I think that it's better
to follow this standard to avoid a cluttered home-dir.
Running haproxy with "DynamicUser = true" doesn't really work, since
it prohibits specifying a TLS certificate bundle with limited
permissions. This revives the haproxy user and group, but makes them
dynamically allocated by NixOS, rather than statically allocated. It
also adds options to specify which user and group haproxy runs as.
Previously, systemd.network.links was only respected with networkd
enabled, but it's really udev taking care of links, no matter if
networkd is enabled or not.
With our module fixed, there's no need to manually manage the text file
anymore.
This is to facilitate units that should _only_ be manually started and
not activated when a configuration is switched to.
More specifically this is to be used by the new Nixops deploy-*
targets created in https://github.com/NixOS/nixops/pull/1245 that are
triggered by Nixops before/after switch-to-configuration is called.
When blocklists are built with a derivation, using extraHosts would
require IFD, since the result of the derivation needs to be converted to
a string again.
By introducing this option no IFD is needed for such use-cases, since
the fetched files can be assigned directly.
- Fix misspelled option. mkRenamedOptionModule is not used because the
option hasn't really worked before.
- Add missing cfg.telemetryPath arg to ExecStart.
- Fix mkdir invocation in test.
The allowed values have changed in bd3319d28c.
0.15:
--log.level="info" Only log messages with the given severity or above. Valid levels: [debug, info, warn, error, fatal]
--log.format="logger:stderr"
Set the log target and format. Example: "logger:syslog?appname=bob&local=7" or "logger:stdout?json=true"
0.17:
--log.level=info Only log messages with the given severity or above. One of: [debug, info, warn, error]
--log.format=logfmt Output format of log messages. One of: [logfmt, json]
This avoids a possible surprise if the user is using `nixpkgs.system`
and `nesting.children`. `nesting.children` is expected to ignore all
parent configuration so we shouldn't propagate the user-facing option
`nixpkgs.system`. To avoid doing so, we introduce a new internal
option for holding the value passed to eval-config.nix, and use that
when recursing for nesting.
Add a cage module to nixos. This can be used to make kiosk-style
systems that boot directly to a single application. The user (demo by
default) is automatically logged in by this service and the
program (xterm by default) is automatically started.
This is useful for some embedded, single-user systems where we want
automatic booting. To keep the system secure, the user should have
limited privileges.
Based on the service provided in the Cage wiki here:
https://github.com/Hjdskes/cage/wiki/Starting-Cage-on-boot-with-systemd
Co-Authored-By: Florian Klink <flokli@flokli.de>
* prometheus-nginx-exporter: 0.5.0 -> 0.6.0
* nixos/prometheus-nginx-exporter: update for 0.6.0
Added new option constLabels and updated virtualHost name in the
exporter's test.
Prior to this fix, changes to certain settings would not be applied
automatically and users would have to know to manually restart the
affected service. A prime example of this is
`services.mailman.hyperkitty.baseUrl`, or various things that affect
`mailman3/settings.py`
The current weekly setting causes every NixOS server to try to renew
its certificate at midnight on the dot on Monday. This contributes to
the general problem of periodic load spikes for Let's Encrypt; NixOS
is probably not a major contributor to that problem, but we can lead by
example by picking good defaults here.
The values here were chosen after consulting with @yuriks, an SRE at
Let's Encrypt:
* Randomize the time certificates are renewed within a 24 hour period.
* Check for renewal every 24 hours, to ensure the certificate is always
renewed before an expiry notice is sent out.
* Increase the AccuracySec (thus lowering the accuracy(!)), so that
systemd can coalesce the renewal with other timers being run.
(You might be worried that this would defeat the purpose of the time
skewing, but systemd is documented as avoiding this by picking a
random time.)
The current behavior lets `system` default to
`builtins.currentSystem`. The system value specified to
`eval-config.nix` has very low precedence, so this should compose
properly.
Fixes#80806
Directory mode 755 is standard for running services. Without this,
downloadDirPermissions doesn't have any use since other users can't even
look inside the main transmission directory
* nixos/gdm: Fix pulseaudio tmpfiles structure
Fix the following startup failure of the sound service in the gdm
session that was introduced by #75893:
```
Feb 16 11:44:15 qp pulseaudio[1432]: W: [pulseaudio] core-util.c: Failed to open configuration file '/run/gdm/.config/pulse//daemon.conf': Not a directory
Feb 16 11:44:15 qp pulseaudio[1432]: W: [pulseaudio] daemon-conf.c: Failed to open configuration file: Not a directory
Feb 16 11:44:15 qp systemd[1380]: pulseaudio.service: Main process exited, code=exited, status=1/FAILURE
Feb 16 11:44:15 qp systemd[1380]: pulseaudio.service: Failed with result 'exit-code'.
Feb 16 11:44:15 qp systemd[1380]: Failed to start Sound Service.
```
Co-authored-by: worldofpeace <worldofpeace@protonmail.ch>
Note we're not using wayland default in the graphical media because it
could cause headaches for Nvidia users. But the session is still available
if someone logs out.
lego already bundles the chain with the certificate,[1] so the current
code, designed for simp_le, was resulting in duplicate certificate
chains, manifesting as "Chain issues: Incorrect order, Extra certs" on
the Qualys SSL Server Test.
cert.pem stays around as a symlink for backwards compatibility.
[1] 5cdc0002e9/acme/api/certificate.go (L40-L44)
This reverts commit 6a756af3e7.
Currently zshenv by default only set fpath and HELPDIR without exporting them.
A parent shell would also not set those variables usually as they are shell local.
It also sources a file called set-environment but this is protected by an
environment variable called __NIXOS_SET_ENVIRONMENT_DONE. Hence any modification
done by the parent shell should persist as long as __NIXOS_SET_ENVIRONMENT_DONE
is not unset.
This behavior deviates from what we do in bashrc and breaks common setups such
as tmux/mosh or screen.
Fixes#80437
This commit fixes#76620. It moves ExecStartPre and ExecStopPost to
preStart and postStop, as these options are composable. It thus allows
adding additional initialisation scripts or cleanup scripts to the systemd
unit of the docker container.
This leads to inconsistent results between local builds and
Hydra. Also Nix is not a general purpose language, we shouldn't be
parsing .git from inside Nix code.
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.
This option allows the user to control whether or not the docker container is
automatically started on boot. The previous default behavior (true) is preserved
* nixos/postgresql: support 0750 for data directory
This is rework of part of https://github.com/NixOS/nixpkgs/pull/46670.
My usecase was to be able to inspect PG datadir as wheel user.
PG11 now allows starting server with 0750 mask for data dir.
`groupAccess = true` now does this automatically. The only thing you have to do
is to set group ownership.
For PG10 and below, I've described a hack how this can be done. Before this PR
hack was impossible. The hack isn't ideal, because there is short
period of time when dir mode is 0700, so I didn't want to make it official.
Test/example is present too.
* postgresql: allow changing initidb arguments via module system
Closes https://github.com/NixOS/nixpkgs/issues/18829
+ some cleanups
* addressed review comments and some fixes
* whoops
* change groupAccess to tristate, to not force `chmod` on dataDir.
Making mask either 0700 or 0750 is too restrictive..
* WIP
* let's not support group mode for versions pre-11.
The only fix is to change mode to 0700 before start, because otherwise postgresql
doesn't start, and error is non-obvious.
In some cases, /dev/stderr may not point to a sensible location. For
example, running nixos-enter inside a systemd unit where the unit's
StandardOutput and StandardError are set to be sockets. In these
cases, this line would fail.
Piping to fd2 directly works just as well, even under strange and
twisted executions.
Co-authored-by: Michael Bishop <michael.bishop@iohk.io>
Originally added in [1], and iwd added StateDirectory to its services
in [2] -- 4 days later.
("StateDirectory wasn't used when tmpfile snippet was added to NixOS")
(nevermind git -> release delay)
[1] 6e54e9253a
[2] upstream iwd git rev: 71ae0bee9c6320dae0083ed8c1700bc8fff1defb
Some display managers (e.g. SDDM) set the XDG_CURRENT_DESKTOP variable accroding to this parameter.
If this variable is not defined, there will be some problems (e.g. MATE doesn't have icons on the desktop).
Fixes https://github.com/NixOS/nixpkgs/issues/71427
3c74e48d9c was a bit too much, it updated
permissions of all files recursively, causing files to be readable by
the group.
This isn't a problem immediately after bootup, but on a new activation,
as tmpfiles.d get restarted then, updating the permission bits of
now-existing files.
This updates the `Z` to be a `z` (the non-recursive variant), and adds a
`d` to ensure a directory is created (which should be covered by the
initrd shell script anyway)
Due to the support of the systemd-logind API the udev rules aren't
required anymore which renders this module useless [0].
Note: brightnessctl should now require a working D-Bus setup and a valid
local logind session for this to work.
[0]: https://github.com/NixOS/nixpkgs/pull/79663
"master" is not a valid SHA-1 commit hash, and it's not even
necessarily the branch used. 'nixos-version --revision' now returns an
error if the commit hash is not known.
Depending on the network management backend being used, if the interface
configuration in stage 1 is not cleared, there might still be some old
addresses or routes from stage 1 present in stage 2 after network
configuration has finished.
This makes predictable interfaces names available as soon as possible
with udev by adding the default network link units to initrd which are read
by udev. Also adds some udev rules that are needed but which would normally
loaded from the udev store path which is not included in the initrd.
invalid test was introduced in 297d1598ef
and it is disabled in the shipped daemon.conf.
I forgot to reflect that in the module, which caused the daemon to print the following on start-up:
FuEngine invalid has incorrect built version invalid
and the command to warn:
WARNING: The daemon has loaded 3rd party code and is no longer supported by the upstream developers!
To reduce the change of this happening in the future, I moved the list of default disabled plug-ins to the package expression.
I also set the value of the NixOS module option in the config section of the module instead of the default value used previously,
which will allow users to not care about these plug-ins.
We switched to unified default session option services.xserver.displayManager.defaultSession
and included fallback path for the legacy options. Unfortunately when only
services.xserver.windowManager.default is set and not services.xserver.desktopManager.default,
it got incorrectly converted to the new option.
This should fix that.
Closes: https://github.com/NixOS/nixpkgs/issues/76684
NixOS has `virtualisation.docker.autoPrune.enable` for this
functionality; we should not do it every time a container starts up.
(also, some trivial documentation fixes)
In 87a19e9048 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a5 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c7979. This was however wrong, as it "removed" master.
This reverts commit 0be87c7979.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048.
This reverts commit ac241fb7a5, reversing
changes made to 76a439239e.
Memtest86+ doesn't support EFI, so unfree Memtest86 is used when EFI
support is enabled (systemd-boot currently also uses Memtest86 when
memtest is enabled).
boot.specialFileSystems is used to describe mount points to be set up in
stage 1 and 2.
We use it to create /run/keys already there, so sshd-in-initrd scenarios
can consume keys sent over through nixops send-keys.
However, it seems the kernel only supports the gid=… option for tmpfs,
not ramfs, causing /run/keys to be owned by the root group, not keys
group.
This was/is worked around in nixops by running a chown root:keys
/run/keys whenever pushing keys [1], and as machines had to have pushed keys
to be usable, this was pretty much always the case.
This is causing regressions in setups not provisioned via nixops, that
still use /run/keys for secrets (through cloud provider startup scripts
for example), as suddenly being an owner of the "keys" group isn't
enough to access the folder.
This PR removes the defunct gid=… option in the mount script called in
stage 1 and 2, and introduces a tmpfiles rule which takes care of fixing
up permissions as part of sysinit.target (very early in systemd bootup,
so before regular services are started).
In case of nixops deployments, this doesn't change anything.
nixops-based deployments receiving secrets from nixops send-keys in
initrd will simply have the permissions already set once tmpfiles is
started.
Fixes#42344
[1]: 884d6c3994/nixops/backends/__init__.py (L267-L269)
* Fix documentation example for `jupyter.kernels`
The environment variable loading fails when using the example for `kernels` config, due to incorrect syntax. The error being something along the lines of `path not found`.
Thanks to @Infinisil and @layus for suggestions.
Minor incompatibilities due to moving to upstream defaults:
- capabilities are used instead of systemd.socket units
- the control socket moved:
/run/kresd/control -> /run/knot-resolver/control/1
- cacheDir moved and isn't configurable anymore
- different user+group names, without static IDs
Thanks Mic92 for multiple ideas.
Previously, some files were copied into the Nixpkgs tree, which meant
we wouldn't easily be able to update them, and was also just messy.
The reason it was done that way before was so that a few NixOS
options could be substituted in. Some problems with doing it this way
were that the _package_ changed depending on the values of the
settings, which is pretty strange, and also that it only allowed those
few settings to be set.
In the new model, mailman-web is a usable package without needing to
override, and I've implemented the NixOS options in a much more
flexible way. NixOS' mailman-web config file first reads the
mailman-web settings to use as defaults, but then it loads another
configuration file generated from the new services.mailman.webSettings
option, so _any_ mailman-web Django setting can be customised by the
user, rather than just the three that were supported before. I've
kept the old options, but there might not really be any good reason to
keep them.
We already had python3Packages.mailman, but that's only really usable
as a library. The only other option was to create a whole Python
environment, which was undesirable to install as a system-wide
package.
It's likely that a user might want to set multiple values for
relay_domains, transport_maps, and local_recipient_maps, and the order
is significant. This means that there's no good way to set these
across multiple NixOS modules, and they should probably all be set
together in the user's Postfix configuration.
So, rather than setting these in the Mailman module, just make the
Mailman module check that the values it needs to occur somewhere, and
advise the user on what to set if not.
This replaces all Mailman secrets with ones that are generated the
first time the service is run. This replaces the hyperkittyApiKey
option, which would lead to a secret in the world-readable store.
Even worse were the secrets hard-coded into mailman-web, which are not
just world-readable, but identical for all users!
services.mailman.hyperkittyApiKey has been removed, and so can no
longer be used to determine whether to enable Hyperkitty. In its
place, there is a new option, services.mailman.hyperkitty.enable. For
consistency, services.mailman.hyperkittyBaseUrl has been renamed to
services.mailman.hyperkitty.baseUrl.
Using a custom path in the Nix store meant that users of the module
couldn't add their own config files, which is a desirable feature. I
don't think avoiding /etc buys us anything.
This module allows root autoLogin, so we would break that for users, but
they shouldn't be using it anyways. This gives the impression like auto
is some special display manager, when it's just lightdm and special pam
rules to allow root autoLogin. It was created for NixOS's testing
so I believe this is where it belongs.
- the `imageFile` option allows to load an image from a derivation
- the `dependsOn` option can be used to specify dependencies between container systemd units.
Co-authored-by: Christian Höppner <mkaito@users.noreply.github.com>
Motivation:
if enableQuota is true, mail plugins cannot be enabled in extraConfig
because of the problem described here:
https://doc.dovecot.org/configuration_manual/config_file/config_file_syntax/#variable-expansion
doveconf: Warning: /etc/dovecot/dovecot.conf line 8: Global setting
mail_plugins won't change the setting inside an earlier filter at
/etc/dovecot/dovecot.conf line 5 (if this is intentional, avoid this
warning by moving the global setting before /etc/dovecot/dovecot.conf
line 5)
The current module assumes use of iptables and breaks if nftables is
used instead.
This change configures the correct backend based on the
config.networking.nftables.enable setting.
Aligned systemd service config with the definition in the upstream repo:
https://github.com/Irqbalance/irqbalance/blob/master/misc/irqbalance.service#L7.
Other than adding some level of sandboxing it also fixes the "Daemon
couldn't be bound to the file-based socket." warning reported on
irqbalance startup due to the fact that the "/run/irqbalance" directory
didn't exist. The "RuntimeDirectory" property makes sure it gets
created. The aforementioned warning didn't cause any problems I could
spot though.
I have verified that both `irqbalance` as well as `irqbalance-ui` work
fine with this new systemd service config.
Previously if ~/.background-image wasn't present, the background would
be set to black, which would override what the user could
set in e.g. services.xserver.windowManager.i3.extraSessionCommands
According to https://repology.org/repository/nix_unstable/problems, we have a
lot of packages that have http links that redirect to https as their homepage.
This commit updates all these packages to use the https links as their
homepage.
The following script was used to make these updates:
```
curl https://repology.org/api/v1/repository/nix_unstable/problems \
| jq '.[] | .problem' -r \
| rg 'Homepage link "(.+)" is a permanent redirect to "(.+)" and should be updated' --replace 's@$1@$2@' \
| sort | uniq > script.sed
find -name '*.nix' | xargs -P4 -- sed -f script.sed -i
```
* nixos/buildkite: drop user option
This reverts 8c6b1c3eaa.
Turns out, buildkite-agent has logic to write .ssh/known_hosts files and
only really works when $HOME and the user homedir are in sync.
On top of that, we provision ssh keys in /var/lib/buildkite-agent, which
doesn't work if that other users' homedir points elsewhere (we can cheat
by setting $HOME, but then getent and $HOME provide conflicting
results).
So after all, it's better to only run the system-wide buildkite agent as
the "buildkite-agent" user only - if one wants to run buildkite as
different users, systemd user services might be a better fit.
* nixosTests.buildkite-agent: add node with separate user and no ssh key
There is no need to stop/start the unit when the machine is online or
offline.
This should fix the shutdown locking issues.
nixos zerotier: sometimes it doesn't shutdown
On numerous occasions I have seen users mistake this
module as libinput because it being called "multitouch"
and them being unaware that the actually module they want
is libinput. They then run into several decrepit bugs due
to the completely out-of-date nature of the underlying package.
The underlying package hasn't been changed to an up-to-date
fork in a period of 8 years. I don't consider this to be production quality.
However, I'm not opposed for the module being readded to NixOS
with new packaging, and a better name.
Before c9214c394b and
9d396d2e42 if .git is symlink the version
would gracefully default to no git revision. With those changes an
exception is thrown instead.
This introduces a new function `pathIsGitRepo` that checks if
`commitIdFromGitRepo` fails without error so we don't have to
reimplement this logic again and can fail gracefully.
Some things were provided by default, some by systemd unit and some
were just miraculously working. This turns them into explicit
dependencies of the package itself, making everything properly
overrideable.
+ providing glibcLocales fixes elixir compile warnings
+ providing systemd dependency allows rabbit to use systemctl for unit
activation check instead of falling back to sleep. This was seen as
a warning during startup.
As of 2020-01-09, way-cooler is officially dead:
http://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html
hence, remove the package and the module.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
docs/release-notes: remove way-cooler
way-cooler: show warnings about removal
Apply suggestions from code review
Co-Authored-By: worldofpeace <worldofpeace@protonmail.ch>
way-cooler: add suggestion by @Infinisil
The php installer creates a random one, but we bypass it, so we have
to create one ourselves.
This should be backward compatible as encryption is used for session
cookies only: users at the time of the upgrade will be logged out but
nothing more.
259b7fa065/config/config.inc.php.sample (L73)
If the database is local, use postgres peer authentication.
Otherwise, use a password file.
Leave database initialisation to postgresql.ensure*.
Leave /var/lib/roundcube creation to systemd.
Run php upgrade script as unpriviledged user.
This gets passed to BUILDKITE_SHELL, which will specify the shell being
used to executes script in.
Defaults to `${pkgs.bash}/bin/bash -e -c`, matching how buildkite
behaves on other distros.
SSH public keys aren't needed to clone private repos, and if we only
need to configure a single attribute, there's no need for the "openssh"
attrset anymore.
This applies [hydra PR #432](https://github.com/NixOS/hydra/pull/432)
to the NixOS module in nixpkgs:
```
commit 4efd078977e5ea20e1104783efc324cba11690bc
Author: Bas van Dijk <v.dijk.bas@gmail.com>
Date: Sun Dec 11 15:35:38 2016 +0100
Only set buildMachinesFiles when nix.buildMachines is defined
```
The following commit from 2016 in hydra removed the `--option
build-use-substitutes` from the hydra-queue-runner service:
```
commit ee2e9f5335c8c0288c102975b506f6b275793cfe
Author: Eelco Dolstra <edolstra@gmail.com>
Date: Fri Oct 7 20:23:05 2016 +0200
Update to reflect BinaryCacheStore changes
BinaryCacheStore no longer implements buildPaths() and ensurePath(),
so we need to use copyPath() / copyClosure().
```
It would be better if the hydra module in NixOS matches the upstream
module.
This replaces some hardcoded values in nginx's VirtualHosts's
configuration with customizable options. Previous values are kept as
default, so nothing should break for existing users.
Co-Authored-By: Florian Klink <flokli@flokli.de>
Lego allows users to use the DNS-01 challenge to validate their
certificates. It is mostly backwards compatible, with a few
caveats.
- extraDomains can no longer have different webroots to the
main webroot for the cert.
- An email address is now mandatory for account creation
The following other changes were required:
- Deprecate security.acme.certs.<name>.plugins, as this was
specific to simp-le
- Rename security.acme.validMin to validMinDays, to avoid
confusion and errors. Lego requires the TTL to be specified in
days
- Add options to cover DNS challenge (dnsProvider,
credentialsFile, dnsPropagationCheck)
- A shared state directory is now used (/var/lib/acme/.lego)
to avoid account creation rate limits and share credentials
between certs
slapd does only print the error and not the line number.
Sometimes it is not even clear that it fails to start
due to an incorrect configuration file.
Example output of slaptest:
5e1b2179 /nix/store/gbn2v319d4qgw851sg41mcmjm5dpn39i-slapd.conf: line 134 objectClass: Missing closing parenthesis before end of input
ObjectClassDescription = "(" whsp
numericoid whsp ; ObjectClass identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
[ "SUP" oids ] ; Superior ObjectClasses
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
; default structural
[ "MUST" oids ] ; AttributeTypes
[ "MAY" oids ] ; AttributeTypes
whsp ")"
slaptest: bad configuration file!
Currently there is no way to set game settings, such as administrators.
extraSettings allows users to override default game settings without
adding many more settings.
The package option allows users to use the experimental version, or
override to a specific version with their own modified package.
Supporting a path here is important because it allows e.g. fetching a
configuration from a URL. To do this and provide the configuration as
a string, IFD would be necessary. It's just written into a path
anyway.
lib.commitIdFromGitRepo now resolves the refs from the
parent repository in case the supplied path is a file
containing the path to said repository. this adds support
for git-worktree and things alike. see gitrepository-layout(5).
this also:
- adds a new boolean function lib.pathIsRegularFile to
check whether a path is a regular file
- patches lib.revisionWithDefault and
the revision and versionSuffix attributes in
config.system.nixos in order to support git-worktrees
We should wait until after `multi-user.target` is triggered to allow
hardware to finish initializing, such as network devices and USB drives.
This ensures `powertop --auto-tune` sets more tunables to "Good".
Fixes#66820
Fixes this error from `nixos-rebuild switch` introduced by #75893:
setting up tmpfiles
[/etc/tmpfiles.d/nixos.conf:7] Invalid age 'yes'.
warning: error(s) occurred while switching to the new configuration
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
In some cases like we've noticed in https://github.com/NixOS/nixpkgs/issues/76169,
having duplicate packages in systemd.packages like
```
systemd.packages = [ gnome-shell gnome-shell gnome-session ];
```
breaks.
Here we use an associative array to ensure no
duplicate paths when we symlink all the units listed
in systemd.packages.
This fixes the dhcpcd issue in https://github.com/NixOS/nixpkgs/issues/76969,
which was exposed by https://github.com/NixOS/nixpkgs/pull/75031
introducing changes in the module ordering and therefore option ordering
too.
The dhcpcd issue would also be fixable by explicitly putting
dhcpcd's paths before others, however it makes more sense for systemd's
default paths to be after all others by default, since they should only
be a fallback, which is how binary finding will work if they come after.
###### Motivation for this change
With space between two options, multiple options just don't work
Looks like xkbOptions then used for generation of xorg.conf.d/00-keyboard.conf.
kbd's man says XkbOptions must be comma-separated without spaces.
https://linux.die.net/man/4/kbd
###### Things done
<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->
- [ ] Tested using sandboxing ([nix.useSandbox](http://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS, or option `sandbox` in [`nix.conf`](http://nixos.org/nix/manual/#sec-conf-file) on non-NixOS linux)
- Built on platform(s)
- [ ] NixOS
- [ ] macOS
- [ ] other Linux distributions
- [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review wip"`
- [ ] Tested execution of all binary files (usually in `./result/bin/`)
- [ ] Determined the impact on package closure size (by running `nix path-info -S` before and after)
- [ ] Ensured that relevant documentation is up to date
- [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md).
###### Notify maintainers
cc @
Currently if you specify home to be someplace else than ~/ for user
then Transmissions always attempts to load the config from the
default location which is $HOME/.config/transmission-daemon based on documentation:
https://github.com/transmission/transmission/wiki/Configuration-Files
Which means that the changes done to the config under settingsDir in
ExecPreStart have no effect because they are modifying a file that is never loaded.
I've added an explicit --config-dir ${settingsDir} to make sure
that Transmission loads the correct config file even when home is changed.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Previously, we were storing the leader pid in a runtime file and
signalled SIGRTMIN+4 manually.
In systemd 219, the `machinectl poweroff` command was introduced, which
does that for us.
* structured config for main config file allows to launch nagios in
debug mode without having to write the whole config file by hand
* build time syntax check
* all options have types, one more example
* I find it misleading that the main nagios config file is linked in
/etc but that if you change the link in /etc/ and restart nagios, it
has no effect. Have nagios use /etc/nagios.cfg
* fix paths in example nagios config files, which allows to reuse it:
services.nagios.objectDefs =
(map (x: "${pkgs.nagios}/etc/objects/${x}.cfg")
[ "templates" "timeperiods" "commands" ]) ++ [ ./main.cfg ]
* for the above reason, add mailutils to default plugins
Co-Authored-By: Aaron Andersen <aaron@fosslib.net>
xsession gets passed `dm` `wm`, so the desktop manager would be launched
before the window manager resulting in a regular desktop manager
session.
Fixes https://github.com/NixOS/nixpkgs/issues/76625
The missing `\n` in the printf format string prevented multiple channels from
being logged.
The missing `nixpkgs=` in the `NIX_PATH` prevented `nixos-rebuild` from working
if the system configuration has any reference to `nixpkgs`.
Additionally:
* Use process substitution instead of piping printf to avoid creating a subshell.
* Set an empty `IFS` to avoid word splitting.
* Add the `-r` flag to `read` to avoid mangling backslashes.
This fixes a harmless error from systemd-udevd that looks like:
Dec 23 15:35:23 dellbook systemd-udevd[696]:
/nix/store/iixya3ni5whybpq9zz1h7f4pyw7nhd19-udev-rules/99-local.rules:25
Invalid value "..." for RUN (char 101: invalid substitution type),
ignoring, but please fix it.
Using $$ fixes it using the escaping documented at https://www.freedesktop.org/software/systemd/man/udev.html.
The commit b0bbacb521 was a bit too fast
It did set executable bit for log files.
Also, it didn't account for other directories in state dir:
```
# ls -la /var/spool/nginx/
total 32
drwxr-x--- 8 nginx nginx 4096 Dec 26 12:00 .
drwxr-xr-x 4 root root 4096 Oct 10 20:24 ..
drwx------ 2 root root 4096 Oct 10 20:24 client_body_temp
drwx------ 2 root root 4096 Oct 10 20:24 fastcgi_temp
drwxr-x--- 2 nginx nginx 4096 Dec 26 12:00 logs
drwx------ 2 root root 4096 Oct 10 20:24 proxy_temp
drwx------ 2 root root 4096 Oct 10 20:24 scgi_temp
drwx------ 2 root root 4096 Oct 10 20:24 uwsgi_temp
```
With proposed change, only ownership is changed for state files, and mode is left as is
except that statedir/logs is now group accessible.
This change brings pre-existing installations (where the logfiles
are owned by root) in line with the new permssions (where logfiles
are owned by the nginx user)
Currently to run borg job manually, you have to use systemctl:
```
$ systemctl start borgbackup-job-jobname.service
```
This commit makes wrappers around borg jobs available in $PATH, which have
BORG_REPO and connection args set correctly:
```
$ borg-job-jobname list
$ borg-job-jobname mount ::jobname-archive-2019-12-25T00:01:29 /mnt/some-path
$ borg-job-jobname create ::test /some/path
```
Closes: https://github.com/NixOS/nixpkgs/pull/64888
Co-authored-by: Danylo Hlynskyi <abcz2.uprola@gmail.com>
Currently, LXD always use pkgs.zfs, even if boot.zfs.enableUnstable is set. This
change provides the option to change the LXC, LXD and ZFS packages, and
determines the default ZFS package based on zfs.enableUnstable.
When installing a fresh NixOS system it occasionally happens that you
encounter issues that are rather hard to track down since
`nixos-install(8)` doesn't provide any debugging flags.
This patch adds `-L` to force `nix build` to display the build-log on
stderr and `-v` to increase the log-level of Nix.
