Upgrade command needs to get the existing that FQDN

[rjmateus]

During installation, the user can provide an FQDN to be used as the server name and to generate the certificates. If the FQDN is not passed, it will call the command hostname -f [1]

The upgrade command doesn't receive the FQDN as a parameter, but it needs the FQDN to compute the certificates. Since not FQDN is passed, it always use the command call hostname -f, which may not return the wanted FQDN to use.
It's used in the context of DB certificate generation [2] (needed also for MLM 5.1) but also in the context of the new TFTP container [3] (needed for 5.2)

The update process must use the same FQDN as the one that was installed before. We must improve our code base for the upgrade process to look for the configured FQDN and use it, instead of collecting it using the cmd call.

The alternative solution (but not user-friendly) of allowing the user to pass the FQDN when calling the upgrade would be error-prone and redundant, since we already have that value on the rhn.conf, and the same value must be used.

[1] https://github.com/uyuni-project/uyuni-tools/blob/main/shared/utils/utils.go#L418-L433
[2] https://github.com/uyuni-project/uyuni-tools/blob/main/mgradm/shared/podman/podman.go#L441
[3] https://github.com/uyuni-project/uyuni-tools/blob/main/mgradm/shared/podman/podman.go#L504

[mbussolotto]

after the last refactoring, we have

uyuni-tools/mgradm/shared/templates/serverEnvironmentTemplate.go

Line 20 in 763789b

UYUNI_HOSTNAME={{ .Fqdn }}

. So I think to the point is to set this value properly during the installation and then be sure that this is the only one used

[rjmateus]

I'm not sure, since the FQDN looks to be used also to generate the DB certificate when upgrade from 5.0 to 5.1. Would the change you mentioned also handle this scenario?

[rjmateus]

bug: https://bugzilla.suse.com/show_bug.cgi?id=1262113

[aaannz]

It's not that easy, as that env file is designed to be not completely persistent and for example for upgrades it currently only modifies debug settings and the rest is discarded.

IMO we can enhance podman inspector to get java.hostname from the rhn.conf and automatically use that for fqdn everywhere.

[mbussolotto]

we already have that values ad fqdn with inspect command

uyuni-tools/shared/utils/containerinspector.go

Lines 22 to 24 in 763789b

	types.NewInspectData(
	"fqdn",
	`sed -n '/^java\.hostname/{s/^java\.hostname[[:space:]]*=[[:space:]]*\(.*\)/\1/;p}' /etc/rhn/rhn.conf || true`),

(also in 5.1)

[aaannz]

Right! So we need to adapt https://github.com/uyuni-project/uyuni-tools/blob/main/shared/utils/utils.go#L418 to use it or instead of using that function, use inspect results in https://github.com/uyuni-project/uyuni-tools/blob/main/mgradm/shared/podman/podman.go#L346

[rjmateus]

Thank you for looking at it. Looks to me that the right approach you be to use fqdn from the inspect when we are running an upgrade. That should BE the most straitforward.