blueprint: fix cacerts name for TOML

[lzap]

@avitova found some issues, I am going to address them.

To test the CA generation run this:

go run ./cmd/gen-manifests --arches x86_64 --distros fedora-41 --types qcow2 -config ./test/configs/all-customizations.json

It creates the following file in test/data/manifests:

...
         {
            "type": "org.osbuild.copy",
            "inputs": {
              "file-4c4e8c734e4ee3a117ca8f9363ba7b706d02bfc8f297c00b02ce02babddef51c": {
                "type": "org.osbuild.files",
                "origin": "org.osbuild.source",
                "references": [
                  {
                    "id": "sha256:4c4e8c734e4ee3a117ca8f9363ba7b706d02bfc8f297c00b02ce02babddef51c"
                  }
                ]
              }
            },
            "options": {
              "paths": [
                {
                  "from": "input://file-4c4e8c734e4ee3a117ca8f9363ba7b706d02bfc8f297c00b02ce02babddef51c/sha256:4c4e8c734e4ee3a117ca8f9363ba7b706d02bfc8f297c00b02ce02babddef51c",
                  "to": "tree:///etc/pki/ca-trust/source/anchors/27894af897dd2423607045716438a725f28a6d0b.pem",
                  "remove_destination": true
                }
              ]
            }
          },
          {
            "type": "org.osbuild.chown",
            "options": {
              "items": {
                "/etc/pki/ca-trust/source/anchors/27894af897dd2423607045716438a725f28a6d0b.pem": {
                  "user": "root",
                  "group": "root"
                }
              }
            }
          },
          {
            "type": "org.osbuild.pki.update-ca-trust"
          },
...

I think it works.

[bcl]

I don't think this can be changed, any existing blueprint using this field will not be parsed correctly.

[thozza]

Except for the leftover debug prints, this looks OK to me. 👍

[thozza]

I don't think this can be changed, any existing blueprint using this field will not be parsed correctly.

This has not yet been exposed to users in any form AFAICT, and the TOML parsing here is not the same as the one used on-prem in osbuild-composer. So, all in all, this should be fine.

[lzap]

So removed the logging line and added a test, but I am not sure where exactly this shell test is being executed.

[lzap]

Tests look good, why this isn’t getting merged? Not sure if I should rebase.

[thozza]

Tests look good, why this isn’t getting merged? Not sure if I should rebase.

You dismissed my review by force-pushing. If you need just to rebase, using GH UI does not dismiss approvals.

[lzap]

Ah now I remember, I was on the wrong branch and accidentally pushed here instead, sorry! Cheers.

[lzap]

Out of curiousity, where do I see this output? I am unable to locate this job.

[thozza]

If the manifest were not rebuilt during the CI run (because it didn't change), you'd find a link to the run in which it was tested in the job that generated it (e.g. https://gitlab.com/redhat/services/products/image-builder/ci/images/-/jobs/8565731980). Since the manifest didn't change and you added the test, it was not run at all. A complete manifest regeneration would be required. That can be achieved by bumping the rngseed in

images/Schutzfile

Line 3 in 048c8c6

"rngseed": 1,

I did it in #1093 and if my comment about the potential typo from above is correct, it should fail 🤔

[thozza]

The story continuous:

• osbuild: new stage 'cacert' (HMS-4839) #907 added the cacert customization only to all-customizations.json,
• all-customizations.json is applied only when building qcow2

  images/test/config-map.json

  Lines 2 to 13 in 048c8c6

  	"./configs/all-customizations.json": {
  	"distros": [
  	"rhel-10*",
  	"rhel-9*",
  	"rhel-8*",
  	"centos*",
  	"fedora*"
  	],
  	"image-types": [
  	"qcow2"
  	]
  	},

• We do not boot-test qcow2 in this repository CI, so the change in the base-host-check.sh won't run in the CI.

[lzap]

Yeah, apologies: #1096

[thozza]

@lzap I just noticed a potential typo in the filename - note the double .pem.pem 🤔

[mvo5]

Yeah, this is curious, do we generate funky filenames here or is the test not running correctly?

[thozza]

@mvo5 see #1076 (comment). The cacert customization is not applied to any image we boot-test, so this code is never executed.