Do not accept hostname from DHCP, use static one

[mnowaksuse]

POO#15740

On Xen under svirt backend we don't have user-mode networking we have
for KVM and Qemu. If networking.service is restarted (explicitly or by
system restart) on Xen the system accepts new hostname different from
the static one.

This change prevents system to set as a hostname whatever comes from
DHCP and sticks with static hostname. Otherwise yast2_lan test fails:
https://openqa.suse.de/tests/692200.

Now hostname --fqdn fails on all systems but that's expected as domain
name is not set.

Verification runs:
Xen: http://assam.suse.cz/tests/4578
KVM: http://assam.suse.cz/tests/4575
Qemu: http://assam.suse.cz/tests/4577

[mnowaksuse]

Related needle: https://gitlab.suse.de/openqa/os-autoinst-needles-sles/merge_requests/282.

[okurz]

I am not sure about this one. Don't we want to test how the hostname is set by DHCP or does it not make sense to test this and why?

[mnowaksuse]

My sense is that we avoid looking at hostname, if we feel it may came from DHCP, where possible - be it in needle matching in YaST, or on virtual console prompt -, because there's new name for every new VM. Couldn't find a test where we actually test hostname sent from DHCP.

I don't know why setting static hostname, then restarting network.service, and then getting that hostname from DHCP works for Qemu and KVM (both use usermode networking), but 1) looks like a hack to me, 2) it does not work with bridged interfaces. Can't use user mode networking on Xen.

Other approaches:

1. Configure Xen host to provide similar behavior to Qemu user mode networking. - No idea how.
2. Keep hostname.pm intact, but change needles for Xen and treat it as a special case.

(Though I prefer my original approach.)

[dzedro]

I was thinking why is this not Xen/svirt specific, I had no good arguments to not set static hostname, so I didn't comment, but with this behavior we will avoid default settings.

[dzedro]

e.g. with this all PUBLISH_HDD_1 will have static hostname, "custom setup".

[okurz]

yes, does not sound like a good idea

[mnowaksuse]

This

assert_script_run("sed -ie '/DHCLIENT_SET_HOSTNAME=/s/=.*/=\"yes\"/' /etc/sysconfig/network/dhcp");

should avoid that "custom setup" issue as new SUT boot or later yast2 lan run would re-set to retrieving hostnames from DHCP.

[dzedro]

exactly yast_lan is not running when disk image is created e.g. https://openqa.suse.de/tests/692578

[dzedro]

I see you added that "yes" part, but now it is not "Do not accept hostname from DHCP, use static one" anymore :)

[mnowaksuse]

This is somewhat messy approach. I should rather come up with different solution.