The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
/etc/containers is also used by Podman, Skopeo & other popular
container tooling so we need to be able to move to another
configuration directory.
The state move is not strictly a requirement but is good for consistency.
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
This reverts commit 7cb100b683.
See also #83432.
This appears to break at least the `container`-backend of `nixops`: when
running `switch-to-configuration` within `nixos-container run`, the
running `systemd`-instance gets reloaded which appears to kill the
`systemd-run` command and causes `nixos-container run` to hang.
The full issue is reported in the original PR[1].
[1] https://github.com/NixOS/nixpkgs/pull/67332#issuecomment-604145869
(cherry picked from commit 7f1ba606ac)
E.g. to create a container that runs the NixOS homepage:
$ nixos-container create homepage --flake nixos-homepage
And to upgrade it:
$ nixos-container update homepage
I have a nixops network where I deploy containers using the `container`
backend which uses `nixos-container` intenrally to deploy several
containers to a certain host.
During that time I removed and added new containers and while trying to
deploy those to a different host I realized that it isn't guaranteed
that each container gets the same IP address which is a problem as some
parts of the deployment need to know which container is using which IP
(i.e. to configure port forwarding on the host).
With this change you can specify the container's IP like this (and don't
have to use the arbitrarily used 10.233.0.0/16 subnet):
```
$ nixos-container create test --config-file test-container.nix \
--local-address 10.235.1.2 --host-address 10.235.1.1
```
The containers local address can be given as ipv4 only or with a subnetmask in
CIDR notation in the container configuration, see [1]. This works fine but the
'nixos-container show-ip' only supports plain ipv4 addresses without the netmask
suffix.
Changed the regex to also match in case of a CIDR netmask suffix.
[1] 9939032e35/nixos/modules/virtualisation/containers.nix (L382)
This reverts commit
c37e76b4d2. Unfortunately, using
"machinectl shell" has two bad side effects:
* It sends the command's stderr to stdout.
* It doesn't propagate the command's exit status.
This broke NixOps.
PR #18825.
This should be completely backwards compatible. It allows the '-f' part
of the nix-env command to be configured. This greatly eases using
nixos-container as part of development where several nixpkgs
repositories might be tested at the same time.
My earlier commit to have `nixos-container destroy` use `kill` broke
the `container-imperative` test, see[1]. As suggested by @aszlig,
`machinectl terminate` doesn't have that problem, and is the command
that should have been used to begin with rather then `kill`.
1| 60c6c7bc9a (commitcomment-18478032)
Using 'machinectl kill' is much faster then gracefully stopping the
container.
In the case of 'destroy', since we're destroying it anyway, there's no
reason to do a graceful shutdown.
This moves nixos-containers into its own package so that it can be
relied upon by other packages/systems. This should make development
using dynamic containers much easier.
