#1399 Issue closed: Major user input/output cleanup and improvement for ReaR 2.3¶
Labels: enhancement, cleanup, fixed / solved / done
jsmeix opened issue at 2017-06-30 11:53:¶
For ReaR 2.3 I will implement
to a reasonable initially usable extent some general
major user input/output behavioural improvements
plus a general cleanup of user input/output code
(i.e. special cases will not be implemented for ReaR 2.3).
The goal regarding input/output behavioural improvement is
to implement what is needed that ReaR can run fully unattended
but the goal is not that ReaR 2.3 will be prepared to be able to
run fully unattended in any case (cf. "no special cases" above).
A related issue regarding running ReaR unattended is
https://github.com/rear/rear/issues/1366
The goal regarding user input/output cleanup is that
for user input/output only dedicated ReaR functions
should be used so that we have a central point where
user input/output functionality is implemented and maintained.
A related issuse regarding input/output cleanup is
https://github.com/rear/rear/issues/885
It is a precondition for ReaR to run fully unattended
that needed user input values can be predefined
so that user input requests can be autoresponded.
To ensure the right autoresponse happens for each particular
user input request the new UserInput function should be used
(instead of just feeding input values into STDIN hoping
the right value arrives at each particular user input request).
See the UserInput function documentation in
https://raw.githubusercontent.com/rear/rear/master/usr/share/rear/lib/_input-output-functions.sh
jsmeix commented at 2017-06-30 12:06:¶
While I am implementing the user input/output cleanup
and improvements there could be regressions
mainly because STDOUT is redirected to the log file, cf.
https://github.com/rear/rear/issues/1398#issuecomment-311886920
jsmeix commented at 2017-07-14 10:34:¶
According to
https://github.com/rear/rear/issues/1398#issuecomment-315318878
this issue here is no longer for ReaR v 2.2 but for ReaR v 2.3.
jsmeix commented at 2017-11-10 09:30:¶
During SUSE Hack Week 16
I intend to primarily work on this issue, cf.
https://hackweek.suse.com/16/projects/major-user-input-slash-output-cleanup-and-improvement-for-rear-2-dot-3
jsmeix commented at 2017-11-15 16:49:¶
With
https://github.com/rear/rear/pull/1573
merged
"some usual" user dialogs in "rear recover" use now UserInput()
that 'rear recover' can run unattended in "some usual" cases.
jsmeix commented at 2017-11-15 16:56:¶
The next step is to use UserInput() in "some usual" user dialogs
during ReaR recovery system startup (mainly the dialog that
asks what network interface card should be used even if there
is only one network interface card).
But that could become more complicated because I cannot
"just source" usr/share/rear/lib/_input-output-functions.sh
during recovery system startup (to get the UserInput function)
because that script does not contain only function definitions
but it also contains low-level ReaR initialization code like
exit task setup and stdin/stdout/stderr redirections
which should be split from _input-output-functions.sh
cf.
https://github.com/rear/rear/issues/1251
jsmeix commented at 2017-11-17 16:02:¶
With
https://github.com/rear/rear/pull/1583
merged
the most hindering user dialog during recovery system startup
(i.e. the network MAC adresses migration dialog)
runs now by default (i.e. without an etc/rear/mappings/mac)
unattended when possible:
If there is only one old MAC and only one new MAC
then the old MAC is automatically mapped to the new one.
When there are more MACs ReaR will not blindly guess
what the right mapping could be so that in this case
by default (i.e. without an etc/rear/mappings/mac)
a user dialog is shown (as it was before).
In any case the user could and can predefine in
/etc/rear/mappings/mac what mapping should be done
during recovery system startup and a predefined mapping
was and is done automatically without a user dialog.
Accordingly the sophisticated UserInput() is not needed
in this case (i.e. for the network MAC adresses migration), cf.
https://github.com/rear/rear/issues/1399#issuecomment-344656970
jsmeix commented at 2017-11-28 10:58:¶
Sufficiently done for ReaR 2.3.
Remaining things can be fixed for ReaR 2.4 or later
as time permits and as users ask for it.
[Export of Github issue for rear/rear.]