Restoring emptied /etc/postfix/virtual using rebuild-map

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

1 Like

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.

1 Like

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.)

1 Like

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.

1 Like

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.

1 Like

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!

1 Like

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.

1 Like

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.

1 Like

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?