Jinja error for file during highstate, but deploying file manually works fine. (Salt parsing macros meant for something else?)

[digdilem]

Problem description

I have two files which I deploy to a few machines in a specific Configuration Channel.

Uyuni (or perhaps Salt) seems to be erroneously expanding a macro meant for something else and is breaking as a result.

In the example file, this breaks in a systemd .d stub file which sets a specific ExecStart for Docker that we want to use. However, Uyuni refuses to deploy this file during a Highstate, and if the file exists on the client already, breaks Highstate every time.

Uyuni's manual deploy of the file works fine, this issue only seems to happen with State operations when Uyuni (salt?) checks the client file to decide if it needs replacing.

The same thing happens if I use {{.Name}} in any file managed by Uyuni, even if it's on a commented line.

This pretty much breaks my want to use Uyuni to config manage a specific service.

If this is Salt's issue as I suspect, then it may be beyond Uyuni's ability to resolve. But I am fairly unfamiliar with Salt.

Does anyone know a workaround?

----------
          ID: manager_org_1.docker-temporary_2024./etc/systemd/system/docker.service.d/_docker_config.conf
    Function: file.managed
        Name: /etc/systemd/system/docker.service.d/_docker_config.conf
      Result: false
     Comment: Unable to manage file: Jinja syntax error: unexpected '.'; line 9

---
[...]

[Service]
# Empty line needed to bypass duplicate ExecStart error
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --default-address-pool base=172.27.0.0/16,size=24 --default-ulimit nproc=1024:2048 --default-ulimit nofile=512:1024 --no-new-privileges --live-restore --userland-proxy=false --log-driver syslog --log-opt syslog-address=unixgram:///dev/log --log-opt tag="docker/{{.Name}}"    <======================

---

Steps to reproduce

1. Add {{.Name}} to any file config-managed by Uyuni
2. Use State -> Highstate on any vm subscribed to the config channel containing the above file.

Uyuni version

2024.02

Uyuni proxy version (if used)

No response

Useful logs

Client machine is Rocky 9

Additional information

No response

[digdilem]

I have discovered a workaround for my specific use case, leaving here for others.

In terms of 'fixing' Uyuni, if that is possible, is to extend the "Change delimiter" field so it also works with Salt managed clients. I don't know if that is possible.

My (horrible but working) fix is:

One can specify these logging options for Docker in /etc/docker/daemon.json too. Because that's JSON, it also allows you to unicode encode characters, so I've changed one of the leading curly brackets to unicode. This is sufficient for Jinja to ignore it, but still parseable as valid JSON to docker.

Eg: "tag": "docker/\u007B{.Name}}

[avshiliaev]

Hey @digdilem
thanks for the report. I'm glad you've found a workaround.
In fact, if I get your problem right, this is an expected behavior of Jinja. For example, here it's documented for almost this very case, you've been referring to.

[digdilem]

Interesting link, thank you. I didn't try that, but i don't think it would work in this example, as the brackets need to be presented intact when deployed in a file. Escaping them like that would allow Salt and Uyuni to deploy the file without trying to parse it, but would then break docker because it doesn't understand that form of escaping.

Uyuni UI has the option to change the macro delimiters for config files, but only for the deprecated traditional clients, not salt ones. It's a little irksome to see that option in the UI but be unable to use it...

I agree it's a thorny problem, and possibly one that's rare enough not to be worth resolving.

If the team want to close this with WONTFIX or CANTFIX, that's fine, I do understand.

Thanks for your thoughts.

[avshiliaev]

Seems to be solved then, please feel free to reopen if needed 😃

[digdilem]

Ok with it being closed, but it's not solved - perhaps a CANTFIX or WONTFIX would be appropriate, if available.