Only core prunes the message of the day drop-ins of another product #16

New issue

Open

opened 2026-09-28 02:37:11 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 02:37:11 -03:00

(Migrated from github.com)

Keel-Linux/keel-core#9 removes the two message of the day drop-ins that
speak for another product, in conf.d/main of the core recipe, because an
overlay can add a file and cannot remove one. That is enough for the way
Keel ships and not enough for every way a recipe can be built.

Why it is enough today. bt-layer subtracts the parent's common_conf
from the child's, so no appliance built on core re-runs
common/conf/turnkey.d/motd. Measured on the build host on 2026-09-28,
the mariadb, wordpress, redis and postgresql layer tarballs carry no
/etc/update-motd.d entries at all: core's removals are what every layer
above it inherits.

Where it is not. A plain make of a non-core recipe runs with the full
COMMON_CONF and no parent to subtract it, so conf/turnkey.d/motd writes
00-turnkey-sysinfo and 08-turnkey-confconsole again and nothing removes
them. That image welcomes the operator twice and tells them to run
tklbam-init, and keel_motd_check_dir is not called there to catch it.
The ISO path and an M0-style full build are built that way, so this is not
hypothetical.

What closes it. Either the same two calls in every recipe's conf.d:

. /usr/lib/keel/motd.sh
keel_motd_prune_dir /etc/update-motd.d
keel_motd_check_dir /etc/update-motd.d

or the arrangement asserted somewhere that is not one product's conf script.
The recipes: keel-apache-php, keel-lamp, keel-lapp, keel-mariadb,
keel-nodebb, keel-nodejs-nginx, keel-postgresql, keel-redis,
keel-transition, keel-wordpress.

Recorded rather than solved in keel-core#9 by agreement with the review:
every appliance Keel ships is strictly better off with that change and none
regresses, so it should not wait for this. The limit is written down in
conf.d/main and COVERAGE.md of keel-core.

Context: Keel-Linux/tracker#6, Keel-Linux/keel-core#7, handbook decision 0014.

Keel-Linux/keel-core#9 removes the two message of the day drop-ins that speak for another product, in `conf.d/main` of the core recipe, because an overlay can add a file and cannot remove one. That is enough for the way Keel ships and not enough for every way a recipe can be built. **Why it is enough today.** `bt-layer` subtracts the parent's `common_conf` from the child's, so no appliance built on core re-runs `common/conf/turnkey.d/motd`. Measured on the build host on 2026-09-28, the mariadb, wordpress, redis and postgresql layer tarballs carry no `/etc/update-motd.d` entries at all: core's removals are what every layer above it inherits. **Where it is not.** A plain `make` of a non-core recipe runs with the full `COMMON_CONF` and no parent to subtract it, so `conf/turnkey.d/motd` writes `00-turnkey-sysinfo` and `08-turnkey-confconsole` again and nothing removes them. That image welcomes the operator twice and tells them to run `tklbam-init`, and `keel_motd_check_dir` is not called there to catch it. The ISO path and an M0-style full build are built that way, so this is not hypothetical. **What closes it.** Either the same two calls in every recipe's `conf.d`: . /usr/lib/keel/motd.sh keel_motd_prune_dir /etc/update-motd.d keel_motd_check_dir /etc/update-motd.d or the arrangement asserted somewhere that is not one product's conf script. The recipes: keel-apache-php, keel-lamp, keel-lapp, keel-mariadb, keel-nodebb, keel-nodejs-nginx, keel-postgresql, keel-redis, keel-transition, keel-wordpress. Recorded rather than solved in keel-core#9 by agreement with the review: every appliance Keel ships is strictly better off with that change and none regresses, so it should not wait for this. The limit is written down in `conf.d/main` and `COVERAGE.md` of keel-core. Context: Keel-Linux/tracker#6, Keel-Linux/keel-core#7, handbook decision 0014.