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

Consider/evaluate building FHS environments for containers #58

Open
tazjin opened this issue Oct 3, 2019 · 6 comments
Open

Consider/evaluate building FHS environments for containers #58

tazjin opened this issue Oct 3, 2019 · 6 comments
Labels
enhancement New feature or request needs-fhs Issues blocked by issue #58

Comments

@tazjin
Copy link
Owner

tazjin commented Oct 3, 2019

This might lead to container images that people who are unfamiliar with Nix find more useful.

In practice, this would replace the symlink layer that is currently constructed via symlinkJoin in Nix with a layer that looks like an FHS layout. If there's a primitive in Nix for doing this, it might be preferable!

@tazjin tazjin added the enhancement New feature or request label Oct 3, 2019
@wamserma
Copy link

Like buildFHSChrootEnv {} + chroot in the final layer?
(see also here http://sandervanderburg.blogspot.com/2013/09/composing-fhs-compatible-chroot.html)

@JohnAZoidberg
Copy link

JohnAZoidberg commented Oct 23, 2019

I've done that, to run proprietary software in a container like:

let
  pkgs = import <nixpkgs> {};
  # Just build the FHS without the env part, that chroots you into it
  fhs = (pkgs.callPackage <nixpkgs/pkgs/build-support/build-fhs-userenv/env.nix> {}) {
    name = "container-fhs";
    targetPkgs = pkgs: with pkgs; [ hello cowsay ];
    multiPkgs = null;  # Don't include glibc's multilib
  };
in
  pkgs.dockerTools.buildImage {
  name = "custom-container";
  tag = "latest";

  contents = pkgs.symlinkJoin {
    name = "contents";
    paths = with pkgs; [
      fhs

      # Creating directories and files like this is much faster than runAsRoot
      (pkgs.runCommand "tempfiles" {} ''
        mkdir -p $out/{var/tmp,tmp}
      '')

      /more/paths
    ];
  };

  config = {
    Env = [
      "PATH=usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      "LD_LIBRARY_PATH=/run/opengl-driver/lib:/run/opengl-driver-32/lib:/usr/lib:/usr/lib32:"
    ];
    Entrypoint = [ "${pkgs.bashInteractive}/bin/bash"];
  };
}

@tazjin
Copy link
Owner Author

tazjin commented Oct 24, 2019

@JohnAZoidberg Thanks, that's close to what I imagined - good to know that this already exists as isolated functionality!

The barebones FHS env still pulls in a lot of stuff that we don't want in container images - I'll take a look at how that can be reduced, and alternatively find a way to maybe gate the FHS feature (e.g. by introducing an fhs meta-package that triggers the behaviour).

@JohnAZoidberg
Copy link

Yeah, there's lots of room for tweaking in pkgs/build-support/build-fhs-userenv/env.nix.

Especially:

basePkgs = with pkgs;
  [ glibcLocales
    (if isMultiBuild then glibc_multi else glibc)
    (toString gcc.cc.lib) bashInteractive coreutils less shadow su
    gawk diffutils findutils gnused gnugrep
    gnutar gzip bzip2 xz
  ];

@tazjin
Copy link
Owner Author

tazjin commented Oct 25, 2019

@JohnAZoidberg Are you at NixCon by any chance? If so we could probably spend an hour or so hacking on this.

@JohnAZoidberg
Copy link

Yes, I am. Sure, that'd be fun! You can come to me after my talk. It's the first one tomorrow morning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs-fhs Issues blocked by issue #58
Projects
None yet
Development

No branches or pull requests

3 participants