nixos: Decide and document scope of configuration

[cyounkins]

To what degree should configuration be handled in nix?

We have a number of related issues:

• Purity in /etc (#3192 #22005)
• Only a subset of options are exposed in nixpkgs (Compare https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/networking/ssh/sshd.nix and https://linux.die.net/man/5/sshd_config), many GitHub issues created for exposing options (#30475 #33282)
• Unclear handling of defaults in options (https://github.com/NixOS/nixpkgs/pull/50849#pullrequestreview-176969593)
• Configurations can depend on /nix/store paths (eg systemd unit path to binary, lighthttpd config wants path to perl)

Some questions:

• Should we describe configuration options in nixpkgs? All or a subset?
• Do we generate configuration in Nix then write it out, or attempt to patch a copied config?
• Can we reasonably make /etc readonly?
• What parts of a system should be mutable? Users? Services? Containers? Passwords? Network?

Some opinions:

• Mirroring upstream configuration options is too much maintenance burden, too hard to get right
• Allow arbitrary configuration options, validating/type checking where possible
• Implicitly use upstream defaults
• Services should "do the right thing" by default. Log to systemd journal, put mutable state in correct directories.
• It should be hard to get into a broken configuration (like bad network config), but it should be easy to get out of one.

Please post your thoughts and ideas!

Edit: Removed questions of bootstrapping

[endgame]

I know it's a mountain of effort, but what I really want to do is write configuration.nix, and have it configure everything system-level on that machine. Readonly /etc would be fantastic. Hardcoded store paths do not bother me. Not having to learn the configuration syntax for each and every thing is surprisingly nice.

That said, a useful meta-option might be to just override entire config files, for when you can't do something through nixpkgs yet, but you need to do it Right Now.

I wonder: how much work would it be to start automating the generation of options from specifications (like we do with haskell packages, and probably other packaging systems too).

It's not obvious to me whether a hypothetical bootstrap env should use old or new config. I can imagine situations where either makes sense, depending on the order of applying changes. This doesn't have a straightforward solution that i can see.

[danbst]

@endgame

I wonder: how much work would it be to start automating the generation of options from specifications (like we do with haskell packages, and probably other packaging systems too).

probably best example of what happens when NixOS module options are generated is nixsap.

For example, postgresql options were translated to NixOS: https://github.com/zalora/nixsap/blob/master/modules/apps/postgresql/server.nix

Does it look like what you've imagined?

[endgame]

It looks like a pretty cool project, but where are the options coming from? Is there a manifest somewhere in that repo which is used to generate that .../postgresql/server.nix you mentioned? (If so, then yes that's the sort of thing I was thinking about.)

I'm okay with things like .extraConfig options to append arbitrary text to a config file. While it's not ideal it does at least make config files a pure function of the nixos config.

[danbst]

Looks like I lied and these options are not autogenerated. cc @ip1981 on the generation method.

I'm okay with things like .extraConfig options to append arbitrary text to a config file

It doesn't work in some scenarios.

1. nginx. One can't simply override/extend existing virtual host by appending stuff to config. That's why we have a tree of configuration options for it in NixOS. For most nested stuff dumb .extraConfig doesn't work.

Another example is with postgres:

    services.postgresql.extraConfig = ''
        listen_addresses = '127.0.0.1'
        listen_addresses = '127.0.0.2'
    '';

The latter line will override former, but I wanted merge behavior.

2. In some (rare) cases, it is forbidden to duplicate config entries, so even override behavior is absent

So, depending on config parsing of a specific service, we have to choose different strategies of option naming. .extraConfig is somtimes not sufficient.

[endgame]

Agreed that it doesn't solve every problem, and that having well-structured options is superior, but it does give you an escape hatch in a number of situations.

[danbst]

@cyounkins

Configurations can depend on /nix/store paths (eg systemd unit path to binary, lighthttpd config wants path to perl

There is nothing bad here, right?

Should we describe configuration options in nixpkgs? All or a subset?

My rules of thumb:

• if you want this configuration option to be discoverable by NixOS newcomers, expose it as NixOS option and write good documentation on how can it helps life
• if it is impossible to define in .extraConfig style, but it is of great importance, expose as an option
• otherwise provide .configFile and .extraConfig
• one more desire is to expose functions used to generate config. So that it would be possible to do https://github.com/NixOS/nixpkgs/pull/22209 entirely in configuration.nix. As of now it is extremely hard to do such overrides, have to fork module.

Do we generate configuration in Nix then write it out, or attempt to patch a copied config?

Generate. Patching isn't much composable (but there can be hacks like

configPatch = mkOption {
  type = types.str; # note, not type.lines, but str, which forbids any merges
  example = ''
    sed 's/xxx/yyy/g' "$1"
  '';
  description = "run this patch over default configuration";
};

)

[ip1981]

Nixsap guy here. First of all, current events happen here => https://github.com/ip1981/nixsap

Primary idea of its configuration options: make nix stuff transparent as much as possible, so users would not need to learn new language, and whatnot. Ideally, an application (service) should accept a configuration file or files as it were set up manually. Often it is not possible on NixOS, because we need some introspection, e. g. to get and create a data directory, open a TCP port. In such cases parameters (options) are preferred. In any case it is really desired to have exactly one source of truth, either not allowing to use raw configuration snippets, or make sure they are overridden by explicit parameters. The point is that users or administrators could not damage the system unless explicitly allowed. For this, some "upstream" configuration options does not make sense at all, and not added. There are some other things related to Nix and NixOS which make "upstream" features irrelevant. For example PHP-FPM supports pools out of desperation, but with Nix we can create as many PHP-FPM instances as we need with proper privilege separation, logs, etc. So PHP-FPM pools aren't supported in Nixsap, instead you create instances, each with only one pool.

All options like in PostgreSQL or MariaDB Server are added manually after carefully reading of their documentation.

[danbst]

Related https://github.com/NixOS/rfcs/pull/42. Some comments discuss topics from OP-post

[infinisil]

Thanks for pointing this out @danbst, the RFC is very relevant to this issue, it addresses multiple concerns mentioned here.

A structural config option should remove the need for stringly-typed extraConfig options. A structural version allows merging of multiple assigments correctly, introspection into its value, a flexible assignment of defaults and not needing hardcoded defaults. It also makes sure all upstream settings can be assigned, without having to maintain all of them in NixOS.

And with such an option, it then makes a lot of sense to limit the amount of additional NixOS options for specific settings to the ones that most people will be using, therefore decreasing the maintenance burden and module size.

I am currently in the process of rewriting a big part of the RFC in order to address the comments on it.

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[cyounkins]

This is still important and I don't think it's really been resolved.

[stale[bot]]

I marked this as stale due to inactivity. → More info

[davidak]

This is still important.

[stale[bot]]

I marked this as stale due to inactivity. → More info

[buckley310]

rm stale

[dark-ether]

in my opinion having all configuration accessible through nix should be our goal. however that seems like a massive undertaking and even worse partial configuration through nix and normal configuration is probably inferior to configuring only through the normal method. so we probably should mark the ones we want "nixfied" and then create a module when enough interest arises