nixos/archtika: init at 1.0.1

[thiloho]

This PR adds the archtika package and its NixOS module.

archtika is a modern Content Management System (CMS) designed for the creation and management of documentation and blog websites. It focuses on simplicity, performance and maintainability, while providing essential features for content creators, such as:

• Easy website creation with predefined templates
• Markdown support with live preview
• Collaboration features
• Storage management
• Change tracking
• Automatic static site generation

Homepage: https://archtika.com
Repository: https://github.com/archtika/archtika

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[thiloho]

Some improvements can be made, such as avoiding the with expressions (https://nix.dev/guides/best-practices#with-scopes), possibly using recursiveUpdate (https://nix.dev/guides/best-practices#updating-nested-attribute-sets) and other nitpicks.

I will look into this.

[SigmaSquadron]

It's always great to see someone's first contribution is a massive NixOS module. Great work on this!

The following commits should be squashed:

• archtika: fix allow-import-from-derivation error for npm ➜ archtika: init at 1.0.1
• nixos/manual: add archtika module to 25.05 release notes ➜ nixos/archtika: init module
• archtika: fix formatting, add module description, remove trailing whitespace and archtika: refactor package and module definitions ➜ Both the package and module commit, as appropriate.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/2167

[thiloho]

Hi @Lassulus , seeing that you recently merged another pull request (#365006), could you please check this one? As far as I can see it should be ready.

[thiloho]

I have also tested all the functionality again using the given steps and using a local setup in the repository, see https://github.com/archtika/archtika/blob/main/nix/module.nix

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/2188

[sarahec]

I think what @SigmaSquadron was suggesting is that you pull all the pieces into individual derivations as /pkgs/by-name/ar/archtika/{package,service,api,webapp}.nix then import them into package.nix with let web-app = callPackage ./webapp.nix {}. (You can override or add parameters to the call as needed.)

As you approach the finish line, there's some git cleanup to do:

1. Merging master pulled in some extraneous information (did you mean to add two names to maintainers?). So let me walk you through the nixpkgs way (from CONTRIBUTING.md):

git checkout archtika-pkg
# Back out the merge
git reset --hard HEAD~1
# Rebase onto master, nixpkgs-style
git checkout master
git fetch upstream master
git checkout archtika-pkg
git rebase master
# Fix any merge conflicts before pushing
git push --force-with-lease

2. The maintainers list update should only contain your entry. I think you picked up someone else's in merging master. Step 1 should have fixed that.

[thiloho]

Thanks, yes, I can remove the last merge commit by force pushing, I just did that on GitHub to fix a merge conflict.

As for the individual derivations suggested earlier, there could be two other files, web-app.nix and api.nix, which would then be used via callPackage, but I doubt that it is really necessary to split those very few lines in the one package file.

I just wanted to mention this PR on Matrix again, as nothing has happened here for two weeks since I made the post in the already reviewed Discourse thread. And I think this should be ready to be merged.

[sarahec]

Reviews seem to be taking longer than usual lately. The automation we usually see doesn't seem to be working and that may be increasing reviewers' workload.

Since you're on Discourse, try pinging Sandro with a PM.

[SuperSandro2000]

Since this must match the username connecting via the Unix socket this is not really configurable in most modules anymore and most likely requires an assertion

[thiloho]

I am not sure why the databaseName should not be configurable, could you give an example here?

[SuperSandro2000]

see the description of https://search.nixos.org/options?channel=unstable&show=services.postgresql.ensureUsers.*.ensureDBOwnership&from=0&size=50&sort=relevance&type=packages&query=services.postgresql.ens and the other ensure options.

[thiloho]

So I looked again, and this should not be necessary for my module.

The default value for PostgreSQL's Unix socket auth-method is peer, which requires the system username to match the database username. In my module, however, the local auth-method is set to trust, which is not as secure, but should still be fine for local auth. See below for why this is necessary:

Since Unix sockets are now used, I was able to remove two of the lines.

This one is still needed though, because the default value of peer that PostgreSQL uses for auth-method would prevent the authenticator user (which does not exist as a system user) from connecting, which PostgREST needs:

The authenticator role is used to connect to the database and should be configured to have very limited access. It is a chameleon whose job is to "become" other users in order to serve authenticated HTTP requests.

authentication = pkgs.lib.mkOverride 11 ''
  #type database  DBuser  auth-method
  local all       all     trust
'';

The database migration is run as the regular postgres user, and the PostgREST API then uses the authenticator role, which is required (see docs: https://docs.postgrest.org/en/v12/references/auth.html).

So most of this is in line with the PostgREST recommendations, which require this module setup.

What I think is a bit less ideal is that I enable this setting for all databases, I could adjust the rules so that this is only enforced for the database that archtika is using, something like this:

authentication = pkgs.lib.mkOverride 11 ''
  #type database  DBuser  auth-method
  local ${cfg.databaseName}       all     trust
'';

This way, any other modules someone may have enabled on their server will still default to their preferred settings, and this is only enforced for the archtika module because it is necessary. I would make this last change if you agree.

[thiloho]

I have now made the suggested change, which only affects what it should.

authentication = lib.mkOverride 11 ''
  local postgres postgres trust
  local ${cfg.databaseName} all trust
'';