# 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:
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!
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.
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.
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.
Thanks for all of this information. Reading through documentation gives information on how to do things when everything is working perfectly. It’s a large leap for a newcomer to handle the imperfect case.
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 inputthen, in my system configuration, I add this:
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:
sudo su - postgres
psql -v ON_ERROR_STOP=1 lemmy postgres
SET ROLE lemmy;
After that’s done, you can exit the postgres CLI by typing
\q
, exit the postgres user and just simplysudo 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!
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.
Is this sort of lag the nature of package managers that will inherently be part of NixOS and nixpk?
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.That kinda defeats the purpose of the hash.
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.
Thanks for all of this information. Reading through documentation gives information on how to do things when everything is working perfectly. It’s a large leap for a newcomer to handle the imperfect case.