The GRR server's handling of misnamed config options needs to be more user friendly

Currently, if an unrecognized config option is provided in the writeback file, restarting the GRR server components causes the writeback to be renamed by attaching a ‘.bak’ suffix. After this happens though, the server components cannot start, because the writeback is not initialized:

Traceback (most recent call last):
  File "/usr/share/grr-server/bin/grr_console", line 11, in <module>
    sys.exit(Console())
  File "/usr/share/grr-server/local/lib/python2.7/site-packages/grr_response_server/distro_entry.py", line 14, in Console
    flags.StartMain(console.main)
  File "/usr/share/grr-server/local/lib/python2.7/site-packages/grr_response_core/lib/flags.py", line 147, in StartMain
    main(sys.argv)
  File "/usr/share/grr-server/local/lib/python2.7/site-packages/grr_response_server/bin/console.py", line 107, in main
    server_startup.Init()
  File "/usr/share/grr-server/local/lib/python2.7/site-packages/grr_response_server/server_startup.py", line 88, in Init
    raise RuntimeError("Config not initialized, run \"grr_config_updater"
RuntimeError: Config not initialized, run "grr_config_updater initialize". If the server is already configured, add "Server.initialized: True" to your config.

[mbushkov]

@panhania - it’s a valid point. However, this flag has a default true value for server components and a default false value for the client component. If allow_missing_config_definitions flag is introduced, you’ll end up in the opposite situation: it will have to default to True on the clients and to False on the server components. While this would be an improvement, I’m not sure it’s worth it, given that it’s one of the rare command line flags that’s actually widely used (because of how Docker and GRR service files are written) - so the change would either require everybody to migrate or us to support both flags at the same time for a while.

At the very least I’d keep 2 issues separate: renaming the flag and ensuring the reasonable default behavior on server/client components.

[panhania]

Since negative flags with true value as default are counter-intuitive (at least for me), I would also suggest renaming the flag to --allow_missing_config_definitions and reverse the behaviour.