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

knot-resolver: 4.3.0 -> 5.0.0 -> 5.0.1 #78628

Merged
merged 6 commits into from Feb 5, 2020
Merged

knot-resolver: 4.3.0 -> 5.0.0 -> 5.0.1 #78628

merged 6 commits into from Feb 5, 2020

Conversation

@vcunat
Copy link
Member

@vcunat vcunat commented Jan 27, 2020

Motivation for this change

https://gitlab.labs.nic.cz/knot/knot-resolver/tags/v5.0.0

The service needed lots of changes. A few smaller changes are added into the PR, e.g. replacement for PR #72014. See the commit messages for details.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • N/A Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • N/A Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-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):
    negligible increase (9576 bytes)
  • N/A Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
  • Tested the NixOS service with various combinations of options.
@vcunat
Copy link
Member Author

@vcunat vcunat commented Jan 28, 2020

Note: upstream and packages on other distros now use the "knot-resolver" name on more places, e.g. /var/cache/knot-resolver/ instead of /var/cache/kresd/, user/group name and /etc/knot-resolver/. The cost/benefit ratio of doing such changes didn't seem very favorable to me, so I didn't touch those – at least for now. Well, moving /etc/ stuff is easy on NixOS, but users can't edit it anyway and they might not have motivation to even read from there, so it's perhaps unimportant.

@Mic92
Copy link
Contributor

@Mic92 Mic92 commented Jan 28, 2020

I would migrate to upstream defaults soonish as it makes it easier to follow upstream documentation. And the stuff you mentioned here should not require user intervention in the most cases (different users, service names, cache directory)

@vcunat
Copy link
Member Author

@vcunat vcunat commented Jan 28, 2020

  • user+group: drop the current IDs? And either assign now ones or migrate to that "dynamic" scheme of systemd? (I'm not aware of a good way of renaming them, but I haven't looked much.)
  • cache directory: the old one will just be left rotting, I guess? I consider instead adding tmpfiles spec that removes the old one.
@vcunat
Copy link
Member Author

@vcunat vcunat commented Jan 28, 2020

I wonder whether to put all the changes into this single PR, but it probably doesn't really matter, given the (expected) number of reviewers.

@Mic92
Copy link
Contributor

@Mic92 Mic92 commented Jan 28, 2020

* user+group: drop the current IDs?  And either assign now ones or migrate to that "dynamic" scheme of systemd?  (I'm not aware of a good way of renaming them, but I haven't looked much.)

knot-resolver looks like a good candidate for DynamicUser except that users might need a user/group in case certificates are generated via the acme module for chowning them (or any other secret managed by nixops/krops). It is not possible right now to rename uid/gids, however old ids just get recycled eventually.

* cache directory: the old one will just be left rotting, I guess?  I consider instead adding tmpfiles spec that removes the old one.

I fear that deleting user data causes more harm than it helps. I would just leave it as it is.

@vcunat
Copy link
Member Author

@vcunat vcunat commented Jan 28, 2020

Right, if it would make it more difficult to give kresd read access to ACME certs, I don't think we want to go that way. So I'll get new fixed IDs, I suppose.

There should be no "user data" in the cache directory. I know we don't precisely follow FHS or similar, but still.

/var/cache/ Flushing this directory should have no effect on operation of programs, except for increased runtimes necessary to rebuild these caches.

Still, if there are any doubts, not touching the old cache is the easiest approach.

@Mic92
Copy link
Contributor

@Mic92 Mic92 commented Jan 29, 2020

Right, if it would make it more difficult to give kresd read access to ACME certs, I don't think we want to go that way. So I'll get new fixed IDs, I suppose.

The IDs don't need to be fixed. They can also be allocated at activation time, however a user/group name should be allocated for chown() to work.

There should be no "user data" in the cache directory. I know we don't precisely follow FHS or similar, but still.

/var/cache/ Flushing this directory should have no effect on operation of programs, except for increased runtimes necessary to rebuild these caches.

Still, if there are any doubts, not touching the old cache is the easiest approach.

Looks fine, I would just add a comment when to remove these tmpfile rules. For example NixOS 21.09.

