Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos/sks: Add option to configure database settings #54726

merged 1 commit into from Jan 28, 2019


Copy link

@etu etu commented Jan 27, 2019

Motivation for this change

This can be used for options to tweak the behavior around the database.

For example, I've set up the sks-server on my VPS, 3 weeks later it ran out of disk. Even though it didn't even talk to another server and had just like 3 keys uploaded.

And that was quite annoying but could be solved by adding:


To the DB_CONFIG files, then it stopped eating ~20MiB disk per day while idle.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Assured whether relevant documentation is up to date
  • Fits

Copy link
Contributor Author

etu commented Jan 27, 2019

@grahamc Updated with a fixup, I can squash it later before merging. Just want to keep history for now.

This can be used for options to tweak the behavior around the database.
@etu etu merged commit 3d6ed83 into NixOS:master Jan 28, 2019
@etu etu deleted the nixos-sks-db-config branch January 28, 2019 13:43
Copy link

primeos commented Apr 27, 2019

FYI: This broke the module due to a typo (see 753e1e0).

Not to blame anyone (these things happen occasionally) but just as a friendly reminder to test things (I'm assuming both files existed during testing due to a previous mistake) and cc the maintainers (the latter can be quite useful, at least if they actually maintain the package/module) :)

Copy link
Contributor Author

etu commented Apr 28, 2019

@primeos Hey, could you make a backport of that to 19.03 to unbreak the module? That would be great. Sorry for that typo. I thought I tested it well locally because I set it up on my local machine etc. But it appears not.

Copy link

primeos commented Apr 28, 2019

@etu Yes, had to wait for today though because I couldn't test it yesterday in a VM (without an existing DB, i.e. with a clean setup).

It's now backported in 47e9779 and 0943e4a (turns out there was a second problem with a clean setup - and I've included the full path in the error message to make it easier to find the file).

It's probably not optimal (the module is a bit hacky in general) but it should work now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging this pull request may close these issues.

None yet

4 participants