Open cyounkins opened 5 years ago
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.
@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?
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.
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.
.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.
So, depending on config parsing of a specific service, we have to choose different strategies of option naming. .extraConfig
is somtimes not sufficient.
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.
@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:
.extraConfig
style, but it is of great importance, expose as an option.configFile
and .extraConfig
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";
};
)
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.
Related https://github.com/NixOS/rfcs/pull/42. Some comments discuss topics from OP-post
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.
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:
This is still important and I don't think it's really been resolved.
I marked this as stale due to inactivity. → More info
This is still important.
I marked this as stale due to inactivity. → More info
rm stale
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
To what degree should configuration be handled in nix?
We have a number of related issues:
/nix/store
paths (eg systemd unit path to binary, lighthttpd config wants path to perl)Some questions:
/etc
readonly?Some opinions:
Please post your thoughts and ideas!
Edit: Removed questions of bootstrapping