#1251 Issue closed: Implement a proper 'init' stage

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

jsmeix opened issue at 2017-03-17 09:29:

I will implement a proper 'init' stage to clean up
the currently contradicting implementations how
ReaR initializes itself during usr/sbin/rear startup
versus what the current 'init' scripts do.

During the discussion in
https://github.com/rear/rear/issues/1229
it became clear that the current 'init' stage is
basically a quick and dirty retroactively working hack
to make things like RECOVERY_UPDATE_URL and
DRLM_MANAGED somehow work but currently it works
basically against how ReaR operates by default.

My current untested offhanded idea what kind of scripts
there should be in the 'init' stage is:

I think that in usr/sbin/rear basically all between

# Include default config ...

and

# Check for and run the requested workflow:

should be moved into the 'init' stage.

Accordingly I am thinking about to have basically
the following scripts in the 'init' stage:

init/default/120_include_basic_functions.sh
init/default/140_source_default_and_init_config.sh
init/default/160_start_logging.sh
init/default/180_set_basic_exit_tasks.sh
init/default/220_prepare_update_server_access.sh
init/default/240_update_rear_directories.sh
init/default/260_update_recovery_system.sh
init/default/280_close_update_server_access.sh
init/default/320_include_standard_functions.sh
init/default/420_prepare_config_server_access.sh
init/default/440_download_remote_config.sh
init/default/460_install_downloaded_config_files.sh
init/default/480_close_config_server_access.sh
init/default/520_source_config_files.sh
init/default/620_check_for_mandatory_stuff.sh

The current RECOVERY_UPDATE_URL stuff
would happen via the init/default/2nn_* scripts
and the current DRLM_MANAGED stuff
would happen via the init/default/4nn_* scripts.

schlomo commented at 2017-03-17 09:51:

👍 thanks a lot

jsmeix commented at 2017-03-17 12:32:

Regarding
init/default/620_check_for_mandatory_stuff.sh
cf. the related issue
https://github.com/rear/rear/issues/1233

gdha commented at 2017-03-17 12:50:

@jsmeix why not rename the scripts to more precise meaning for which part or external software these are meant for?

jsmeix commented at 2017-03-17 13:14:

My currently - perhaps overoptimistic - idea is
that I can make the scripts generically usable
so that specific external software like DRLM
only needs specific values for generically usable
config variables.

But let's try to not discuss implementation details too much
as long as I did not do any coding here.

First I need the new DRLM stuff from @didacog
so that I can better understand what DRLM needs,
then I will meditate on it (which could take infinitely ;-)
and afterwards I will do some initial coding and get
feedback from @didacog if I do it in the right way.

Cf.
https://github.com/rear/rear/issues/1229#issuecomment-287004509

I will implement it in a way so that it is useful
on its own (which I can test on my systems)
and also so that it is in particular useful
for DRLM_MANAGED=y
(which @didacog needs to test on his systems).

jsmeix commented at 2020-03-06 14:12:

I won't do that.
I have no time for cleanup without an actual benefit for the user.
I might do it when the current mess actually hurts us.


[Export of Github issue for rear/rear.]