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.
