I've gone back and forth on this one over time; lately my
thought is that conceptually `/` is stuff that bootc/ostree doesn't
actually own, and so we shouldn't add this bit.
For a use case of e.g. testing out bootc via an "alongside" install,
we would want to enable rolling back to the non-bootc state
(at some point in the future when we e.g. save the original `/boot`)
and the immutable bit would be a thing we'd then need to undo.
The readonly bind mount over `/sysroot` should be sufficient for
our use cases.
Signed-off-by: Colin Walters <walters@verbum.org>
Right now we're not using a `Cargo.lock`, but we should. Let's
try out renovate like some other Rust containers/ GH repos.
e.g. 67b7da4a89
I commented out the assignee thing as we don't have a dedicated
team yet.
Signed-off-by: Colin Walters <walters@verbum.org>
The current `bootc install` model is VERY opinionated: we install
the running container image to disk, and that is (almost!) it.
The only non-container out of band state that we support injecting right now
is kargs (via `--karg`) - we know we need this for machine local
kernel arguments.
(We do have a current outstanding PR to add a highly generic mechanism
to inject arbitrary files in `/etc`, but I want to think about that more)
THis current strict stance is quite painful for
a use case like "take a generic container image and bootc install to-filesystem --alongside"
in a cloud environment, because the generic container may not
have cloud-init.
With this change it becomes extremely convenient to:
- Boot generic cloud image (e.g. AMI with apt/dnf + cloud-init)
- cloud-init fetches SSH keys from hypervisor (instance metadata)
- podman run -v /root/.ssh/authorized_keys:/keys:ro <image> bootc install ... --root-ssh-authorized-keys=/keys`
And then the instance will carry forward those hypervisor-provided
keys but without a dependency on cloud-init.
Another use case for this of course is being the backend of things
like Anaconda's kickstart verbs which support injecting SSH keys.
Signed-off-by: Colin Walters <walters@verbum.org>
We're going to investigate supporting installing SELinux-enabled
targets from a SELinux-disabled host. This environment
variable will allow bypassing the check.
xref https://github.com/ostreedev/ostree/pull/3151
Signed-off-by: Colin Walters <walters@verbum.org>
I just keep hitting the host skopeo requirement in corner cases;
it's annoying because *otherwise* the container is self-sufficient.
Change our installation instructions to add a `/var/lib/containers`
bind mount.
For the time being of course we continue to support forking off
`skopeo` on the host.
One thing I still want to investigate is dropping some requirements
here and switch to *dynamically* setting up the mount points
inside the container as is mentioned in https://brauner.io/2023/02/28/mounting-into-mount-namespaces.html
but this currently requires relatively new host kernels.
As far as test coverage, this changes the Github Action that
uses ubuntu and needed to build a newer skopeo to stop doing
that, and in fact we explicitly *remove* skopeo to verify
it's not being used in the install process.
I didn't change the other install tests to verify they keep
working.
Closes: https://github.com/containers/bootc/issues/81
Signed-off-by: Colin Walters <walters@verbum.org>
Even when an external process is creating the disk, we want
it to be able to honor the root filesystem type specified in the container.
Signed-off-by: Colin Walters <walters@verbum.org>
Closes: https://github.com/containers/bootc/issues/218
Basically this effort has not been really successful and adds
more pain than it solves. We need to have a solution that works
for podman too.
In many scenarios, TLS is sufficient - or at least, we're far
from the only thing that if fetched from a compromised server
would result in a compromised system (e.g. privileged containers).
Signed-off-by: Colin Walters <walters@verbum.org>
Take the current `install` verb and change it to be
`bootc install to-disk`, and then `install-to-filesystem` becomes
`bootc install to-filesystem` - they are obvious peers.
The main motivation here is that in the end many use cases will
want nontrivial filesystem customization, and while I like having
a fully opinionated builtin flow to write to a target disk,
we should really think of `to-filesystem` as a fully equal peer
of `to-disk`.
Signed-off-by: Colin Walters <walters@verbum.org>
Having a fast disposable VM is good for this. Also we are now
verifying that the baseline functionality works to install alongside
an Ubuntu system!
Signed-off-by: Colin Walters <walters@verbum.org>
Right now we only install a single binary, but in the future
that will change (e.g. systemd units, config files).
Signed-off-by: Colin Walters <walters@verbum.org>
The install code greatly increases the scope of this project. Not
every OS/distribution will want it on by default; some may always
want to use their own install code.
Having a feature for this shows that while we're opinionated, we're
also flexible.
Signed-off-by: Colin Walters <walters@verbum.org>
I typed `bootc status` in a container and got an unhelpful error.
Print something more useful and add integration tests for this
scenario.
Signed-off-by: Colin Walters <walters@verbum.org>
Usage example with `/dev/vda` being an extra mounted disk:
```
$ podman run --privileged --pid=host --net=none quay.io/cgwalters/c9s-oscore:latest bootc install /dev/vda
```
Signed-off-by: Colin Walters <walters@verbum.org>
First, this adds `cargo xtask` following
https://github.com/matklad/cargo-xtask/
We use this to write "external glue scripts" in Rust, not bash.
Specifically we now have e.g. `cargo xtask vendor` which just
wraps running `cargo vendor-filterer`.
Then build on that and add `cargo xtask package-srpm` which generates
a `.src.rpm`.
And build on that by adding the requisite glue to have Fedora's COPR
be able to understand it, so that we can get auto-built and shipped
packages there.
This will make trying out bootc a bit easier.
Signed-off-by: Colin Walters <walters@verbum.org>
Add a feature to enable internal tests. I originally started
by matching
6543c85558
but since here the binary is really end user facing and not just
a demo, we shouldn't enable the feature by default.
If in the future we split off the tiny CLI bit out of the workspace,
then we could auto-enable but that seems not worth it.
Signed-off-by: Colin Walters <walters@verbum.org>
