This allows to combine `org.osbuild.mkdir` with the `osbuild.deployment`
mount and with the upcoming `org.osbuild.bind` mount. The use case is
that we need to create the dir `/var/home` so that `useradd` from inside
a ostree root works (there /home is a symlink and useradd will not
follow the symlink and create a dir in the target by itself).
This allows to write:
```json
{
"type": "org.osbuild.mkdir",
"options": {
"paths": [
{
"path": "/var/home"
}
]
},
"devices": {
"disk": {
"type": "org.osbuild.loopback",
"options": {
"filename": "disk.raw",
"partscan": true
}
}
},
"mounts": [
{
"name": "part4",
"type": "org.osbuild.ext4",
"source": "disk",
"target": "/",
"partition": 4
},
{
"name": "part3",
"type": "org.osbuild.ext4",
"source": "disk",
"target": "/boot",
"partition": 3
},
{
"name": "part2",
"type": "org.osbuild.fat",
"source": "disk",
"target": "/boot/efi",
"partition": 2
},
{
"name": "ostree.deployment",
"type": "org.osbuild.ostree.deployment",
"options": {
"source": "mount",
"deployment": {
"default": true
}
}
},
{
"name": "bind",
"type": "org.osbuild.bind",
"target": "tree://",
"options": {
"source": "mount://"
}
}
]
},
```
to fix this.
When moving to `bootc install to-filesystem` we will need support
for mounting the deployed disk and writing to the deployment root
this requires that we teach the users and selinux stages to
have them available. This is a first step towards this.
It also adds tests to ensure the options can be passed.
This is a preparation to allow adding mounts/devices to the users
stage so that we can eventually support bootc install to-filesystem.
It also adds some smoke tests for the schema to ensure it's still
valid.
In CoreOS Assembler, some hyperv artifact we `zip` for compression. This
new stage is modeled after the `org.osbuild.tar` stage with necessary
modifications.
Update the org.osbuild.systemd.unit stage to also support multiple
Environment options where each is an object with {key: value}. Enable
the allow_no_value option in configparser so we can add the multiple
entries.
Support the Environment and EnvironmentFile options in the Service
section of the unit file.
The Environment option is set as an object with keys "key" and "value"
and the key is validated with a pattern.
Updated the stage to special-case the Environment option.
By default "bootc" will refuse to work on a non-selinux system if
the bootc container requires selinux. This is a sensible approach
in general but for us it's tricky because we want to be able to
generate images when running on developer machines or CI machines
that may not necessarily have selinux. So make bootc more relaxed.
- Move functions to the 'util' to centralize common
functionality, reducing code duplication and improving
maintainability across the codebase.
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
This is needed because on a mounted `bootc` container `setfiles`
without excluding `/sysroot` will create many warnings like:
```
setfiles: conflicting specifications for /run/osbuild/tree/sysroot/ostree/repo/objects/00/0ef9ada2ee87792e8ba21afd65aa00d79a1253018832652b8694862fb80e84.file and /run/osbuild/tree/usr/lib/firmware/cirrus/cs35l41-dsp1-spk-prot-103c8b8f-r1.bin.xz, using system_u:object_r:lib_t:s0.
```
but simply excluding this dir fixes them.
The issue with mocking subprocess.call() is that we will not
catch if arguments are passed as eg. integers. So instead use
the `mock_command()` helper so that a real binary is called.
The current `make_container()` helper is a bit silly (which is
entirely my fault). It requires a container tag as input but all
tests end up creating a random number for this input. So instead
just remove the input and return the container_id from the podman
build in the contextmanager and use that.
To start using the `bootc.instal-to-filesystem` stage we need
to be able to test the generated images. This requires a login
on the disk. Traditionally we did that via the `users` stage.
But on a bootc system we do not want to modify the disk after
bootc did the install to avoid messing with things like the
selinux labels or (future) fsverity setups.
So for now we will use the `--root-ssh-authorized-keys` feature
to inject support for login.
So this commit adds a new option to the stage called
`root-ssh-authorized-keys`.
Instead of always parsing the python stage to load meta information
allow the user of a new `{stage}-meta.json` file. This is a first
step towards allowing modules to be written in a different language
than python. It also has some practical advantages:
- slightly faster as it avoids calling python to output the schemas
- easier to write schemas as this can be done in a real json editor
now
- more extensible in a future where stages maybe binaries with
shlib dependencies that are only satisfied in the buildroot
but not on the host
Add the expiredate field to the users option in the org.osbuild.users
stage. This option maps to the --expiredate option of useradd/usermod,
which can be useful when creating users whose password must be changed
upon first login.
This is a follow up to #1550 where we enabled a `rw` permissions mode,
which is not ideal since it would theoretically be possible to set both
`ro` and `rw` modes at the same time. This commit fixes the issue by only
allowing one option at a time.
Fixes#1588
User can now customize the systemd unit load path.
User can select between etc or usr , defaults to 'usr'.
Also user can customize the scope of the service between global
or system, defaults to system.
Signed-off-by: Sayan Paul <paul.sayan@gmail.com>
With the test the helper can now be slightly simplified. Because
we only have two results it seems easier to just use them directly
than to store them in an intermediate result struct.
- Process all necessary operations related to CoreOS
platforms is crucial and specific to CoreOS. This step
is essential for CoreOS exclusively.
- Our approach to handling 'platforms.json' may change as we
advance with the OSBuild work. However, we don't have a clear
vision about how it will be in the future yet, particularly as
we also manage similar components within the osbuild composer
to configure cloud parameters. We probably will know better
when we start working with the cloud artifacts.
As a summary, let's add it know to unblock us, and if we find a
better approach in the future, we can always go back and remove it.
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
- Add functions for appending kernel parameters to the
Boot Loader Specification (BLS) as needed.
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
While integrating the changes to grub2 config stage options in the
`osbuild/images` repository, I noticed that the code for grub2.legacy
is embedding the grub2 stage config options struct in its own config
options struct [1]. However, the grub2 stage options contain also the
`default` entry, while the grub2.legacy stage does not allow this option
in its stage options.
This change fixes that and ensures that the grub2 stage options config
section is a subset of the grub2.legacy stage options config section.
[1] d5644f3115/pkg/osbuild/grub2_legacy_stage.go (L85)
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