@vcunat
Copy link
Member Author

@vcunat vcunat commented Jan 29, 2020

The IDs don't need to be fixed. [...]

Whenever the IDs change, the file ownership won't match anymore. I think ownership can be force-changed by switching to "e" rule in tmpfiles, but overall I wonder about cost/benefit ratio.

@Mic92
Copy link
Contributor

@Mic92 Mic92 commented Jan 29, 2020

The IDs don't need to be fixed. [...]

Whenever the IDs change, the file ownership won't match anymore. I think ownership can be force-changed by switching to "e" rule in tmpfiles, but overall I wonder about cost/benefit ratio.

If CacheDirectory is used than systemd should take care of fixing the ownership.

@vcunat
Copy link
Member Author

@vcunat vcunat commented Jan 29, 2020

Right, that's a possible approach, if we remove the possibility to configure cacheDir location (or restrict it being within /var/cache/).

@Mic92
Copy link
Contributor

@Mic92 Mic92 commented Jan 30, 2020

I don't think this option is often used anyway. Deprecating it makes things easier and it is always possible to put a different filesystem using a bind mount. Also see: 5c18c08

@vcunat
Copy link
Member Author

@vcunat vcunat commented Jan 30, 2020

OK, let me remove that option.

By the way, larger deployments want to have cache in tmpfs to reduce the I/O load (and persistence across reboots isn't a big deal), and we/upstream recommend to mount a separate tmpfs on the cache directory instead of relocating it. Perhaps I'll add a simple NixOS option for this later, though I haven't yet looked into whether to do this via systemd features or plain filesystems."/var/cache/knot-resolver".

vcunat added 5 commits Jan 27, 2020
The cqueues fix is in nixpkgs already, so it works now.
Part of this is approximate revert of commit f0d2da4.
Minor incompatibilities due to moving to upstream defaults:
  - capabilities are used instead of systemd.socket units
  - the control socket moved:
    /run/kresd/control -> /run/knot-resolver/control/1
  - cacheDir moved and isn't configurable anymore
  - different user+group names, without static IDs

Thanks Mic92 for multiple ideas.
@vcunat vcunat force-pushed the vcunat:p/kresd-5 branch from cd07cd1 to 02bf055 Jan 31, 2020
@vcunat
Copy link
Member Author

@vcunat vcunat commented Jan 31, 2020

I incorporated all that's been discussed now, I think. Also minor fixes/improvements were added, and the git history was cleaned up. I'm using the service already, as usual.

All the namings (users, paths) should be the same now as in other distributions and (upstream) docs. I kept the services.kresd name, as I'm not aware of any equivalent elsewhere anyway – but it would be cheap to change (compatible).

@Mic92
Mic92 approved these changes Feb 1, 2020
Copy link
Contributor

@Mic92 Mic92 left a comment

Looks good! Have not tested it but I assume you did.

@Mic92
Mic92 approved these changes Feb 1, 2020
Copy link
Contributor

@Mic92 Mic92 left a comment

Looks good! Have not tested it but I assume you did.

@Mic92
Mic92 approved these changes Feb 1, 2020
Copy link
Contributor

@Mic92 Mic92 left a comment

Looks good! Have not tested it but I assume you did.

@vcunat vcunat changed the title knot-resolver: 4.3.0 -> 5.0.0 knot-resolver: 4.3.0 -> 5.0.0 -> 5.0.1 Feb 5, 2020
vcunat added a commit that referenced this pull request Feb 5, 2020
The service needed lots of changes. A few smaller changes
are added into the PR, e.g. replacement for PR #72014.
See the commit messages for details.
@vcunat vcunat merged commit e3edb00 into NixOS:master Feb 5, 2020
@vcunat vcunat deleted the vcunat:p/kresd-5 branch Feb 5, 2020
dtzWill added a commit to dtzWill/nixpkgs that referenced this pull request Feb 5, 2020
The service needed lots of changes. A few smaller changes
are added into the PR, e.g. replacement for PR NixOS#72014.
See the commit messages for details.

(cherry picked from commit baeed03)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.