pam_mkhomedir should create homedirs with the same umask as the rest
of the system. Currently it creates homedirs with go+rx which makes
it readable for other non-privileged users.
The default has been unchanged for a decade. Space is cheaper and
software catches up with that. Let's not make our testing harder
than necessary by default.
Use service internal bind mounts instead of global ones.
This also moves the logs to /var/log/unifi on the host
and the run directory to /run/unifi.
Closes#61424
In 780135ad5ce54a6b3e7dfb35e3b596757e2ea6f8 the nodes for testing Deluge
1.x were removed, but the test script still referred to it.
This removes the references in the test script and also renames the
nodes to drop the 2 suffix.
The new option `services.prometheus.enableReload` has been introduced
which, when enabled, causes the prometheus systemd service to reload
when its config file changes.
More specifically the following property holds: switching to a
configuration (`switch-to-configuration`) that changes the prometheus
configuration only finishes successully when prometheus has finished
loading the new configuration.
`enableReload` is `false` by default in which case the old semantics
of restarting the prometheus systemd service are in effect.
- Add HDFS journalnode and ZKFC services
- Test failover of HDFS and YARN master services in full hadoop test
- Check if a minimal HDFS cluster works in the minimal HDFS test
The parentheses prevent the `continue` line from working by running the
enclosed in a subshell -- I noticed that ZFS would start asking me for
my password to encrypted child datasets, even though they were not
specified in `requestEncryptionCredentials`. The following logs would
also be present in the import unit's journal:
Oct 31 22:13:17 host systemd[1]: Starting Import ZFS pool "pool"...
Oct 31 22:13:44 host zfs-import-pool-start[3711]: importing ZFS pool "pool"...
Oct 31 22:13:44 host zfs-import-pool-start[4017]:pool/nix/store/39zij3xcxn4w38v6x8f88bx8y91nv0rm-unit-script-zfs-import-pool-start/bin/zfs-import-pool-start: line 31: continue: only meaningful in a `for', `while', or `until' loop
Oct 31 22:13:44 host zfs-import-pool-start[4020]:pool/nix/store/39zij3xcxn4w38v6x8f88bx8y91nv0rm-unit-script-zfs-import-pool-start/bin/zfs-import-pool-start: line 31: continue: only meaningful in a `for', `while', or `until' loop
Oct 31 22:15:14 host zfs-import-pool-start[4023]: Failed to query password: Timer expired
Oct 31 22:15:14 host zfs-import-pool-start[4024]: Key load error: encryption failure
Oct 31 22:15:14 host systemd[1]: zfs-import-pool.service: Main process exited, code=exited, status=255/EXCEPTION
Oct 31 22:15:14 host systemd[1]: zfs-import-pool.service: Failed with result 'exit-code'.
Oct 31 22:15:14 host systemd[1]: Failed to start Import ZFS pool "pool".
Details on https://github.com/NixOS/nixops/issues/1063#issuecomment-453253666.
`partOf` makes that if `smokeping.service` is stopped, `thttpd.service` will
be stopped as well.
(But not that `thttpd` will be started when `smokeping` is started).
Once `thttpd.service` is stopped that way, `Restart = always` will not apply.
When the smokeping config options are changed, NixOS's `switch-configuration.pl`
will stop `smokeping` (whit shuts down thttpd due to `partOf`), and then restart
smokeping; but this does not start thttpd.
As a result, thttpd will be off after changing the config, which isn't desired.
This commit fixes it by removing the `partOf`, which makes `Restart` work
as expected.
This avoids a common problem:
Until now, port forwarding to multiple hosts running smokeping did not work;
they all show the data of the first smokeping instance.
That ws because the image URLs generated by smokeping are absolute
(`imgurl` setting).
Consequently, if you ran
ssh node-1 -L 8081:localhost:8081
ssh node-2 -L 8081:localhost:8082
ssh node-3 -L 8081:localhost:8083
and try to open http://localhost:8081, http://localhost:8082 and
http://localhost:8083, they all would show the images of node-1!
Using a relative `imgurl` fixes that.
As per smokeping docs on `imgurl`:
> Either an absolute URL to the `imgcache` directory or one relative to the
> directory where you keep the SmokePing cgi.
qemu_kvm is only built for one architecture, so it's smaller and takes
MUCH less time to build if it has to be built from source. And this
module doesn't support running a VM for one architecture from another
architecture, so the one architecture is all we'll need.
Some upstream changes broke the automatic fallback to SwiftShader.
Without this workaround the GPU initialization fails (apparently due to requiring Vulkan):
machine # libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
machine # [1001:1001:1101/104304.000625:ERROR:viz_main_impl.cc(161)] Exiting GPU process due to errors during initialization
machine # libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
machine # [1052:1052:1101/104305.060496:ERROR:viz_main_impl.cc(161)] Exiting GPU process due to errors during initialization
machine # [1084:1084:1101/104305.165898:ERROR:angle_platform_impl.cc(44)] Display.cpp:894 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-3): Initialization of an object could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1048.
machine # [1084:1084:1101/104305.171191:ERROR:gl_surface_egl.cc(782)] EGL Driver message (Critical) eglInitialize: Internal Vulkan error (-3): Initialization of an object could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1048.
machine # [1084:1084:1101/104305.178707:ERROR:gl_surface_egl.cc(1382)] eglInitialize SwANGLE failed with error EGL_NOT_INITIALIZED
machine # [1084:1084:1101/104305.180111:ERROR:gl_ozone_egl.cc(20)] GLSurfaceEGL::InitializeOneOff failed.
machine # [1084:1084:1101/104305.189760:ERROR:viz_main_impl.cc(161)] Exiting GPU process due to errors during initialization
machine # [1092:1092:1101/104305.233470:ERROR:gpu_init.cc(457)] Passthrough is not supported, GL is disabled, ANGLE is
This workaround restores the previous result:
machine # [1004:1004:1101/104551.131190:ERROR:gpu_init.cc(457)] Passthrough is not supported, GL is swiftshader, ANGLE is
The workaround is only required for Chromium, not Google Chrome.
This reverts commit e2bea4427b.
While this commit was probably fine, I want to be conservative
with changes right before the release branch-off.
So far the extendModules commits have been adding and refactoring
expressions that did not affect derivation hashes, whereas this
commit changes the module ordering. I will open a separate PR for
it.
The involved test was nixosTests.nextcloud.basic21.
It has a testScript that is strict in nodes.nextcloud.config.system.build.vm,
in assertions about imagemagick being in the system closure.
The recursion was introduced in 329a4461a7 from
https://github.com/NixOS/nixpkgs/pull/140792
Some specialisations (such as those which affect various boot-time
attributes) cannot be switched to at runtime. This allows picking the
specialisation at boot time.
This adds a `wantedBy` clause to the user systemd service for
yubikey-agent, to ensure an enabled agent is started on boot. This
brings the behavior inline with existing documentation.
If the user has selected a graphical pinentry program, then we need to
wait for the graphical environment to exist before starting the
yubikey-agent. I've found that if we start the agent earlier it will
fail when we perform an ssh command later.
Massively reduce the time it takes running the test by building a
proper root disk image and increasing the virtualized core count to
4. This should make it much easier for the tests to pass even on
weaker systems.
With my laptop (AMD Ryzen 7 PRO 2700U) as the reference system, I see
the following test run times:
- No change:
Times out after 28 mins
- Building a root image:
7 mins, 48 secs
- Building a root image and bumping the core count:
7 mins, 17 secs
The times include the time it takes to build the image
(~1 min, 20 secs).
Massively reduce the time it takes running the test by building a
proper root disk image and increasing the virtualized core count to
4. This should make it much easier for the tests to pass even on
weaker systems.
With my laptop (AMD Ryzen 7 PRO 2700U, 32GB RAM) as the reference
system, I see the following test run times:
- No change:
25 mins, 49 secs
- Building a root image:
4 mins, 44 secs
- Building a root image and bumping the core count:
3 mins, 6 secs
The times include the time it takes to build the image (~40 secs).
Make sure the all derivations referenced by the test script are
available on the nodes. Accessing these derivations works just fine
without this change when using 9p to mount the host's store, but when
an image is built (virtualisation.buildRootImage), the dependencies
need to be copied to the image. We don't want to copy the script
itself, though, since that would trigger unnecessary image rebuilds.
pathsInNixDB isn't a very accurate name when a Nix store image is
built (virtualisation.useNixStoreImage); rename it to additionalPaths,
which should be general enough to cover both cases.
Add the `useNixStoreImage` option, allowing a disk image with the
necessary contents from the Nix store to be built using
make-disk-image.nix. The image will be mounted at `/nix/store` and
acts as a drop-in replacement for the usual 9p mounting of the host's
Nix store.
This removes the performance penalty of 9p, drastically improving
execution speed of applications which do lots of reads from the Nix
store. The caveats are increased disk space usage and image build
time.
Add a copyChannel argument which controls whether the current source
tree will be made available as a nix channel in the image or
not. Previously, it always was. Making it available is useful for
interactive use of nix utils, but changes the hash of the image when
the sources are updated.
the `nixos-rebuild` command has multiple subcommands, and not each of
them would fix the problem of a large `/boot` partition, so let’s be
more precise here.
