An appliance still announces itself as TurnKey at login #6

New issue

Open

opened 2026-09-27 14:23:40 -03:00 by marcos-mendez · 1 comment

marcos-mendez commented

2026-09-27 14:23:40 -03:00

(Migrated from github.com)

Measured on the wordpress-demo container, 2026-09-27. The login shows our
mark, the appliance name, the version and the four addresses, and then
immediately below:

Welcome to Wordpress-demo, TurnKey GNU/Linux 19.0 (Debian 13/Trixie)
...
TKLBAM (Backup and Migration):  NOT INITIALIZED
    To initialize TKLBAM, run the "tklbam-init" command to link this
    system to your TurnKey Hub account.

Three separate problems in those lines. The operator is welcomed twice, by two
different products. The second welcome names a distribution this image is not.
And it advertises a service, the Hub, that decision 0002 deferred and that this
project is decoupling from, so an operator who follows the instruction is sent
somewhere we do not go.

What it is: /etc/update-motd.d/00-turnkey-sysinfo and its neighbours, plus
/etc/turnkey_version, all inherited from the core layer.

Closes when a Keel appliance welcomes the operator once, as itself, with the
system information the TurnKey banner gives today, and says nothing about a
service this distribution does not use. Two things to decide while doing it,
and both belong in a decision note rather than in a commit message: whether
/etc/turnkey_version keeps its name, since tooling reads it and compatibility
with TurnKey appliances is a stated property of this project, and what the
appliance says about backup now that TKLBAM is deferred.

Touches keel-core's overlay, so it needs a layer rebuild to reach an appliance.

Measured on the `wordpress-demo` container, 2026-09-27. The login shows our mark, the appliance name, the version and the four addresses, and then immediately below: Welcome to Wordpress-demo, TurnKey GNU/Linux 19.0 (Debian 13/Trixie) ... TKLBAM (Backup and Migration): NOT INITIALIZED To initialize TKLBAM, run the "tklbam-init" command to link this system to your TurnKey Hub account. Three separate problems in those lines. The operator is welcomed twice, by two different products. The second welcome names a distribution this image is not. And it advertises a service, the Hub, that decision 0002 deferred and that this project is decoupling from, so an operator who follows the instruction is sent somewhere we do not go. What it is: `/etc/update-motd.d/00-turnkey-sysinfo` and its neighbours, plus `/etc/turnkey_version`, all inherited from the core layer. Closes when a Keel appliance welcomes the operator once, as itself, with the system information the TurnKey banner gives today, and says nothing about a service this distribution does not use. Two things to decide while doing it, and both belong in a decision note rather than in a commit message: whether `/etc/turnkey_version` keeps its name, since tooling reads it and compatibility with TurnKey appliances is a stated property of this project, and what the appliance says about backup now that TKLBAM is deferred. Touches keel-core's overlay, so it needs a layer rebuild to reach an appliance.

marcos-mendez commented

2026-09-27 14:30:30 -03:00

(Migrated from github.com)

Two more surfaces, measured on wordpress-demo the same day.

Webmin carries TurnKey's logo. The theme reads
/etc/webmin/authentic-theme/logo.png and logo_welcome.png, 17 KB and 15 KB,
and /usr/share/webmin/images/turnkey-blue.gif is there too. All of it comes
from the core layer, so it has the same root as the duplicated welcome and
should be fixed in the same pass.

The appliance has no page of its own. Only wordpress.conf is enabled in
Apache and /var/www holds only wordpress: the application owns the root,
so there is no appliance landing page and therefore no footer. The maintainer
noticed the absence of the footer older appliances had.

A caution to carry into that work, because the obvious fix is the wrong one:
our mark does not go in the footer of the site the operator publishes. That
page belongs to their readers, not to us, and branding it would be marking
their work with our name. The appliance's identity belongs on the surfaces the
appliance owns: the console, Webmin, the web shell, and any page the appliance
itself serves. If an appliance landing page is wanted, it is a page of ours at
a path or a port of ours, not a footer injected into the application's output.

Two more surfaces, measured on `wordpress-demo` the same day. **Webmin carries TurnKey's logo.** The theme reads `/etc/webmin/authentic-theme/logo.png` and `logo_welcome.png`, 17 KB and 15 KB, and `/usr/share/webmin/images/turnkey-blue.gif` is there too. All of it comes from the core layer, so it has the same root as the duplicated welcome and should be fixed in the same pass. **The appliance has no page of its own.** Only `wordpress.conf` is enabled in Apache and `/var/www` holds only `wordpress`: the application owns the root, so there is no appliance landing page and therefore no footer. The maintainer noticed the absence of the footer older appliances had. A caution to carry into that work, because the obvious fix is the wrong one: our mark does not go in the footer of the site the operator publishes. That page belongs to their readers, not to us, and branding it would be marking their work with our name. The appliance's identity belongs on the surfaces the appliance owns: the console, Webmin, the web shell, and any page the appliance itself serves. If an appliance landing page is wanted, it is a page of ours at a path or a port of ours, not a footer injected into the application's output.