Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[fix] Don't backup cron files #442
This is an alternative solution to #334
c.f. my comment here : #334 (comment) , I personally don't understand the motivation to backup cron jobs... They are neither configuration nor data, in the sense that they should be sat up by the postinstall or other relevant pieces of code...
For instance, we do not backup/restore the
If for instance we decide to change the cron job for dyndns domain for various reasons (e.g. change the frequency or optimize the way it works) then a backup before that moment, followed by a restore, will override the new cron with the old one...
Done / ready for review
How to test
Create a backup, and check that no cron job is backuped..
It's a design question between backup strategy and the regen-conf feature.
We should backup all /etc (and may be complete mysql databases unreferenced by an app)... User don't know how to add some files to backup, /etc is not so big and there is a lot of configuration (yunohost or user config).
But we are not obliged to restore all part of the system configuration. Some users wants to get a "clean" install after restoring...
About cron, I don't see where is the mechanism to regenerate cron like:
So remove this restore hook isn't enough.
It's not exact, we backup and restore it...
The regen con mechanism manages conflict with user change. If the user has change some things may be he/she wants to backup it and even restore it.
So in fact, yes, it appears that we do restore nginx configuration files. But since those are handled by the regen-conf, either : a) the regen-conf is properly reset so that those are re-written with up to date conf automatically, or b) the regen-conf is not properly reset and all restored nginx files are flagged as manually modified, and that might lead to trouble now or later.
Imho, the focus should be on restoring a clean, working setup. Restoring manually-edited configuration files, and/or files which are not handled by the regen-conf, is a hazard in the sense that we cannot ensure that it won't break the destination setups because of backward/forward-incompatible stuff...
But this whole question of backuping / restoring /etc/ as a whole is a different question so I would say it's outside of the scope here (though it's related) ...
It's the same as the mechanism that initially creates them, which might be different for each cron. But for instance,
So imho the proper solution on this is to :
Looks like the best.
I think at some point we should have a