• 0 Posts
  • 32 Comments
Joined 2 months ago
cake
Cake day: June 23rd, 2024

help-circle





  • Well, a lot of it is just trying stuff out, but let’s say you want to setup Navidrome because you read about it somewhere. My first step is always to go to https://search.nixos.org/options? and search for it, it’ll show you the options available. If you want to know how it’s implemented under the hood, press the “Declared in” link where it shows you the source code of the module, this can sometimes be helpful.

    Other than that, read the wiki for examples, and remember that nix is a full language and not just a configuration, so you can keep it flexible.


  • 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.


  • Laser@feddit.orgtolinuxmemes@lemmy.worldHave you tried NixOS?
    link
    fedilink
    arrow-up
    14
    arrow-down
    1
    ·
    19 days ago

    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.



  • Laser@feddit.orgtolinuxmemes@lemmy.worldHave you tried NixOS?
    link
    fedilink
    arrow-up
    15
    arrow-down
    1
    ·
    19 days ago

    Just to clarify, I wouldn’t recommend putting everything in a single file, but rather modularize the configuration.

    I also came from Arch, but have since abandoned it, and I don’t think I want to use distributions for myself that use the the classic imperative concept. One you get a better understanding of it, it makes so much more sense.






  • Laser@feddit.orgtoTechnology@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    19 days ago

    we already had XMPP available and well developed.

    XMPP as defined where?

    For privacy, I guess OMEMO is the current gold standard regarding XMPP; however, agreeing on a feature set between clients apart from the most basic stuff wasn’t always easy (and I guess it still isn’t).

    Also, I guess XML has fallen out of style for this kind of use case. Matrix is just JSON over REST, which I guess is kind of nice nowadays?

    XML kind of suffers the jack of all trades curse. If you just have two sides exchanging messages using a well-defined protocol, why go for something that offers schema definition, DTD, XSL transformation? These come with costs, and if you don’t use them, why XML in the first place?

    All of this combined with the fact that the communication model of XMPP and Matrix is different - XMPP closer to email where a server relays messages between clients while in Matrix, everything is a synchronized (?) room, even direct messages between two participants - would have required bending or extending the spec so much that it wouldn’t have been XMPP in the original spirit anyways. So instead, a new protocol was designed that incorporated a lot of lessons learned in the decade before it.

    You’re free to continue using XMPP, after all, bridges exist.