In fontconfig’s 60-generic.conf, order of preference is estabilished for emoji
font family. Because fontconfig parses the config files in lexicographic order,
appending each <prefer> from <alias> element to the family’s prefer list
(to be prepended before the family) [1], our font family defaults stored
in 52-nixos-default-fonts.conf will take precedence. That is, of course, unless
the default „weak“ binding [2] is used. Emoji family binds strongly [3],
so we need to set binding to “same” for our <alias>es to be considered before
the ones from 60-generic.conf.
By default, we will set the option to all emoji fonts supported by fontconfig,
so that emoji works for user if they have at least one emoji font installed.
If they have multiple emoji fonts installed, we will use the fontconfig’s
order of preference [4].
[1]: https://github.com/bohoomil/fontconfig-ultimate/issues/51#issuecomment-64678322
[2]: https://www.freedesktop.org/software/fontconfig/fontconfig-user.html#AEN25
[3]: cc8442dec8
[4]: c41c922018
It currently lacks an emoji font-family which means it has to be
disabled for them to function [0]. Additionally it's fallen out of
necessity to ship custom font rendering settings (as far as I'm aware
of).
[0]: https://github.com/NixOS/nixpkgs/pull/67215
We don’t want any trailing whitespace, otherwise we mess up the
formating of the shadow file. Some things like readFile may have the
trailing new line.
Fixes#66745
This module correctly includes the vte.sh script
required for vte terminals like gnome-terminal to show the
CWD in the window title and preserved across instances.
This is achieved with the options:
* programs.bash.vteIntegration
* programs.zsh.vteIntegration
as it's best to keep this configuration unguarded by gnome3.enable
to support other vte terminals (such as elementary-terminal).
Note the distinction between Zsh and Bash doesn't include
a different script, as this script only supports those two shells.
systemd provides two sysctl snippets, 50-coredump.conf and
50-default.conf.
These enable:
- Loose reverse path filtering
- Source route filtering
- `fq_codel` as a packet scheduler (this helps to fight bufferbloat)
This also configures the kernel to pass coredumps to `systemd-coredump`.
These sysctl snippets can be found in `/etc/sysctl.d/50-*.conf`,
and overridden via `boot.kernel.sysctl`
(which will place the parameters in `/etc/sysctl.d/60-nixos.conf`.
Let's start using these, like other distros already do for quite some
time, and remove those duplicate `boot.kernel.sysctl` options we
previously did set.
In the case of rp_filter (which systemd would set to 2 (loose)), make
our overrides to "1" more explicit.
sysctl.d(5) recommends prefixing all filenames in /etc/sysctl.d with a
two-digit number and a dash, to simplify the ordering of the files.
Some packages provide custom files, often with "50-" prefix.
To ensure user-supplied configuration takes precedence over the one
specified via `boot.kernel.sysctl`, prefix the file generated there with
"60-".
This change is needed because the order of profiles correlate to the
order in PATH, therefore "/etc/profiles/per-user/$USER" always appeared
after the system packages directories.
If lib.optional is given a false value it will return an empty list.
Thusly the set-environment script can have
```
export GTK_USE_PORTAL=
```
This can rub certain bugs the wrong way #65679
so lets make sure this isn't set in the environment
at all.
Prior to this change GTK_USE_PORTAL was unconditionally
set to "1". For this to not break things you have to have some
sort of portal implementation in extraPortals.
Setting GTK_USE_PORTAL in this manner is actually only useful
when using portals for applications outside flatpak. For example
people using non-flatpak Firefox who want native filechoosers.
It's also WIP for electron applications to support this.
Left to do: re-enable as needed in the usual situations.
This added ~286MiB to the base system closure, which is enough to bring
the sd images over the limit allowed on Hydra.
This is a refactor of how resolvconf is managed on NixOS. We split it
into a separate service which is enabled internally depending on whether
we want /etc/resolv.conf to be managed by it. Various services now take
advantage of those configuration options.
We also now use systemd instead of activation scripts to update
resolv.conf.
NetworkManager now uses the right option for rc-manager DNS
automatically, so the configuration option shouldn't be exposed.
This is more robust than setting via environment variable, though it does come
later in the load sequence. An added benefit is affecting the current
session.
Add an option to set the rc-manager parameter in NetworkManager.conf,
which controls how NetworkManager handles resolv.conf. This sets the
default rc-manager to "resolvconf", which solves #61490. It
additionally allows the user to change rc-manager without interference
from configuration activations.
Back in 2013, update-mime-database started using fdatasync() to write out
its changes after processing each file in /share/mime, with the reasoning
that a corrupted database from an interruption midway would be
problematic for applications[1]. Unfortunately, this caused a
significant regression in the time required to run update-mime-database:
commonly from under a second to half a minute or more.
This delay affects the time required to build system-path on NixOS, when
xdg.mime.enable is true (the default). For example, on one of my systems
system-path builds in ~48 seconds, 45 of which are update-mime-database.
This makes rapidly building new system configurations not fun.
This commit disables the calls to fdatasync(). update-mime-database
checks an environment variable, PKGSYSTEM_ENABLE_FSYNC, to determine
whether it should sync, and we can set this to false. system-path
already only has whatever filesystem commit guarantees that the Nix
builder provides. Furthermore, there is no risk of a failed MIME
database update messing up existing packages, because this is Nix.
(This issue was also reported at and discussed by Debian, Red Hat, and
Gentoo at least.)
[1] https://bugs.freedesktop.org/show_bug.cgi?id=70366
Currently, this uses the somewhat crude method of setting LD_PRELOAD in the
system environment. This works, but should be considered a stepping stone to
a more robust solution.
eb90d97009 broke nslcd, as /run/nslcd was
created/chowned as root user, while nslcd wants to do parts as nslcd
user.
This commit changes the nslcd to run with the proper uid/gid from the
start (through User= and Group=), so the RuntimeDirectory has proper
permissions, too.
In some cases, secrets are baked into nslcd's config file during startup
(so we don't want to provide it from the store).
This config file is normally hard-wired to /etc/nslcd.conf, but we don't
want to use PermissionsStartOnly anymore (#56265), and activation
scripts are ugly, so redirect /etc/nslcd.conf to /run/nslcd/nslcd.conf,
which now gets provisioned inside ExecStartPre=.
This change requires the files referenced to in
users.ldap.bind.passwordFile and users.ldap.daemon.rootpwmodpwFile to be
readable by the nslcd user (in the non-nslcd case, this was already the
case for users.ldap.bind.passwordFile)
fixes#57783
users.ldap.daemon.rootpwmodpw -> users.ldap.daemon.rootpwmodpwFile
users.ldap.bind.password -> users.ldap.bind.passwordFile
as users.ldap.daemon.rootpwmodpw never was part of a release, no
mkRenamedOptionModule is introduced.
The motivation for this is that some applications are unaware
of this feature and can set their volume to 100% on startup
harming people ears and possiblly blowing someone's audio
setup.
I noticed this in #54594 and by extension epiphany[0].
Please also note that many other distros have this default for
the reason outlined above.
Closes#5632#54594
[0]: https://bugzilla.gnome.org/show_bug.cgi?id=675217
This creates a dependency cycle when used with boot.tmpOnTmpfs:
basic.target <- tmp.mount <- swap.target <- zram-init-dev0 <- basic.target
This same fix is done already for tmp.mount
Fixes https://github.com/NixOS/nixpkgs/issues/47474
- add `zramSwap.algorithm` option, which allows to change compressor
declaratively. zstd as default
- add `zramSwap.swapDevices` option, which allows to define how many zram
devices will be used as swap. Rest devices can be managed freely
- simpler floating calculations
- fix udev race condition
- some documentation changes
- replaced `/sys/block/zram*` handling with `zramctl`, because I had occasional
"Device is busy" error (looks like zram has to be configured in predefined order)
- added `memoryPercent` and `algorithm` as restart triggers. I think, it was
a bug that changing `memoryPercent` in configuration wasn't applied immediately.
- removed a bind to .swap device. While it looks natural (when swap device goes
off, so should zram device), it wasn't implemented properly. This caused problems
with swapon/swapoff:
```
$ cat /proc/swaps
Filename Type Size Used Priority
/dev/zram0 partition 8166024 0 -2
/var/swapfile file 5119996 5120 1
$ sudo swapoff -a
$ sudo swapon -a
swapon: /dev/zram0: read swap header failed
$ cat /proc/swaps
Filename Type Size Used Priority
/var/swapfile file 5119996 0 1
```
The aim is to minimize surprises: when the user explicitly installs a
package in their configuration, it should override any package
implicitly installed by NixOS.
It's a quick approximation to unblock unstable channels after #48116.
This commit isn't ideal, as I suspect most wayland users won't have
xserver.enable, so they will lose the icon cache in case they had gtk
in system path (otherwise they didn't get cache anyway).
I considered using environment.noXlibs, but the nixos tests installing
headless systems do *not* get that option, so we would still be pulling
gtk in many cases where it's clearly not desired. We need to design
this more carefully.
Several service definitions used `mkEnableOption` with text starting
with "Whether to", which produced funny option descriptions like
"Whether to enable Whether to run the rspamd daemon..".
This commit corrects this, and adds short descriptions of services
to affected service definitions.
We use `127.0.1.1` instead of `127.0.0.1` because some applications will fail if
`127.0.0.1` resolves to something other than `localhost`.
Debian does the same.
See #1248 and #36261.
Since `networking.hosts` is properly typed all of that magic `/etc/hosts` generator
does can be dropped. People that disagree with the value of `networking.hosts` can
simply `mkForce`.
For update-mime-database to work, you must have to have some mime
packages installed. In some DEs like XFCE this is not guaranteed to
happen. In that case just skip the update-mime-database call.
Fixes#46162
A shared exported guard `__NIXOS_SET_ENVIRONMENT_DONE` is introduced that can
be used to prevent child shells from sourcing `system.build.setEnvironment`
the second time.
This fixes e.g. `nix run derivation` when run from e.g. ZSH through the console or
ssh. Before this Bash would resource the common environment resetting the `PATH`
environment variable.
We also export `system.build.setEnvironment` to `/etc/set-environment` making it
easy to reset the common environment with `. /etc/set-environment` when
needed and to grep for environment variables in `/etc` (which was the
motivation of #30418).
This reverts changes made in b00a3fc6fd
(the original #30418).
- default coreutils is stripped of /share/ (11 -> 2 MiB)
- coreutils-full retains /share/ and adds openssl for faster *sum tools
- NixOS systemPackages contains coreutils-full
- *Support parameter defaults are moved inside
(it seemed confusing to have `? false` and "at once" with `? isLinux`)
Closure considerations:
+ typical build-time closure will get lighter by ~9 MiB
- typical closure of NixOS installation will grow by ~2 MiB,
due to referring to both versions. I think it would be possible to
re-use most of the utils between the two versions, but the expression
would get much more complex.
I considered having stdenv with minimal coreutils and the default
`coreutils` attribute being full, but it turned out there were too many
trivial references in nixpkgs, so it didn't seem easy to keep rebuild
impact of openssl from growing significantly.
Forcibly restarting NSCD is unnecessary and breaks setups that use SSSD for
authentication. NSCD is capable of detecting changes to /etc/resolv.conf and
invalidating its caches internally. Restarting NSCD/SSSD breaks user name and
UID resolution.
The usage of nixpkgs.config.packageOverrides is deprecated and we do
have overlays since quite a while.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra
When doing source routing/multihoming, it's practical to give names to routing
tables. The absence of the rt_table file in /etc make this impossible.
This patch recreates these files on rebuild so that they can be modified
by the user see NixOS#38638.
iproute2 is modified to look into config.networking.iproute2.confDir instead of
/etc/iproute2.
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
With #36556, a check was introduced to make sure the user and group
names do not exceed their respective maximum length. This is in part
because systemd also enforces that length, but only at runtime.
So in general it's a good idea to catch as much as we can during
evaluation time, however the maximum length of the group name was set to
16 characters according groupadd(8).
The maximum length of the group names however is a compile-time option
and even systemd allows more than 16 characters. In the mentioned pull
request (#36556) there was already a report that this has broken
evaluation for people out there.
I have also checked what other distributions are doing and they set the
length to either 31 characters or 32 characters, the latter being more
common.
Unfortunately there is a difference between the maximum length enforced
by the shadow package and systemd, both for user name lengths and group
name lengths. However, systemd enforces both length to have a maximum of
31 characters and I'm not sure if this is intended or just a off-by-one
error in systemd.
Nevertheless, I choose 32 characters simply to bring it in par with the
maximum user name length.
For the NixOS assertion however, I use a maximum length of 31 to make
sure that nobody accidentally creates services that contain group names
that systemd considers invalid because of a length of 32 characters.
Signed-off-by: aszlig <aszlig@nix.build>
Closes: #38548
Cc: @vcunat, @fpletz, @qknight
Currently broken on NixOS due to hardcoded modprobe binary path (see
bug #30756 from Oct 2017), no activity on a proposed fix for months.
As the protocol is terribly broken anyways, let's better remove it
completely, and not talk about anymore ;-)
Closes#30756.
Resolved the following conflicts (by carefully applying patches from the both
branches since the fork point):
pkgs/development/libraries/epoxy/default.nix
pkgs/development/libraries/gtk+/3.x.nix
pkgs/development/python-modules/asgiref/default.nix
pkgs/development/python-modules/daphne/default.nix
pkgs/os-specific/linux/systemd/default.nix
`nixos-generate-config` detects the `cpuFreqGovernor` suited best for my
machine, e.g. `powerManagement.cpuFreqGovernor = lib.mkDefault "powersave";`.
However the `powerManagement` module sets a sensitive default for
`cpuFreqGovernor` using `mkDefault` to avoid breackage with older
setups. Since 140ac2f1 the `hardware-configuration.nix` sets the
gorvernor with `mkDefault` as well which causes evaluation errors if the
powermanagement module is enabled:
```
error: The unique option `powerManagement.cpuFreqGovernor' is defined multiple times, in `/home/ma27/Projects/nixos-config/hardware-configuration.nix' and `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/config/power-management.nix'.
```
Using `mkOptionDefault` rather than `mkDefault` in the powermanagement
module fixes this issue as it decreases the priority of the module and
prefers the value set in `hardware-configuration.nix`.
I have confirmed the change using the following VM declaration:
```
{
cpuFreq = { lib, ... }: {
powerManagement.cpuFreqGovernor = lib.mkDefault "powersave";
powerManagement.enable = true;
};
}
```
- /var/run -> /run as the former is deprecated
- configure openal to use pulseaudio if pulseaudio is enabled
- configure libao to use pulseaudio if pulseaudio is enabled
Commit 987aac7 and issue #18183 were intended to fix support for other
things, but in the process, changed mdns_minimal to use the wrong return
setting, resulting in permanent failures in early boot, affecting things
like issue #30459.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This reverts commit 670b4e29adc16e0a29aa5b4c126703dcca56aeb6. The change
added in this commit was controversial when it was originally suggested
in https://github.com/NixOS/nixpkgs/pull/29205. Then that PR was closed
and a new one opened, https://github.com/NixOS/nixpkgs/pull/29503,
effectively circumventing the review process. I don't agree with this
modification. Adding an option 'resolveLocalQueries' to tell the locally
running name server that it should resolve local DNS queries feels
outright nuts. I agree that the current state is unsatisfactory and that
it should be improved, but this is not the right way.
(cherry picked from commit 23a021d12e8f939cd0bfddb1c7adeb125028c1e3)
When the user specifies the networking.nameservers setting in the
configuration file, it must take precedence over automatically
derived settings.
The culprit was services.bind that made the resolver set to
127.0.0.1 and ignore the nameserver setting.
This patch adds a flag to services.bind to override the nameserver
to localhost. It defaults to true. Setting this to false prevents the
service.bind and dnsmasq.resolveLocalQueries settings from
overriding the users' settings.
Also, when the user specifies a domain to search, it must be set in
the resolver configuration, even if the user does not specify any
nameservers.
(cherry picked from commit 670b4e29adc16e0a29aa5b4c126703dcca56aeb6)
This commit was accidentally merged to 17.09 but was intended for
master. This is the cherry-pick to master.
In order for DynamicUser = true to work in services, we need the
nss-systemd module to be able to resolve the user and group names
generated dynamically.
Evaluation error introduced in a0d464033c.
If the value for timeZone is null it shouldn't be even tried to coerce
it into a string.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @lheckemann, @joachifm
Creating and then erasing the key relies on the disk erasing data
correctly, and otherwise allows attackers to simply decrypt swap just
using "secretkey". We don't actually need a LUKS header, so we can save
ourselves some pointless disk writes and identifiability.
In addition, I wouldn't have made the awful mistake of backing up my swap partition's LUKS header instead of my zpool's. May my data rest in peace.
