HOSTNAME (uppercase) exists¶

Labels: enhancement, cleanup, won't fix / can't fix / obsolete

ProBackup-nl opened issue at 2017-04-13 09:57:¶

After merging issue #1286 this enhancement beautifies the recovery environment scripting, to not run unnecessary code for:

cases where /etc/HOSTNAME does not exist
things that the operating system already has taken care of.

Target: Arch Linux
Hostname set in /etc/hostname (lowercase)
Only that /etc/hostname file present, will already set the hostname in (1) system and (2) shell for Arch Linux, without the need for this script to set any of these 2.

jsmeix commented at 2017-04-13 12:41:¶

@ProBackup-nl
according to
https://github.com/rear/rear/issues/1258#issuecomment-289167853
and
https://github.com/rear/rear/issues/1258#issuecomment-293558696
I think usr/share/rear/skel/default/etc/scripts/boot
i.e. /etc/scripts/boot in the recovery system is
only run in the recovery system when the
the sysv-compatible init process is used
in the recovery system and I asume that
in your recovery system already systemd is used
so that changes in etc/scripts/boot do not matter
in your case and in general when systemd is used.

If you nevertheless like to enhance etc/scripts/boot:
When I looked at that script during debugging
of https://github.com/rear/rear/issues/1258
I was wondering about why it uses $(uname -n)
to show the HOSTNAME value to the user
and not what it had actually set?

In other words:
After calling

hostname "$HOSTNAME"

I wonder if then

echo Hostname set to $(uname -n)

really shows the right output.
On my SLES12 system it works

# hostname testy

# hostname
testy

# uname -n
testy

but woudn't

echo Hostname set to $( hostname )

be the more straightforward way to do it?

Simply put:
I do not understand why there is the indirection of using
the "uname -n" output instead of the "hostname" output.

jsmeix commented at 2017-04-13 12:42:¶

@gdha
I would appreciate it if you coud you also have a look here.

ProBackup-nl commented at 2017-04-13 13:00:¶

I would suggest to keep $(uname -n), to rule out edge cases where anything goes wrong, that the actually outputs the value of the current hostname setting.

And I think checking for the existence of /etc/HOSTNAME is better then assuming that it is there.

gdha commented at 2017-04-18 09:20:¶

See also #1316 - it will conflict - to be decided which direction we want to take

jsmeix commented at 2017-04-18 10:02:¶

I like the simple way as in https://github.com/rear/rear/pull/1316
to have two files /etc/hostname and /etc/HOSTNAME with
same content in the ReaR recovery system.
Perhaps we should even have those two same files
in any case in the ReaR recovery system?

gdha commented at 2017-04-19 11:49:¶

@ProBackup-nl @jsmeix With pull request e27f27e 100_hostname.sh: Update comment being committed we can close this pull request in my view.

jsmeix commented at 2017-04-19 12:02:¶

Since https://github.com/rear/rear/pull/1316 is merged
both /etc/hostname and /etc/HOSTNAME exists in any case
so that this pull request in its current form with

if [[ -e /etc/HOSTNAME ]] ; then
 ...

does no longer make sense.

[Export of Github issue for rear/rear.]

#1287 PR closed: Only set host name in recovery when /etc/HOSTNAME (uppercase) exists¶