I mean, it’s like a fucking drug. The learning curve is steep AF but past some point, when it starts making sense, it’s just incredible. I’m currently moving my whole setup to NixOS and I’m in love.
Even when using in a basic way, I think it has one very tangible advantage: the fact that you can “compartmentalize” different aspects of your configuration.
Let’s say I set up a specific web service that I want to put behind a reverse proxy, and it uses a specific folder that doesn’t exist yet, like Navidrome which is a web-based audio player. It requires a set of adjustments of different system parts. My nix file for it looks like this:
All settings related to the service are contained in a single file. Don’t want it anymore? Comment it out from my main configuration (or whereever it’s imported from) and most traces of it are gone, the exception being the folder that was created using systemd.tmpfiles. No manually deleting the link from sites-available or editing the list of domains for my certificate. The next generation will look like the service never existed.
And in my configuration, at least the port could be changed and everything would still work – I guess there is room for improvement, but this does what I want pretty well.
Hey this is a great web server example! Instead of commenting it out to enable or disable you can actually turn it into a full module. Check out this example of a nix module. Basically, you can take your code you pasted and put it under the config set. Then create an option to enable that set of code. Now you can always have this nix file imported, but enable the option only when you need it with another declaration. Really, that’s how all the declarations work you’re just getting the nix files from github and nixpkgs.
Thanks for the answer; I do have at least one module in my config, but usually, I don’t enable or disable services like that, it was more of an example of how the configuration is split up and what the advantage of that is. In the end, if the only option is to enable the module, you’re not gaining that much if you need to import and enable it instead of just importing the configuration straight is my opinion.
Technically correct, but the settings in there are not service specific. However, if there’s something worthy of reworking it’s probably the Authelia part
I mean, it’s like a fucking drug. The learning curve is steep AF but past some point, when it starts making sense, it’s just incredible. I’m currently moving my whole setup to NixOS and I’m in love.
Even when using in a basic way, I think it has one very tangible advantage: the fact that you can “compartmentalize” different aspects of your configuration.
Let’s say I set up a specific web service that I want to put behind a reverse proxy, and it uses a specific folder that doesn’t exist yet, like Navidrome which is a web-based audio player. It requires a set of adjustments of different system parts. My nix file for it looks like this:
{ config, ... }: let domain = "music." + toString config.networking.domain; in { services.navidrome = { enable = true; settings = { Address = "127.0.0.1"; Port = 4533; MusicFolder = "/srv/music"; BaseUrl = "https://" + domain; EnableSharing = true; Prometheus.Enabled = true; LogLevel = "debug"; ReverseProxyWhitelist = "127.0.0.1/32"; }; }; services.nginx = { upstreams = { navidrome = { servers = { "127.0.0.1:${toString config.services.navidrome.settings.Port}" = {}; }; }; }; }; services.nginx.virtualHosts."${domain}" = { onlySSL = true; useACMEHost = config.networking.domain; extraConfig = '' include ${./authelia/server.conf}; ''; locations."/" = { proxyPass = "http://navidrome"; recommendedProxySettings = false; extraConfig = '' include ${./authelia/proxy.conf}; include ${./authelia/location.conf}; ''; }; }; systemd.tmpfiles.settings."navidrome-music-dir"."${toString config.services.navidrome.settings.MusicFolder}" = { d = { user = "laser"; mode = "0755"; }; }; systemd.services.navidrome.serviceConfig.BindReadOnlyPaths = ["/run/systemd/resolve/stub-resolv.conf"]; security.acme.certs."${config.networking.domain}".extraDomainNames = [ "${domain}" ]; }All settings related to the service are contained in a single file. Don’t want it anymore? Comment it out from my main configuration (or whereever it’s imported from) and most traces of it are gone, the exception being the folder that was created using
systemd.tmpfiles. No manually deleting the link from sites-available or editing the list of domains for my certificate. The next generation will look like the service never existed.And in my configuration, at least the port could be changed and everything would still work – I guess there is room for improvement, but this does what I want pretty well.
Hey this is a great web server example! Instead of commenting it out to enable or disable you can actually turn it into a full module. Check out this example of a nix module. Basically, you can take your code you pasted and put it under the config set. Then create an option to enable that set of code. Now you can always have this nix file imported, but enable the option only when you need it with another declaration. Really, that’s how all the declarations work you’re just getting the nix files from github and nixpkgs.
Thanks for the answer; I do have at least one module in my config, but usually, I don’t enable or disable services like that, it was more of an example of how the configuration is split up and what the advantage of that is. In the end, if the only option is to enable the module, you’re not gaining that much if you need to import and enable it instead of just importing the configuration straight is my opinion.
They’re not in a single file though, you got includes
Technically correct, but the settings in there are not service specific. However, if there’s something worthy of reworking it’s probably the Authelia part