Ignore broken resolv conf in case of use dhclient issue 2018

[jsmeix]

• Type: Minor Bug Fix / Enhancement

• Impact: Low

• Reference to related issue (URL):
  Improved setup of etc/resolv.conf in the recovery system (issue 2015) #2018 (comment)

• How was this pull request tested?
  By me on my openSUSE Leap 15.0 system

• Brief description of the changes in this pull request:
  Now build/GNU/Linux/630_verify_resolv_conf_file.sh does no longer error out
  when etc/resolv.conf has no nameserver or only loopback addresses
  and USE_DHCLIENT has a true value
  (and USE_STATIC_NETWORKING does not have a true value)
  because then etc/resolv.conf in the recovery system
  is generated anew by /bin/dhclient-script
  so that its content before does not matter.

[jsmeix]

@OliverO2 @rear/contributors
if there are no objections I would like to "just merge" it today afternoon.

[OliverO2]

@jsmeix As noted here #2018 (comment), this change would still require configuration change to resolve the issue. With this change, I would have the option of setting

• USE_RESOLV_CONF="no", or
• USE_DHCLIENT="yes"

while ReaR was working without any network-related configuration before.

[jsmeix]

@OliverO2
do you perhaps use DHCP on your original system
and that gets detected by "rear mkrescue" so that
you also get networking setup via DHCP in the recovery system?

Could you run rear -D mkrescue without USE_RESOLV_CONF="no"
and USE_DHCLIENT="yes" and attach the debug log file?
I would like to see what goes on in your particular case.

[OliverO2]

@jsmeix Yes, as I've written elsewhere, I use DHCP, and I've briefly checked that this is what happens:

2019-03-11 13:30:43.525267622 Including prep/GNU/Linux/210_include_dhclient.sh
2019-03-11 13:30:43.536177518 Running DHCP client found, enabling USE_DHCLIENT

I'm sorry, it was my understanding that this PR would only work if USE_DHCLIENT were set in the local configuration. As it now looks like that it would work with the above auto-setting of USE_DHCLIENT, it would resolve the case. I'll test that and report. (I'm a bit reluctant about posting debug logs because of sensitive information and I'm a bit short on available time this month.)

[jsmeix]

As far as I could find out
prep/GNU/Linux/210_include_dhclient.sh
is the only place where ReaR automatically determines
to use DHCP for networking setup in the recovery system
and if DHCP should be used it sets USE_DHCLIENT=y
via its dhcp_interfaces_active() function.

As far as I understand networking setup in the recovery system
skel/default/etc/scripts/system-setup.d/58-start-dhclient.sh
is the only recovery system setup script that dals with DHCP
and that script tests for USE_DHCLIENT being non-empty.

Accordingly I can currently not see how DHCP could be used
for networking setup in the recovery system without USE_DHCLIENT=y
so that I can currently not see how this pull request that does no longer
error out if is_true "$USE_DHCLIENT" could still error out when
DHCP is used on the original system...

[jsmeix]

@OliverO2
ah! - right now I noticed your
#2076 (comment)
which matches my investigation result in
#2076 (comment)
so that I also think this pull request should make it "just work" again
when DHCP is used on the original system.

For the "fun" of it:
On my openSUSE Leap 15.0 system I also use DHCP
but SUSE uses it's own kind of networking setup tool:

# ps -e | grep -Es 'dhc'
... wickedd-dhcp4
... wickedd-dhcp6

that is rightfully not detected by define_dhclients_variable() in
prep/GNU/Linux/210_include_dhclient.sh - rightfully because
we do not have Wicked support in ReaR, cf.
https://www.suse.com/media/presentation/wicked.pdf

[OliverO2]

@jsmeix I have just tested it and can confirm that the rescue system generated from an auto-detected DHCP configuration on Ubuntu 18.04.2 LTS now works out of the box (i.e. no additional configuration required). Thank you, well done!

[jsmeix]

@OliverO2
I have to thank you because your testing and your information
made me better understand how nameserver setup works in
the recovery system so that I could improve things.
Now we have (hopefully) a better behaviour in this area
where things work by explicit code (and not in a somehow
vague and obscure looking way which at least looked to me
as if things had worked before more by luck than by intention).