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.

Sign up for GitHub

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

Jump to bottom

gitea: Added option sandbox to be able to disable systemd sanboxing #94756

Closed
wants to merge 1 commit into from
Closed

gitea: Added option sandbox to be able to disable systemd sanboxing #94756

wants to merge 1 commit into from

Conversation

asbachb
Copy link
Contributor

@asbachb asbachb commented Aug 5, 2020

Motivation for this change

Add ability to disable systemd sandbox functionality in order to run gitea inside an lxd container.

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
  • 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 nixpkgs-review --run "nixpkgs-review wip"
[nix-shell:/tmp/nixpkgs]# nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
these paths will be fetched (0.03 MiB download, 0.13 MiB unpacked):
  /nix/store/91qp2v2h0fd9d6b6hchzf13zki091grv-nixpkgs-review-2.3.1
copying path '/nix/store/91qp2v2h0fd9d6b6hchzf13zki091grv-nixpkgs-review-2.3.1' from 'https://cache.nixos.org'...
$ git -c fetch.prune=false fetch --force https://github.com/NixOS/nixpkgs master:refs/nixpkgs-review/0
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 16 (delta 4), reused 3 (delta 3), pack-reused 3
Unpacking objects: 100% (16/16), 178.79 KiB | 660.00 KiB/s, done.
From https://github.com/NixOS/nixpkgs
   580a0e52b13..f9f48250fe1  master     -> refs/nixpkgs-review/0
$ git worktree add /root/.cache/nixpkgs-review/rev-4bf631ed876b8b63ff68c6cd3cba4a7d9ea53a03-dirty/nixpkgs f9f48250fe1657f288a88c8ef519576a7b12a31b
Preparing worktree (detached HEAD f9f48250fe1)
Updating files: 100% (22324/22324), done.
HEAD is now at f9f48250fe1 nixos/smartd: add option for notifiction email sender
$ nix-env -f /root/.cache/nixpkgs-review/rev-4bf631ed876b8b63ff68c6cd3cba4a7d9ea53a03-dirty/nixpkgs -qaP --xml --out-path --show-trace
No diff detected, stopping review...
$ git worktree prune
  • 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)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@asbachb
gitea: Added option sandbox to be able to disable systemd sanboxing…
4bf631e 
… features

This is useful to run gitea inside an lxd container.
@aanderse
Copy link
Member

aanderse commented Aug 6, 2020

Can you explain the issues you are having in more detail please?

ping @flokli @Ma27 @Mic92 @Izorkin

@asbachb
Copy link
Contributor Author

asbachb commented Aug 6, 2020

@aanderse

Aug 04 13:52:40 nixos systemd[14745]: gitea.service: Executing: /nix/store/404wfnlg9dvlzphd955zlqfclsaa31aj-gitea-1.11.8-bin/bin/gitea web
Aug 04 13:52:40 nixos systemd[1]: gitea.service: Failed to read oom_kill field of memory.events cgroup attribute: No such file or directory
Aug 04 13:52:40 nixos systemd[1]: gitea.service: Child 14745 belongs to gitea.service.
Aug 04 13:52:40 nixos systemd[1]: gitea.service: Main process exited, code=dumped, status=31/SYS
Aug 04 13:52:40 nixos systemd[1]: gitea.service: Failed with result 'core-dump'.

Since I already separate my services via lxd containers I don't see the point in additionally sandbox it via systemd.

Mic92
Mic92 requested changes Aug 6, 2020
View reviewed changes
Copy link
Member

@Mic92 Mic92 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should have a sandbox flag for every systemd service. We introduce "sandboxing" in many services now. It's not a boolean flag, some features might not work in docker, some features might work in lxd. If systemd features don't work in LXD containers we should disable them in general for LXD instead of introducing a flag in every service.

@Mic92
Copy link
Member

Mic92 commented Aug 6, 2020

cc @NixOS/systemd

@asbachb
Copy link
Contributor Author

asbachb commented Aug 6, 2020

I don't think we should have a sandbox flag for every systemd service. We introduce "sandboxing" in many services now. It's not a boolean flag, some features might not work in docker, some features might work in lxd. If systemd features don't work in LXD containers we should disable them in general for LXD instead of introducing a flag in every service.

@Mic92 You mean it should be checked for boot.isContainer? Maybe it would make sense to configure the sandboxing stuff on another level of systemd configuration so that the entire level could be enabled/disabled by boot.isContainer on a centralized level.

@flokli
Copy link
Contributor

flokli commented Aug 6, 2020

boot.isContainer also doesn't give you some information inside which container runtime it's running, and how cgroups are mounted in there.

I propose approaching systemd upstream here. This smells like some problem with not all cgroups being available inside lxd, and systemd failing ungracefully.

@flokli flokli closed this Aug 6, 2020
@Izorkin
Copy link
Contributor

Izorkin commented Aug 7, 2020

@asbachb can try this variant:

systemd.services.gitea.serviceConfig = lib.mkForce {
  ProtectHome = false;
  PrivateDevices = false;
  ProtectKernelTunables = false;
  ProtectKernelModules = false;
  ProtectControlGroups = false;
...
};

@asbachb
Copy link
Contributor Author

asbachb commented Aug 19, 2020 •
edited

@Izorkin Basically this kind of configuration prevents the app.in from being generated.

Started another discussion on lxd forums: https://discuss.linuxcontainers.org/t/sandboxed-systemd-service-fails-due-to-cgroups-issue/8650/5

@Mic92
Copy link
Member

Mic92 commented Aug 19, 2020

@Izorkin Basically this kind of configuration prevents the app.in from being generated.

Started another discussion on lxd forums: discuss.linuxcontainers.org/t/sandboxed-systemd-service-fails-due-to-cgroups-issue/8650/5

So maybe your solution is to use cgroup v2?

@asbachb asbachb deleted the gitea-sandbox-option branch January 25, 2021 21:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Mic92 Mic92 Mic92 requested changes

Assignees
No one assigned
Labels
6.topic: nixos 8.has: module (update) 10.rebuild-darwin: 0 10.rebuild-linux: 1-10 10.rebuild-linux: 1
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
5 participants
@asbachb @aanderse @Mic92 @flokli @Izorkin