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

[RFC] stages: run "ksvalidator" optionally when generating kickstarts #1789

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mvo5
Copy link
Contributor

@mvo5 mvo5 commented May 16, 2024

There was a bug in osbuild/bootc-image-builder#363 where a stray newlnine in the ssh key broke the kickstart file (and it was a bit annoying/non-obvious to find).

The isse is that when auto-generating the config.json for an ssh keyfile it's easy to accidentally include the final \n in the ssh key json string. This will break in very non-obvious ways, i.e. the image will be generated but the kickstart file is broken because now it looks like:

sshkey --username foo "ssh-key
"

which make the kickstart invalid but that is only discovered much later when the image booted (or even later after the installer put the kickstart into the target system).

This commit runs ksvalidator (if available) to detect this kind of issue early. It requires pykickstart in the buildroot but that seems to be not too bad as we already have python3-kickstart in our buildroots AFAICT (unless I read the manifest-db incorrectly).

So it does require an extra tweak to images before it's fully useful, something like:

diff --git a/pkg/runner/centos.go b/pkg/runner/centos.go
index 2c65fac9a..a56e938a5 100644
--- a/pkg/runner/centos.go
+++ b/pkg/runner/centos.go
@@ -14,6 +14,7 @@ func (c *CentOS) GetBuildPackages() []string {
        packages := []string{
                "glibc",           // ldconfig
                "platform-python", // osbuild
+               "pykickstart",     // ksvalidator
        }
        if c.Version >= 8 {
                packages = append(packages,
diff --git a/pkg/runner/fedora.go b/pkg/runner/fedora.go
index 3482b0e11..2430cf5c3 100644
--- a/pkg/runner/fedora.go
+++ b/pkg/runner/fedora.go
@@ -12,8 +12,9 @@ func (r *Fedora) String() string {
 
 func (p *Fedora) GetBuildPackages() []string {
        return []string{
-               "glibc",   // ldconfig
-               "systemd", // systemd-tmpfiles and systemd-sysusers
-               "python3", // osbuild
+               "glibc",       // ldconfig
+               "systemd",     // systemd-tmpfiles and systemd-sysusers
+               "pykickstart", // ksvalidator
+               "python3",     // osbuild
        }
 }
diff --git a/pkg/runner/rhel.go b/pkg/runner/rhel.go
index 8b921a211..cec510556 100644
--- a/pkg/runner/rhel.go
+++ b/pkg/runner/rhel.go
@@ -13,7 +13,8 @@ func (r *RHEL) String() string {
 
 func (p *RHEL) GetBuildPackages() []string {
        packages := []string{
-               "glibc", // ldconfig
+               "glibc",       // ldconfig
+               "pykickstart", // ksvalidator
        }
        if p.Major >= 8 {
                packages = append(packages,

probably(?).

There was a bug in osbuild/bootc-image-builder#363 where a stray
newlnine in the ssh key broke the kickstart file.

The isse is that when auto-generating the config.json for an ssh keyfile
it's easy to accidentally include the final `\n` in the ssh key json
string. This will break in very non-obvious ways, i.e. the image will
be generated but the kickstart file is broken because now it looks like:
```
sshkey --username foo "ssh-key
"
```
which make the kickstart invalid but that is only discovered much later
when the image booted (or even later after the installer put the
kickstart into the target system).

This commit runs `ksvalidator` (if available) to detect this kind
of issue early. It requires `pykickstart` in the buildroot but
that seems to be not too bad as we already have `python3-kickstart`
in our buildroots AFAICT (unless I read the manifest-db incorrectly).

So it does require an extra tweak to `images` before it's fully
useful.
@bcl
Copy link
Contributor

bcl commented May 17, 2024

Something that may cause problems is that ksvalidator will run using the rules for the latest release supported by the version that is installed. If the buildroot matches the target distro release this shouldn't be an issue, if the buildroot is different it will need to pass the distro version to it. eg. ksvalidator --version F40 you can get a list of the versions from ksvalidator --listversions but they follow the obvious pattern, like F40, F41, RHEL9, RHEL10.

Or you can add a comment to the top of the kickstart, #version=F40 and it will use that as the version to check against.
Ends up there's a function for that but only anaconda uses it, not ksvalidator.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants