Anyone with experience using NixOS to create a Lemmy instance, please share any caveats and troubleshooting tips you have.

  • ericjmorey@lemmy.worldOP
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    That PR link returns a 404.

    This is my way of learning Nix/NixOS so I’d rather give it a go before the PR is merged.

        • neoney@lemmy.neoney.dev
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 year ago

          Okay, I’ve actually figured simplifying it out, it’s not that bad. Let me share my config:

          First, since the PR isn’t in nixos-unstable yet, I’m adding the fork as a flake input

          inputs = {
            nixpkgs-lemmy.url = "github:CobaltCause/nixpkgs/lemmy-module-improvements";
          };
          

          then, in my system configuration, I add this:

          # Not sure if this is required, maybe caddy auto-allows it
          networking.firewall.interfaces.eth0.allowedTCPPorts = [443 80];
          
          # Override the lemmy module with the one from the PR
          disabledModules = ["services/web-apps/lemmy.nix"];
          imports = [
            "${inputs.nixpkgs-lemmy}/nixos/modules/services/web-apps/lemmy.nix"
          ];
          
          services.lemmy = {
            database.createLocally = true;
            database.uri = "postgres:///lemmy?host=/run/postgresql&user=lemmy";
            enable = true;
            settings = {
              hostname = "<YOUR_HOSTNAME>";
            };
            caddy.enable = true;
          };
          

          and, that’s it! However, I’m not sure if it will cleanly deploy, as you might get an error while starting. If so, please check postgresql logs sudo journalctl -fu postgresql. The error will most likely be something like this: […] [10289] ERROR: permission denied: "RI_ConstraintTrigger_a_16639" is a system trigger […]

          If that happens, you need to manually run the migration until the fix is merged into Lemmy. Here’s how I did it:

          1. sudo su - postgres
          2. psql -v ON_ERROR_STOP=1 lemmy postgres
          3. (in psql) SET ROLE lemmy;
          4. Paste the SQL code from here: https://github.com/LemmyNet/lemmy/issues/2784#issuecomment-1578337686

          After that’s done, you can exit the postgres CLI by typing \q, exit the postgres user and just simply sudo systemctl restart lemmy which should start properly now, and be accessible to the outside network. Open it and it will give you the initial setup screen. Good luck!

          • neoney@lemmy.neoney.dev
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            Note that the PR got merged into nixpkgs now, but hasn’t made it’s way forward (see https://nixpk.gs/pr-tracker.html?pr=236295), so that’s why you need to do the override for now Also, a fix for the issue with the migrations (if still occuring) has been merged yesterday, but it’s not in any release yet, and especially not in nixpkgs. You could most likely get around it by using overrideAttrs to change the source to make it build from a newer commit.

            • ericjmorey@lemmy.worldOP
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 year ago

              Is this sort of lag the nature of package managers that will inherently be part of NixOS and nixpk?

              • neoney@lemmy.neoney.dev
                link
                fedilink
                English
                arrow-up
                1
                ·
                1 year ago

                While we were talking I updated lemmy-server using overrideAttrs for my own use. It’s honestly not that hard. You change the commit, specify some random incorrect hashes, build it, nix screams at you that the hash is incorrect (and generously provides the correct one), put the correct hash, and build again. Done.

                  • neoney@lemmy.neoney.dev
                    link
                    fedilink
                    English
                    arrow-up
                    2
                    ·
                    edit-2
                    1 year ago

                    The hash isn’t there for security, it’s to make sure the code you’re building against doesn’t randomly change which could make the derivation fail to compile. For example, for the source, you can specify a literal HTTP download from a URL, and that file could be changed by the host at any given time, so it’s there as a safeguard.

              • neoney@lemmy.neoney.dev
                link
                fedilink
                English
                arrow-up
                1
                ·
                1 year ago

                Nixpkgs is by nature fully reproducible and declarative - that means you can’t write a nix package to just build from master branch. You also have to specify the sha256 hash to absolutely make sure the source is the same for everyone.
                With flakes, it’s a bit easier, because if the package you’re trying to build has a flake, you can just update it in your own lockfile and it will be rebuilt from the latest version.
                If using something from nixpkgs, you have to wait (or PR yourself) for someone to PR the update, or you can also use overrideAttrs to do a “private” fix.
                For example, I’m using the wlsunset program, but wanted to build from a different branch, so I did this:

                      (wlsunset.overrideAttrs (old: {
                        src = fetchFromSourcehut {
                          owner = "~kennylevinsen";
                          repo = old.pname;
                          rev = "81cfb0b4f8e44db9e5ecb36222a24d53a953e6aa";
                          sha256 = "sha256-Lxuhsk4/5EHuKPkBbaRtCCQ/LFvIxyc+VQYEoaVT484=";
                        };
                      }))
                

                This just changes the source attribute to another commit and another sha hash, and it works fine.

                • neoney@lemmy.neoney.dev
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  1 year ago

                  In the end, the lag is just caused by the fact that it has to work. You never want to get some broken version that you want to avoid, so nix packages are always tested with the new versions, because it may turn out they may need some patching for that version, or they have some new dependencies.