I've written a program to generate a default config.yaml file. I'm seeing that there are times when users have either manually corrupted their file themselves or that a rogue plugin has done so.
I've attached the output file here for reference which of course could be used more simply. I assume that the program above will grow in complexity.
config.yaml (1.3 KB)
Is that example config always going to be what it outputs? If so, it disables access control by default. It's also setting the release to the maintenance branch, does it always do that? Or does it detect which branch you're currently on?
Why not just remove config.yaml and set octoprint to a first run state so the user is presented with the first run wizard? Or a default octopi config (assuming you're detecting octopi vs manual installs)
No, that would be silly, right?
I envision adding some text fields, checkboxes and such. The user could then turn on the virtual printer support, add their api key, configure something like a plugin perhaps.
Ok cool, I had no way of running the actual program so was just curious.
The user could then turn on the virtual printer
heh, I made a plugin that lets me turn that on & off, as well as change octoprint between css and less, and whether it bundles assets. Would be a good addition to your thingamajig for developers who want to quickly switch between css & less, whether octoprint bundles all assets, or clears the cache.
Neat tool! One thing to note, the config.yaml also contains the salt used for the hashed user passwords, so if that's gone it's no longer possible to log in without running the first run wizard again. It might be interesting to maybe instruct the user to extract that from the file ("looks like this") or maybe even try to grep for it if the file is not completely broken. The field in question is accessControl.salt.
Also something to note, OctoPrint will automatically generate a new config.yaml when there isn't one yet. So in case of corruption just renaming/removing the broken one should get you back a working state, and I think even a possibility to reset user authentication (I might be mistaken though and will check that, and if it's not yet the case also rectify it). Of course that will mean having to set up everything again.
Thanks, didn't know that part about the salt.
What might be good is to inject an event so that upon successful startup of OctoPrint, it makes a shadow copy of the config.yaml. If it then won't come up due to a trashed config.yaml it might then offer to restore the shadow copy.
I have to say that I'm interested in how all this works. On my development rig I use lessc as a manual step but I'm assuming that it's built in there somewhere.
Ooooh. That's a neat idea! I really like it!