I believe that the etckeeper is a git repo if that is any help.
Yes it is so you just from previous commits. If you donât know how to use git it would be worth reading up on how it works https://etckeeper.branchable.com/ may give you some clues on how to use it. But you can just use standard git commands to restore the the file e.g git restore postfix/virtual.db things to bare in mind are run git in the etc directory and be aware the file you want to restore is not the latest commit so you may want to review the git history to pin point the exact revision you wish to restore
No. config-system does initial configuration of services, it does not spawn missing data out of thin air.
If your etckeeper git repo is valid, you can restore the lost files.
If notâŠyou probably need to disable mail for each user and then re-enable it. I think? It would be much better to restore the file from a backup of some sort. If you donât have backups, but you have a valid git repo managed by etckeeper, thatâs the best option.
Please keep backups! Iâm begging!
@Ilia implemented a virtualmin command for interacting with the etckeeper git repo, but I donât remember what itâs called and canât find it in a quick search (and I find it more confusing than using git directly, as Iâm familiar with git).
With it being so useful, do you think a wiki page explaining how to practically use etckeeper could be made?
root@debian13-pro:~# virtualmin | grep Git
list-config-backups Lists configuration file backups from Git
restore-config-backups Restores configuration file backups from Git
Perhaps the command descriptions could be clearer though. I used Git rather than etckeeper in the description because this feature can work with just any .git/ directly, without requiring etckeeper.
Youâre right. Iâll work on improving the documentation. Itâs actually quite straightforwardâmuch simpler than using Git directly for this specific scenario.
etckeeper is just a set of tools to commit /etc (or anything) automatically to git.
You donât really interact with etckeeper. You interact with git. If you know git, you know how to interact with the etckeeper-managed /etc git repo.
And, everybody should learn how to use git. Itâs the most valuable software in the world. (Revision control, in general, is the most important tool for anyone who uses computers seriously, and git is by far the dominant revision control system. Though there are other options, and etckeeper works with some other options, I think. Mercurial is a respectable competitor. But, just learn git, youâll be fine.)
But, we certainly should have good documentation for every virtualmin command.
Ilia, itâs weird to call a git repo config-backups. Theyâre not backups. Theyâre revisions.
Yes, itâs on my to-do.
Iâm not sure what else to call it, since technically it provides a backup and restore feature.
Though, Iâm open to suggestions, but it isnât clear what to do with it now because someone may already be using these command names.
I mean, itâs revision control, so the language is ârevisionâ rather than âbackupâ (âhistoryâ is another revision control word, as is âlogâ, and making that info accessible is good). We have backup tools, already, which use a different mechanism and map to what most people think of when they think âbackupâ.
Iâve been meaning to build a GUI for git history. For a while I was thinking weâd integrate something like Gitea or Forgejo or similar, which is a lightweight self-hosted Github-like experience, but thatâs overkill for this specific purpose. I think we probably just want a repo browser with the ability to pull out specific revisions of files. i.e. âI accidentally deleted a file, letâs get the most recent revision of itâ or âI broke Apache, let me roll back to the last working configurationâ.
Edit: To be clear, someone who knows a little git can already do these things. So learning a little git is a great idea for everyone.
Are you suggesting it might be better to name them list-config-revisions and restore-config-revisions instead?
Iâm saying itâs more accurate and less confusing than calling it backups, especially since we have several backup mechanisms in Virtualmin and Webmin. The naming currently sounds like it is related to Webminâs configuration file backups.
Alright, agreed! I will fix that! Thanks!
Done!
From the restore doc, this feels like itâs missing the point of having everything in revision control.
âIf the target is /etc, the selected files are restored directly to the live system. This is useful for rolling a module or file back to an earlier state, but it should be used carefully because it overwrites the current files.â
If the working directory (/etc) is clean and everything is committed, you can pull an older revision and then go back to the newer revision. You can also compare across revisions using git diff, without having to restore to another date-stamped location and look at them side by side or whatever.
Seems like itâs hiding the benefits of revision control to treat revisions as files.
I think users would be better served by knowing how to use git directly. To get all the benefits of git, weâd need to wrap all the git commands and features in Virtualmin commandsâŠbut, git is already there, and already well-documented. It is, admittedly, confusing for new users. But, maybe we ought to also provide a few examples of using git to interact with files in /etc as managed by etckeeper.
Of course, I probably should get around to making a GUI, as well, that allows visually browsing files and revisions similar to how Github/Gitlab and the like do it.
Alright, it should be better now with the latest change.
Thanks, Iâll add it to my to-do list, yet probably for Virtualmin Pro users only.
As a amateur user, I would pull the file of the server and etckeeper and then do a file comparison off the server before making changes.
Do you mean you donât need a UI for this?