nixos/dokuwiki: Don't force http with Caddy

[lluchs]

Description of changes

Caddy usually expects just a hostname without scheme to do its automatic HTTPS. The dokuwiki plugin always adds http:// to the hostname, which is surprising and probably not what most users want. It is possible to get the old behavior (only HTTP) by setting services.caddy.virtualHosts.<host>.hostName.

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/)
• 24.11 Release Notes (or backporting 23.11 and 24.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.

[onny]

this really makes sense to me. would it be possible to somehow deprecate the old behaviour and add a warning while upgrading? so that we won't break the behaviour with the next release and add a deprecation warning

[FliegendeWurst]

Maybe mention it in the release notes for 25.05

[lluchs]

I rebased the commit now and added an entry to the release notes.

[onny]

Somehow NixOS tests with Caddy fail on master, also nixosTests.dokuwiki.

Here's my fix #371205

Probably we'll have to do this for Dokuwiki module too?

[lluchs]

The test is failing because of invalid default logging configuration from the caddy module:

vm-test-run-dokuwiki> dokuwiki_caddy # [   18.521644] caddy[936]: {"level":"info","ts":1736252076.087641,"msg":"using config from file","file":"/etc/caddy/caddy_config"}
vm-test-run-dokuwiki> dokuwiki_caddy # [   18.538640] caddy[936]: {"level":"info","ts":1736252076.1057036,"msg":"adapted config to JSON","adapter":"caddyfile"}
vm-test-run-dokuwiki> dokuwiki_caddy # [   18.546695] caddy[936]: Error: loading initial config: loading new config: setting up custom log 'log0': opening log writer using &logging.FileWriter{Filename:"/var/log/caddy/access-http://site1.local.log", Mode:0
x0, Roll:(*bool)(nil), RollSizeMB:0, RollCompress:(*bool)(nil), RollLocalTime:false, RollKeep:0, RollKeepDays:0}: open /var/log/caddy/access-http://site1.local.log: no such file or directory
vm-test-run-dokuwiki> dokuwiki_caddy # [   18.561471] systemd[1]: caddy.service: Main process exited, code=exited, status=1/FAILURE

I bisected the test failure and found 7c52e7a as the first bad commit. Looks like previous caddy versions ignored errors while opening the log file. I think this should be fixed in the caddy module so that it does not generate invalid configuration.

[stepbrobd]

Seems like an upstream regression caddyserver/caddy#6766