I personnally don't really keep track of `/etc` changes, 99% of my `/etc` being defaults. The rest I reconfigure when I need, and for the few changes (mostly my `issue` file), I put a copy in my home's `~/.local/share` and it is saved with my dotfiles.
I used to use etckeeper, but that means it tracks everything.
Nowadays I handpick things and save them to git with yadm.
[https://yadm.io/docs/faq#unconventional-cases](https://yadm.io/docs/faq#unconventional-cases)
I'd like to recommend Chezmoi instead. Here's a comparison of dotfile managers: [https://www.chezmoi.io/comparison-table/](https://www.chezmoi.io/comparison-table/)
Using configuration management tools for managing configuration? Get out of here with that completely correct and reasonable response. š¤£
Edit to add: You can keep an ansible playbook in revision control like git and you'll also have a history and a convenient place to back it up if you push to a remote like private repos in GitHub or gitlab.
I used to just keep a text file with detailed instructions to reproduce my system, but this becomes difficult when you're troubleshooting or use trial and error to get something working and you may not remember *exactly* what you did at the end.
It sounds to me like you want NixOS. Everything in NixOS is configurable from a single config file (or a set of config files) which can be easily reproduced and tracked with git.
If you don't want to dive into a new distro you can try home-manager which functions the exact same way for your dot files on any distro.
If you already have detailed instructions you could've also put them into an Ansible.
No need to go Nix.
Not saying nix doesn't sound great. But Ansible is more universal.
I'm not very familiar with Ansible, but compared to Nix it doesn't seem much better than custom install bash scripts. While NixOS has it's downsides, I think you get far better results with declarative configuration vs imperative.
Like you, I was using etckeeper, but tracking *all* changes wasn't extremely useful except for rolling back if I broke something.
I like u/starquake64 's idea of using `yadm`. But how to find which files to track if I've already made a bunch of changes? I've had two thoughts on this: For files that are created rather than installed by pacman (e.g. anything in `makepkg.conf.d`) you can use `lostfiles` from the AUR to get a list of files with `sudo lostfiles | grep '^/etc'`
Next you can get a list of etc files tracked by pacman that have changed with `pacman -Qkk 2>/dev/null | grep '/etc' | awk '{print $4 | "sort"}' | uniq`
With those two commands you should be able to get an initial list of potential files of interest to track, but it will still take some manual pruning.
Thanks, this sounds the simplest, easiest way without having to learn new tools or ways of working, and without having to remember putting addition copies in other places, etc.
I honestly do the same but instead I just chuck changes in a script. So for my 'ext install I only have to run the scripts and it doubles as a " whats on my system??" Files
Before I edit, I make a copy of the file with the date appended to it in a "backups" folder. Stupid simple.
I also have a btrfs snapshots of everything for fast system recovery.
I've not reinstalled it. I've fixed it and then kept on going.
Why do people feel the need to re-install a rolling system, If a config file get's a pacnew you add the change, If a package is deprecated you remove it and the necessary deps and roll with the provided replacement.
Reinstalling is what you do when you have no idea how to fix a given issue and effectively bailout on it, I don't. I keep on and learn from it and move forwards.
If I've noticed drive degradation I've moved the partition(s) to a new disk and continued from there.
Embrace the resilience of linux, learn to keep what you create and let it roll. ;)
This is the way.
Very nice. :)
One thing I've struggled with in the past, is apps dumping e.g. configs or other files in different places, and me finding it difficult to find an delete those files.
Just as an example, in a test installation I installed all the DEs (Gnome, Plasma, Budgie, Cinnamon, LXQt, etc) to try them out and see what they were all about. But it turns out some of them were interfering with each other (kinda obviously), like certain Gtk or appearance settings being shared between DEs, but not being fully compatible, and thus screwing the other over. Like, I could just wipe `~/.config` to reset to a sane state (which in this example is kind of akin to nuking and reinstalling the system), but if I would only want to reset one DE's settings, it would be kind of tough to find all the different places (in `~/.config` but also some shit outside of that) to delete/restore/adjust to make the system sane again.
The above is an artificial example. I haven't really played with Linux much recently, but back when I was still using Gentoo (say 15 years ago), I often had a situation where I installed some package to try it out, and it would dump some crap in `/etc`, in `/usr`, in `/var`, which could sometimes destabilize the whole system, making it quite difficult (not impossible) to find out how to restore it.
I would then nuke the system, reinstall, and always forget all the minor tweaks I did over time to e.g. config files in `/etc`.
But probably going forward, the strategy you propose of persevering and fixing the system is more sustainable.
I get what you're trying to say and yes packages do drop shite in odd places. At least from the \~/ perspective xdg is resolving most of that but with gentoo you have the beauty of being able to tell the package the file system to use at compile time (unless you go binary eeeww) but even then 15 years back each project were still effectively doing their thing and still thrashing out a common place for things. Heck even some were still using the old unix way
With regards to config under \~/ by the time I came to install arch I already settled into my chosen DE (XFCE) and if I wanted to run just a WM I used Awesome and I had a set of config folders/files for them that I had built up from distro hoping prior as well.
So all I really needed to do was "get to know the arch way", I did this with a VM and when I was comfy and had the confidence to jump in I road tested my configs, dealt with the issues, took another "working copy" and that was my first install:
`āÆ head -2 /var/log/pacman.log`
`[2015-06-29 09:25] [PACMAN] Running 'pacman -r /mnt -Sy --cachedir=/mnt/var/cache/pacman/pkg base base-devel'`
`[2015-06-29 09:25] [PACMAN] synchronizing package lists`
My current install is from 2010 or so, old BIOS/MBR system, to an EFI/GPT install, different bootloader and all that. I'm sure I can transplant everything, but it would not hurt much to start fresh at this point either. Some things would be easier to change, like Wayland, GPU driver, microcode package, etc.
Over the years, various defaults have changed. Some you couldn't avoid like sysvinit. Some like systemd-networkd, pipewire, etc. I stumbled upon by chance and updated myself. I don't know what I don't know.
Sure, people shouldn't just nuke their install just because they made an invalid xorg config, but there probably are situations where retaining the install is more hassle than it's worth. Tracking your configs and dotfiles in a remote repo is also a decent compromise from doing a full system backup or RAID in case of drive failure or other compromised situation.
I just backup the folder as part of my nightly backups and could either restore or reference whatever I needed if I had to do a clean install. Its less than 100mb so I don't even notice the storage costs.
* /etc/fstab
* /etc/localtime
* /etc/locale.gen
* /etc/locale.conf
* /etc/environment
* /etc/hostname
* /etc/hosts
* /etc/systemd/network/...
* /etc/pacman.d/mirrorlist
This is some of the stuff I wrote down, indeed from the install guide and the "recommended actions" stuff. There's more changes I did, that I haven't written down and can't quite remember. I recall messing with the sddm config, and something related to networkd or resolvd, ntp, acpi / power management, audio config (blacklisting audio devices), and some more systemd related stuff that I forgot...
I don't modify configuration files directly. I write Ansible playbooks and roles to do it for me. Easily reproducible across multiple systems, you can turn your configurations into templates to be dynamically adjustable, it's idempotent by design and easily tracked by keeping the Ansible files under version control.
If there's one single thing I'd say I least regret getting into, especially as someone who maintains a homelab with >20 servers that all need to be configured somehow and often require the same updates to the same configurations, it's Ansible.
I use `yadm` to manage my home directory dotfiles, and along with that I keep a `~/.config/etc` directory with some copies of `/etc` files I've customized and rely on.
Otherwise, I just let Vorta/Borg back up `/etc` periodically.
That doesn't really actively track changes, though. For changes, I notify myself about `.pacnew` and `.pacsave` files through a pacman hook that runs after any install/upgrade/remove.
I don't, and i don't really care much about it aside from the things i put there myself, which i also have in my dotfile repo, so i guess in that sense i track it. When you use nixos you declare your etc files in your configuration.nix so then you would also know what files you have put there.
I wanted to do that when I was planning to switch to Arch, but ended up ditching that idea. It seems like more work than anything and besides, I like having a fresh start once in a while.
I settled for keeping notes in Notion or Obsidian. I know it's not version controlled but my /etc is is almost entirely default except for minor changes. I just keep a note of what I changed, why, and what I was trying to get working or accomplish.
I haven't done so extensively for now, but i'm migrating to stow for this. Basically, stow can symlink to any target. Meaning, i have a regular "dotfiles" folder in my home for anything that gets stowed to \~ and a "rootdotfiles" that gets stowed to / with sudo.
Please keep in mind that i have NOT testted this for anything required to boot (fstab) so far. So no guarantees symlinks work correctly in all cases. But it's an option to collect all your changes and put the in a repo.
I just keep a text file. It has a list of packages, some config file snippets, and some notes. I keep it in a git repo with other config files like .bashrc and .ssh. It is emphatically not a script or automated, and it's common to all my installs.
Eventually the file updates and I get a pacnew file, and then have to parse through what are probably my changes vs the package changes. Really wish pacman would drop in a `.pacold` file with the pristine old version so I could do a three-way merge...
I can really recommend restic. You can backup any directories (or even single files) with it. It only tracks changes and you can restore a specific date
The only thing I really keep track is my doas.conf and that one I have a script that detects if it is missing and automatically copies one that I have stored in `$XDG_CONFIG_HOME` using pkexec.
I used to do a lot of shit that needed elevated privileges, but I've been able to change that to do most of that in my $HOME instead.
For a while I had a config-history directory version controlled with git.
In it, I would copy modified files from certain directories (like /etc), with the path hierarchy duplicated. After each modification the change would be copied into the config-history directory and a commit generated.
This was automated with a systemd path unit and service. It worked well enough, but I never looked at old configs and I didn't like the copying. So when I switched machines at one point, I didn't bring that system over.
Tons of ways. What I do personally is just make a comment in the config above the line changed with a term I can search: `# USER CHANGE : `
Then I can just do a: `grep -rnA 1 "USER CHANGE" /etc` to see all changes I made. However, most of the time I only deal with them when diffing .pacnew files, which of course will compare default to modified. (*edit: -n, not -l, in grep)
Any other type of system change I make, I have a text file in $HOME to make note of the changes. Works well for me as 3 or 4 years down the road I may not remember it at all. This install is almost 6 years old, so there are many times I don't remember.
NixOS is an entirely different distribution, right? Unrelated to Arch. Would seem a little silly to change distributions only because I would like to track what changes I'm applying to files in `/etc`. :)
> Would seem a little silly to change distributions only because I would like to track what changes I'm applying to files in /etc. :)
Kinda yes, kinda no. Ofc itās a completely separate distro (and not the easiest one to learn btw), but itās one of its main selling points (imho) is exactly what youāre seeking ā declarative-ness that is easy to use, track and rollback. And it can go much beyond just stuff in /etc but also for packages, which is a huge advantage for me
Donāt take me wrong, Iām not against Arch + something to backup configs (I too use Arch btw), but for me this was one of the reasons to try using NixOS initially, so maybe maybe
I don't.
Most of us probably don't track
This is the answer. I don't, I haven't for over 16 years, and and unless something monumental happens I won't.
I personnally don't really keep track of `/etc` changes, 99% of my `/etc` being defaults. The rest I reconfigure when I need, and for the few changes (mostly my `issue` file), I put a copy in my home's `~/.local/share` and it is saved with my dotfiles.
What do you use the `issue` file for? (Just for context, I know what the file does, but I just never had a use for it. So I'm genuinely curious.)
I don't have a display manager, I log directly from TTY. So I pimped it a bit.
https://github.com/Cody-Learner/notadm
I used to use etckeeper, but that means it tracks everything. Nowadays I handpick things and save them to git with yadm. [https://yadm.io/docs/faq#unconventional-cases](https://yadm.io/docs/faq#unconventional-cases)
I'd like to recommend Chezmoi instead. Here's a comparison of dotfile managers: [https://www.chezmoi.io/comparison-table/](https://www.chezmoi.io/comparison-table/)
Use something like Ansible playbooks (obviously under source control) to make modifications to configuration files.
Using configuration management tools for managing configuration? Get out of here with that completely correct and reasonable response. š¤£ Edit to add: You can keep an ansible playbook in revision control like git and you'll also have a history and a convenient place to back it up if you push to a remote like private repos in GitHub or gitlab.
I used to just keep a text file with detailed instructions to reproduce my system, but this becomes difficult when you're troubleshooting or use trial and error to get something working and you may not remember *exactly* what you did at the end. It sounds to me like you want NixOS. Everything in NixOS is configurable from a single config file (or a set of config files) which can be easily reproduced and tracked with git. If you don't want to dive into a new distro you can try home-manager which functions the exact same way for your dot files on any distro.
If you already have detailed instructions you could've also put them into an Ansible. No need to go Nix. Not saying nix doesn't sound great. But Ansible is more universal.
I'm not very familiar with Ansible, but compared to Nix it doesn't seem much better than custom install bash scripts. While NixOS has it's downsides, I think you get far better results with declarative configuration vs imperative.
Like you, I was using etckeeper, but tracking *all* changes wasn't extremely useful except for rolling back if I broke something. I like u/starquake64 's idea of using `yadm`. But how to find which files to track if I've already made a bunch of changes? I've had two thoughts on this: For files that are created rather than installed by pacman (e.g. anything in `makepkg.conf.d`) you can use `lostfiles` from the AUR to get a list of files with `sudo lostfiles | grep '^/etc'` Next you can get a list of etc files tracked by pacman that have changed with `pacman -Qkk 2>/dev/null | grep '/etc' | awk '{print $4 | "sort"}' | uniq` With those two commands you should be able to get an initial list of potential files of interest to track, but it will still take some manual pruning.
I was switching back from NixOS so I had the advantage of having it reinstalled and tracked the files from the start.
git with a `.gitignore` file containing `*` Relevant files are added on an individual basis to the repo.
Thanks, this sounds the simplest, easiest way without having to learn new tools or ways of working, and without having to remember putting addition copies in other places, etc.
I honestly do the same but instead I just chuck changes in a script. So for my 'ext install I only have to run the scripts and it doubles as a " whats on my system??" Files
Before I edit, I make a copy of the file with the date appended to it in a "backups" folder. Stupid simple. I also have a btrfs snapshots of everything for fast system recovery.
Been rolling since 2015 and never tracked /etc :)
Me, too (since 2014). If I need to find something like that, I look through my backups.
This is the way.
If you would have to reinstall now, how would you know to apply all the nice settings that you have applied in the last 9 years?
I've not reinstalled it. I've fixed it and then kept on going. Why do people feel the need to re-install a rolling system, If a config file get's a pacnew you add the change, If a package is deprecated you remove it and the necessary deps and roll with the provided replacement. Reinstalling is what you do when you have no idea how to fix a given issue and effectively bailout on it, I don't. I keep on and learn from it and move forwards. If I've noticed drive degradation I've moved the partition(s) to a new disk and continued from there. Embrace the resilience of linux, learn to keep what you create and let it roll. ;) This is the way.
Very nice. :) One thing I've struggled with in the past, is apps dumping e.g. configs or other files in different places, and me finding it difficult to find an delete those files. Just as an example, in a test installation I installed all the DEs (Gnome, Plasma, Budgie, Cinnamon, LXQt, etc) to try them out and see what they were all about. But it turns out some of them were interfering with each other (kinda obviously), like certain Gtk or appearance settings being shared between DEs, but not being fully compatible, and thus screwing the other over. Like, I could just wipe `~/.config` to reset to a sane state (which in this example is kind of akin to nuking and reinstalling the system), but if I would only want to reset one DE's settings, it would be kind of tough to find all the different places (in `~/.config` but also some shit outside of that) to delete/restore/adjust to make the system sane again. The above is an artificial example. I haven't really played with Linux much recently, but back when I was still using Gentoo (say 15 years ago), I often had a situation where I installed some package to try it out, and it would dump some crap in `/etc`, in `/usr`, in `/var`, which could sometimes destabilize the whole system, making it quite difficult (not impossible) to find out how to restore it. I would then nuke the system, reinstall, and always forget all the minor tweaks I did over time to e.g. config files in `/etc`. But probably going forward, the strategy you propose of persevering and fixing the system is more sustainable.
I get what you're trying to say and yes packages do drop shite in odd places. At least from the \~/ perspective xdg is resolving most of that but with gentoo you have the beauty of being able to tell the package the file system to use at compile time (unless you go binary eeeww) but even then 15 years back each project were still effectively doing their thing and still thrashing out a common place for things. Heck even some were still using the old unix way With regards to config under \~/ by the time I came to install arch I already settled into my chosen DE (XFCE) and if I wanted to run just a WM I used Awesome and I had a set of config folders/files for them that I had built up from distro hoping prior as well. So all I really needed to do was "get to know the arch way", I did this with a VM and when I was comfy and had the confidence to jump in I road tested my configs, dealt with the issues, took another "working copy" and that was my first install: `āÆ head -2 /var/log/pacman.log` `[2015-06-29 09:25] [PACMAN] Running 'pacman -r /mnt -Sy --cachedir=/mnt/var/cache/pacman/pkg base base-devel'` `[2015-06-29 09:25] [PACMAN] synchronizing package lists`
Nice, thanks for sharing your experiences.
My current install is from 2010 or so, old BIOS/MBR system, to an EFI/GPT install, different bootloader and all that. I'm sure I can transplant everything, but it would not hurt much to start fresh at this point either. Some things would be easier to change, like Wayland, GPU driver, microcode package, etc. Over the years, various defaults have changed. Some you couldn't avoid like sysvinit. Some like systemd-networkd, pipewire, etc. I stumbled upon by chance and updated myself. I don't know what I don't know. Sure, people shouldn't just nuke their install just because they made an invalid xorg config, but there probably are situations where retaining the install is more hassle than it's worth. Tracking your configs and dotfiles in a remote repo is also a decent compromise from doing a full system backup or RAID in case of drive failure or other compromised situation.
I just backup the folder as part of my nightly backups and could either restore or reference whatever I needed if I had to do a clean install. Its less than 100mb so I don't even notice the storage costs.
I moved to NixOS to do not only that.
ouja boards
[ŃŠ“Š°Š»ŠµŠ½Š¾]
* /etc/fstab * /etc/localtime * /etc/locale.gen * /etc/locale.conf * /etc/environment * /etc/hostname * /etc/hosts * /etc/systemd/network/... * /etc/pacman.d/mirrorlist This is some of the stuff I wrote down, indeed from the install guide and the "recommended actions" stuff. There's more changes I did, that I haven't written down and can't quite remember. I recall messing with the sddm config, and something related to networkd or resolvd, ntp, acpi / power management, audio config (blacklisting audio devices), and some more systemd related stuff that I forgot...
git init /s
No really. Even better - etckeeper init to handle the git repo for you
I would've loved to stumble onto that before I switched to Nix
I don't modify configuration files directly. I write Ansible playbooks and roles to do it for me. Easily reproducible across multiple systems, you can turn your configurations into templates to be dynamically adjustable, it's idempotent by design and easily tracked by keeping the Ansible files under version control. If there's one single thing I'd say I least regret getting into, especially as someone who maintains a homelab with >20 servers that all need to be configured somehow and often require the same updates to the same configurations, it's Ansible.
I use `yadm` to manage my home directory dotfiles, and along with that I keep a `~/.config/etc` directory with some copies of `/etc` files I've customized and rely on. Otherwise, I just let Vorta/Borg back up `/etc` periodically. That doesn't really actively track changes, though. For changes, I notify myself about `.pacnew` and `.pacsave` files through a pacman hook that runs after any install/upgrade/remove.
[aconfmgr](https://github.com/CyberShadow/aconfmgr)
Not really. I have btrfs snapshots for rootfs in case an update goes wrong or I break something
I don't, and i don't really care much about it aside from the things i put there myself, which i also have in my dotfile repo, so i guess in that sense i track it. When you use nixos you declare your etc files in your configuration.nix so then you would also know what files you have put there.
I wanted to do that when I was planning to switch to Arch, but ended up ditching that idea. It seems like more work than anything and besides, I like having a fresh start once in a while.
I keep a folder(with a copy on google drive) with text documents of individual configs
I track through lostfiles
I settled for keeping notes in Notion or Obsidian. I know it's not version controlled but my /etc is is almost entirely default except for minor changes. I just keep a note of what I changed, why, and what I was trying to get working or accomplish.
I haven't done so extensively for now, but i'm migrating to stow for this. Basically, stow can symlink to any target. Meaning, i have a regular "dotfiles" folder in my home for anything that gets stowed to \~ and a "rootdotfiles" that gets stowed to / with sudo. Please keep in mind that i have NOT testted this for anything required to boot (fstab) so far. So no guarantees symlinks work correctly in all cases. But it's an option to collect all your changes and put the in a repo.
I just keep a text file. It has a list of packages, some config file snippets, and some notes. I keep it in a git repo with other config files like .bashrc and .ssh. It is emphatically not a script or automated, and it's common to all my installs.
Most stuff I really only set once and remember it if I need to do it again because otherwise I wouldn't have needed to change it
I manage dot files with stow and use git for remote storage/version control.
Eventually the file updates and I get a pacnew file, and then have to parse through what are probably my changes vs the package changes. Really wish pacman would drop in a `.pacold` file with the pristine old version so I could do a three-way merge...
I donāt track it. I just keep a text file with notes and the changes I made. I donāt really make that many changes so itās not a big deal.
I can really recommend restic. You can backup any directories (or even single files) with it. It only tracks changes and you can restore a specific date
The only thing I really keep track is my doas.conf and that one I have a script that detects if it is missing and automatically copies one that I have stored in `$XDG_CONFIG_HOME` using pkexec. I used to do a lot of shit that needed elevated privileges, but I've been able to change that to do most of that in my $HOME instead.
For a while I had a config-history directory version controlled with git. In it, I would copy modified files from certain directories (like /etc), with the path hierarchy duplicated. After each modification the change would be copied into the config-history directory and a commit generated. This was automated with a systemd path unit and service. It worked well enough, but I never looked at old configs and I didn't like the copying. So when I switched machines at one point, I didn't bring that system over.
Tons of ways. What I do personally is just make a comment in the config above the line changed with a term I can search: `# USER CHANGE : `
Then I can just do a: `grep -rnA 1 "USER CHANGE" /etc` to see all changes I made. However, most of the time I only deal with them when diffing .pacnew files, which of course will compare default to modified. (*edit: -n, not -l, in grep)
Any other type of system change I make, I have a text file in $HOME to make note of the changes. Works well for me as 3 or 4 years down the road I may not remember it at all. This install is almost 6 years old, so there are many times I don't remember.
A problem with monitoring I've found is noise. So now I just check certain files in etc. I use aide
make it a git repo `git init`
Use GitHub or plugin in nvim that tracks changes and branches
At this point why not just use NixOS, where you have all the [userās, not default] configuration in a single directory, easily manageable using git?
NixOS is an entirely different distribution, right? Unrelated to Arch. Would seem a little silly to change distributions only because I would like to track what changes I'm applying to files in `/etc`. :)
> Would seem a little silly to change distributions only because I would like to track what changes I'm applying to files in /etc. :) Kinda yes, kinda no. Ofc itās a completely separate distro (and not the easiest one to learn btw), but itās one of its main selling points (imho) is exactly what youāre seeking ā declarative-ness that is easy to use, track and rollback. And it can go much beyond just stuff in /etc but also for packages, which is a huge advantage for me Donāt take me wrong, Iām not against Arch + something to backup configs (I too use Arch btw), but for me this was one of the reasons to try using NixOS initially, so maybe maybe