DNSproxy as Quic server scenario

[ser]

Describe the bug

In first look using Dynamic Users is a good choice, but if we look into details, it's getting problematic. For example I want to serve Quic using dnsproxy, so I need an cert and key file to be provided. How can I store these files safely on the system in that scenario to be available for a Dynamic User? :=)

Notify maintainers

@diogotcorreia

---

Add a :+1: reaction to issues you find important.

[diogotcorreia]

I think it should be possible to use systemd credentials to achieve this while keeping the dynamic user. What options do you need for the QUIC server, is it --tls-crt and --tls-key?

I think I can make a new option (I need to test to make sure it is doable) like

services.dnsproxy.secretFlags = {
    tls-crt = "/path/to/cert";
    tls-key = "/path/to/key";
};

[ser]

Yes, these two files are required only. I have no practice with Dynamic Users so I can't really recommend any solution. Thanks :-)

[diogotcorreia]

@ser I'd appreciate if you could test PR #332268 (works on my machine btw, but other input is greatly appreciated)

I've added the secretsFlag option, as per my previous comment.

[ser]

I'm really sorry but I have no chance to build a nixos sandbox at the moment, but I can definitely test it when arrives in nixos unstable.

[diogotcorreia]

@ser Are you using flakes? If so, you should be able to add a new input and import my module directly:

{ inputs }:
{
    disabledModules = ["services/networking/dnsproxy.nix"];
    imports = [
        (inputs.nixpkgs-dnsproxy + "/nixos/modules/services/networking/dnsproxy.nix")
    ];

    services.dnsproxy = {
        // ...
    };
}

If you are not, I think a similar thing can be achieved through channels. As a last resort, you can always copy the module manually and import it from a local file.

Otherwise just wait until it gets merged :)