now nix-doc-munge will not introduce whitespace changes when it replaces
manpage references with the MD equivalent.
no change to the manpage, changes to the HTML manual are whitespace only.
make (almost) all links appear on only a single line, with no
unnecessary whitespace, using double quotes for attributes. this lets us
automatically convert them to markdown easily.
the few remaining links are extremely long link in a gnome module, we'll
come back to those at a later date.
we can't embed syntactic annotations of this kind in markdown code
blocks without yet another extension. replaceable is rare enough to make
this not much worth it, so we'll go with «thing» instead. the module
system already uses this format for its placeholder names in attrsOf
paths.
markdown can't represent the difference without another extension and
both the html manual and the manpage render them the same, so keeping the
distinction is not very useful on its own. with the distinction removed
we can automatically convert many options that use <code> tags to markdown.
the manpage remains unchanged, html manual does not render
differently (but class names on code tags do change from "code" to "literal").
the conversion procedure is simple:
- find all things that look like options, ie calls to either `mkOption`
or `lib.mkOption` that take an attrset. remember the attrset as the
option
- for all options, find a `description` attribute who's value is not a
call to `mdDoc` or `lib.mdDoc`
- textually convert the entire value of the attribute to MD with a few
simple regexes (the set from mdize-module.sh)
- if the change produced a change in the manual output, discard
- if the change kept the manual unchanged, add some text to the
description to make sure we've actually found an option. if the
manual changes this time, keep the converted description
this procedure converts 80% of nixos options to markdown. around 2000
options remain to be inspected, but most of those fail the "does not
change the manual output check": currently the MD conversion process
does not faithfully convert docbook tags like <code> and <package>, so
any option using such tags will not be converted at all.
The suspend-then-hibernate functionality is implemented by systemd in
the suspend-then-hibernate.target, separately from suspend.target and
hibernate.target. Thus post-resume would not run after resuming from
suspend-then-hibernate.
Fix this by explicitly making post-resume run after
suspend-then-hibernate.
It was never meant to be used for anything other than testing
and setting it globally can cause weird loops in GTK-based portals,
where the portal will end up waiting for itself until it times out.
https://github.com/NixOS/nixpkgs/issues/135898
Or it can mess up fonts:
https://github.com/NixOS/nixpkgs/issues/155291#issuecomment-1166199585
Having the option in NixOS makes it look like it is okay or even
desirable to enable, when in fact it is a hack that can subtly break apps.
Some apps allow opting into using portal-based APIs, e.g. for Firefox,
you can set `widget.use-xdg-desktop-portal.file-picker` to `1` in about:config.
Otherwise, you can set the `GTK_USE_PORTAL` environment variable to 1
for individual apps.
People who really want it and aware of the downsides can just set
`environment.sessionVariables.GTK_USE_PORTAL = "1";` NixOS option
directly to set the environment variable globally.
More nixpkgs code such as `boot.initrd.systemd.emergencyAccess` defines
options that takes hashed passwords, so move the type definition from
modules/ into lib/.
The type definition itself stays unchanged.
`console.{font,keyMap}` may be a path or a string to a store path,
which should be added to initrd for `systemd-vconsole-setup` before
the prompt for the LUKS password.
For systems without internet connections, it doesn't make sense to
require the existence of an /etc/resolv.conf file to disable
resolvconf, so let's expose networking.resolveconf.enable as a public
option that can be set to false.
Previously we allocated subuids automatically for all normal users.
Make this explicitly configurable, so that one can use this for system
users too (or explicitly disable for normal users). Also don't allocate
automatically by default if a user already has ranges specified statically.
Just setting the XKB_CONFIG_ROOT should be enough, so we don't need to
rebuild the xserver, xkbcomp and other packages anymore.
However, the variable has to be passed explicitely to scripts running at
build time: in particular to xkbvalidate and xkb-console-keymap.
Recommend to use services.xserver.dpi option instead. Mention in the
documentation that it's a sledgehammer approach and monitor settings should be
used instead.
Also don't set DPI in fontconfig settings; fontconfig should use Xft settings
by default so let's not override one value in multiple places. For example,
user now can set DPI via ~/.Xresources properly.
Most desktop environments manage the cursor using the Xcursor library
by default; this comes with scalable or multiple-sized cursor themes.
However, when running just a simple WM (twm, bspwm, ...) the cursor
handling is left to the X server, which uses a very simple fixed bitmap
font (this is called a "core" cursor). The font is uncomfortably small
on a high DPI display and must be replaced with a saner default.
Up until recently[1] it used to be possible to change the font on the
xserver command line, however the font name is now hardcoded. It's still
possible to change it, though: here I override the `fontcursormisc`
package and set an alias that points to a vector variant of the original
cursor font. The font size is set to match the standard cursor
dimensions on a 96dpi display. It's not perfect but it's a very simple
and effective solution.
[1]: 56ea4c769c
This change makes it so that accessing config.users.groups.*.members isn't
empty by default, but instead contains all the users whose `extraGroups`
includes that group, allowing fancy things like
{ config, ... }: {
users.groups.libvirt.members = config.users.groups.wheel.members;
}
to add all users in the wheel group to the libvirt group
- The order of NSS (host) modules has been brought in line with upstream
recommendations:
- The `myhostname` module is placed before the `resolve` (optional) and `dns`
entries, but after `file` (to allow overriding via `/etc/hosts` /
`networking.extraHosts`, and prevent ISPs with catchall-DNS resolvers from
hijacking `.localhost` domains)
- The `mymachines` module, which provides hostname resolution for local
containers (registered with `systemd-machined`) is placed to the front, to
make sure its mappings are preferred over other resolvers.
- If systemd-networkd is enabled, the `resolve` module is placed before
`files` and `myhostname`, as it provides the same logic internally, with
caching.
- The `mdns(_minimal)` module has been updated to the new priorities.
If you use your own NSS host modules, make sure to update your priorities
according to these rules:
- NSS modules which should be queried before `resolved` DNS resolution should
use mkBefore.
- NSS modules which should be queried after `resolved`, `files` and
`myhostname`, but before `dns` should use the default priority
- NSS modules which should come after `dns` should use mkAfter.
The attributes got renamed in PR #126440 and in some places this caused
evaluation errors, e.g. the tarball job was saying (locally)
> attribute 'alsaUtils' missing, at /build/source/nixos/modules/services/audio/alsa.nix:6:4
and I suspect that trunk-combined jobset's failure to evaluate was also caused.
Things will get quite broken if an /etc/passwd entry contains a
colon (which terminates a field), or a newline (which terminates a
record). I know because I just accidentally made a user whose home
directory path contained a newline!
So let's make sure that can't happen.
As the only consequence of isSystemUser is that if the uid is null then
it's allocated below 500, if a user has uid = something below 500 then
we don't require isSystemUser to be set.
Motivation: https://github.com/NixOS/nixpkgs/issues/112647
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
This cropped up, because I have a set-up where my work username is
different to my home desktop username, and I am using a parameterized
config for both, so I have something akin to
config.users.users.default-user = ...;
and using
config.users.users.default-user.{name, home}
in certain places to cope with this. Noticed my home-manager bought in
packages (which use the users.users.<name>.packages hence NixOS issue
not home-manager) weren't present.
It's a dull and boring day, it's cold outside and I'm stuck at home: let
me tell you the story of systemd-vconsole-setup.
In the beginnings of NixOS[1], systemd-vconsole-setup was a powerful
sysinit.target unit, installed and running at boot to set up fonts
keyboard layouts and even colors of the virtual consoles. If needed, the
service would also be restarted after a configuration change, consoles
were happy and everything was good, well, almost.
Since the service had no way to specify the dependency "ttys are ready",
modesetting could sometimes happen *after* systemd-vconsole-setup had
started, leaving the console in a broken state. So abbradar worked
around that by putting a systemd-udev-settle `After=`.
In the meanwhile, probably realizing their mistake, systemd added a
shiny udev rule to start the systemd-udev-settle at the right time[2].
However, the rule bypassed systemd by directly running the binary
`systemd-udev-settle`, and the service - though still installed - fell
into disuse.
Two years would pass before a good samaritan, seeing the poor jobless
systemd-udev-settle service, decided to give it the coup de grâs[3] by
unlisting it from the installed units.
This, combined with another bug, caused quite a commotion[4] in NixOS;
to see why remember the fact that `WantedBy=` in upstream units doesn't
work[5], so it had to be added manually in cc542110, but while systemd
removed it, the NixOS unit continued to install and restart the service,
making a lot of fuss when switching configuration.
After at least thee different tentative fixes, deedrah realised[6] what
the root cause was and fpletz put the final nail[7] in the coffin of
systemd-udev-settle. The service would never see the light of a boot
again, NixOS would not restart it all the time but thanks to udev
consoles would still get their pretty fonts and playful colors.
The En..
..no, wait! You should ask what came of systemd-udev-settle, first.
And why is the service even around if udev is doing all the work?
Udev-settle, like the deceitful snake that he is, laid hidden for years.
He looks innocuous doesn't it? A little hack. Only until it leaves his
den and a poor user[8] drops dead. Obviously, it serves no purpose, as
the service is not part of the boot process anymore, so let's remove it
for good!
About the service, it may not be useful at boot, but it can be started
to pick up changes in vconsole.conf and set the consoles accordingly.
But wait, this doesn't work anymore: the service is never started at
boot (remember f76d2aa6), so switch-to-configuration.pl will not restart
it. Fortunately it can be repaired: here I install a new unit which
does *nothing* on start, but restarts the real service when reloaded.
This perfectly reproduces the original behavior, hopefully without the
original bugs too.
The End?
[1]: cc54211069
[2]: f6ba8671d8 (diff-84849fddcef81458f69725dc18c6614aade5c4f41a032b6908ebcf1ee6740636)
[3]: 8125e8d38e
[4]: https://web.archive.org/web/20180603130107/https://github.com/NixOS/nixpkgs/issues/22470
[5]: https://github.com/NixOS/nixpkgs/issues/81138
[6]: https://web.archive.org/web/20180603130107/https://github.com/NixOS/nixpkgs/issues/22470#issuecomment-330930456
[7]: f76d2aa6e3
[8]: https://github.com/NixOS/nixpkgs/issues/107341
configuration.nix(1) states
users.extraUsers.<name>.createHome
[...] If [...] the home directory already exists but is not
owned by the user, directory owner and group will be changed to
match the user.
i.e. ownership would change only if the user mismatched; the code
however ignores the owner, it is sufficient to enable `createHome`:
if ($u->{createHome}) {
make_path($u->{home}, { mode => 0700 }) if ! -e $u->{home};
chown $u->{uid}, $u->{gid}, $u->{home};
}
Furthermore, permissions are ignored on already existing directories and
therefore may allow others to read private data eventually.
Given that createHome already acts as switch to not only create but
effectively own the home directory, manage permissions in the same
manner to ensure the intended default and cover all primary attributes.
Avoid yet another configuration option to have administrators make a
clear and simple choice between securely managing home directories
and optionally defering management to own code (taking care of custom
location, ownership, mode, extended attributes, etc.).
While here, simplify and thereby fix misleading documentation.
Only set Before=display-manager.service if it is actually present.
On headless systems, `systemctl list-units --state not-found` will
otherwise show display-manager.service.
Reported-In: https://github.com/NixOS/nixpkgs/issues/88597
This allows capping the total amount of memory that will be used for
zram-swap, in addition to the percentage-based calculation, which is
useful when blanket-applying a configuration to many machines.
This is based off the strategy used by Fedora for their rollout of
zram-swap-by-default in Fedora 33
(https://fedoraproject.org/wiki/Changes/SwapOnZRAM), which caps the
maximum amount of memory used for zram at 4GiB.
In future it might be good to port this to the systemd zram-generator,
instead of using this separate infrastructure.
