Otherwise netdata will not find python modules.
To make sure netdata still pick up our setuid version of apps.plugin
we rename the original executable.
These days build systems are more robust w.r.t. to concurrency.
Most users will have at least two cores in their machines.
Therefore I suggest to increase the number of cores used for building.
fixes#50376
Imports the `journaldriver` module into the top-level NixOS module
list to make it usable without extra work.
This went unnoticed in #42134 (mostly because my setup imports modules
explicitly from pinned versions).
Fixes#50390
Based on reports X wouldn't start out of the box and seems OK now.
In case there are still some problems, we can improve later.
I checked that nixos.tests.virtualbox.* still succeed.
This will make the list much easier to re-use, eg. for `nixosTests`
The drawback is that this approaches makes the
```
nix-build release.nix -A tests.opensmtpd.x86_64-linux
```
command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs`
once for each architecture, instead of just having the hardcoded list of
tests that allowed to say “ok just evaluate for x86_64-linux”.
On the other hand, complete evaluation of `release.nix` should be much
faster because we no longer import `nixpkgs` for each test: testing with
the following command went from 30s to 18s, and that's just for a few
tests.
```
time nix-instantiate --eval --strict nixos/release.nix -A tests.nat
```
I initially wanted to test on the whole `release.nix`, but there are too
many broken tests and it takes too long to eval them all, especially
compared to the fact that the current implementation breaks some setup.
Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds
like an overall win.
By using types.lines for 'config', we can specify monit configurations
in lots of modules and they can all be automatically combined together
with newlines. This is desireable because different modules might want
to each specify the small monitoring task specific to their service.
This commit also updates the module to use current idioms.
The `rmilter` module has options for configuring `postfix` to use it but
since that module is deprecated because rspamd now has a builtin worker
that supports the milter protocol this commit adds similar `postfix`
integration options directly to the `rspamd` module.
* Added license: GPLv2.
* Updated homepage and description.
* CFLAGS are no longer necessary as of version 2.2.0.
* Option '-a ::' is no longer necessary as of version 2.2.0.
While this seems silly at first (it's already given as start parameter
to mysqld), it seems like xtrabackup needs that sometimes.
Without it, a Galera cluster cannot be run using the xtrabackup
replication method.
The lines stored in `extraConfig` and `worker.<name?>.extraConfig`
should take precedent over values from included files but in order to do
this in rspamd UCL they need to be stored in a file that then gets
included with a high priority. This commit uses the overrides option to
store the value of the two `extraConfig` options in `extra-config.inc`
and `worker-<name?>.inc` respectively.
When the workers option for rspamd was originally implemented it was
based on a flawed understanding of how workers are configured in rspamd.
This meant that while rspamd supports configuring multiple workers of
the same type, so that different controller workers could have different
passwords, the NixOS module did not support this because it would write
an invalid configuration file if you tried.
Specifically a configuration like the one below:
```
workers.controller = {};
workers.controller2 = {
type = "controller";
};
```
Would result in a rspamd configuration of:
```
worker {
type = "controller";
count = 1;
.include "$CONFDIR/worker-controller.inc"
}
worker "controller2" {
type = "controller";
count = 1;
}
```
While to get multiple controller workers it should instead be:
```
worker "controller" {
type = "controller";
count = 1;
.include "$CONFDIR/worker-controller.inc"
}
worker "controller" {
type = "controller";
count = 1;
}
```
When implementing #49620 I included an enable option for both the
locals and overrides options but the code writing the files didn't
actually look at enable and so would write the file regardless of its
value. I also set the type to loaOf which should have been attrsOf
since the code was not written to handle the options being lists.
This fixes both of those issues.
With `promtool` we can check the validity of a configuration before
deploying it. This avoids situations where you would end up with a
broken monitoring system without noticing it - since the monitoring
broke down. :-)
Gluster's pidfile handling is bug-ridden.
I have fixed https://bugzilla.redhat.com/show_bug.cgi?id=1509340
in an attempt to improve it but that is far from enough.
The gluster developers describe another pidfile issue as
"our brick-process management is a total nightmare", see
f1071f17e0/xlators/mgmt/glusterd/src/glusterd-utils.c (L5907-L5924)
I have observed multiple cases where glusterd doesn't start correctly
and systemd doesn't notice because of the erroneous pidfile handling.
To improve the situation, we don't let glusterd daemonize itself any more
and instead use `--no-daemon` and the `Simple` service type.
Removes the old UI build tooling; it is no longer necessary
because as of 1.2.0 it's bundled into the server binary.
It doesn't even need to have JS built, because it's bundled into
the release commit's source tree (see #48714).
The UI is enabled by default, so the NixOS service is
updated to directly use `ui = webUi;` now.
Fixes#48714.
Fixes#44192.
Fixes#41243.
Fixes#35602.
Signed-off-by: Niklas Hambüchen <mail@nh2.me>
Merging staging into staging-next even though we haven't merged staging-next into master yet.
The motivation for this merge is that it's been a while since we merged into master causing
the 3 branches to diverge too much.
This module permits to preload Docker image in a VM in order to reduce
OIs on file copies. This module has to be only used in testing
environments, when the test requires several Docker images such as in
Kubernetes tests. In this case,
`virtualisation.dockerPreloader.images` can replace the
`services.kubernetes.kubelet.seedDockerImages` options.
The idea is to populate the /var/lib/docker directory by mounting qcow
files (we uses qcow file to avoid permission issues) that contain images.
For each image specified in
config.virtualisation.dockerPreloader.images:
1. The image is loaded by Docker in a VM
2. The resulting /var/lib/docker is written to a QCOW file
This set of QCOW files can then be used to populate the
/var/lib/docker:
1. Each QCOW is mounted in the VM
2. Symlink are created from these mount points to /var/lib/docker
3. A /var/lib/docker/image/overlay2/repositories.json file is generated
4. The docker daemon is started.
