I’m curious if there is a way to have a fallback config.json that is used if the main config.json has been misconfigured.
I’m nervous about making changes to this file on deployed devices and would like for a way to ensure I never lose connection to the device.
Hello @mamoen
Welcome to the balena Forums.
We would normally recommend that you avoid making changes directly to config.json unless absolutely necessary. Please could you describe the configuration changes that you wish to make so that we can advise you of any alternative methods.
Regards - Mark
I wanted to have a way to add more SSH keys, the easiest way was to mount the boot partition as a volume in a container and then have a service I could send new keys to, this would then change the config.json using jq and then reboot the device.
However I’m concerned if something happens during this write I will end up with a broken config.json file or the service.
Hi,
your concern is indeed correct, unfortunately we have no backup config.json because the file is not intended to be written very often.
If you really need to perform config.json updates, which I understand for the SSH keys, I would suggest the configizer project, which is intended for doing this remotely as safely as possible: GitHub - balena-os/configizer: Safe(r) balenaOS config.json updates remotely
Amazing, thanks for the link @mtoman
I’m curious if its on the roadmap to make some kind of “last known good state” for the config.json file?
That upon boot it checks it’s VPN connection and if stable it considers the new json file safe (obviously this is a very simple check, but would at least avoid the potential for completely losing connection to a in the field device), and if it’s can’t connect it rolls back to the previous known good state of the config.json file
Hi, thanks for the feedback. Manual modifications to config.json are discouraged, and we are working towards exposing all of its configuration to the dashboard. Even before that, modifications should only happen via safe mechanisms as the balena CLI or the configizer tool.
So the roadmap for config.json is really to make all configuration supervisor managed and not rely on config.json
@alexgg can you give an update on this?
Hi Andre, what’s the use case you are looking for an update on exactly? This thread started by a concern that modifying config.json in the field might have unexpected consequences. The replies were along the lines of please don’t do this, use the supervisor API or the configizer tool to configure your device. I also pointed out that the intention is to deprecate the configizer tool as the supervisor gains functionality.
What’s your particular concern about?