To manage the 3 machines (laptops) I have home, I am planning to create a package.
This would bear dependencies, as a meta package, but also the configuration options that I would improve over time.
1. Is a meta-config-package that a good way to manage multiple machines ?
I did not find anything anywhere of someone doing that.
But I think it is the simplest when one finds a new software I want on all machines.
- one just adds the new package as a dependency and rebuild the configuration package (one machine bearing a local repo).
- when other machines upgrade periodically, it would propagate that simply.
At initial installation, one would add the package inside the pacstrap list and it may even autoconfigure the system instead of a script.
So why not ?
Or any other better solution to manage multiple machines ?
2. Concerning configuration files updates, how to handle that ?
Let's say that I discover a new setting that improved performance or security etc, or modified the IP on a hosts file.
I would need to propagate that.
I see that including in "backup=" I can have pacman create .pacsave or .pacnew depending.
However, if I want to append or modify one setting line in a defined file.
i can easily create a diff for it. But diffs are applied inside the package at buidling.
I do not see any way to handle merging changes in a nice way.
So I could perhaps have one .diff file in the package that the ".install" would call ?
or any better idea ?
or am I just insane and there is a way for pacman to handle merging the differences ?!
Thanks in advance !
By far the simplest option is to only have one machine to manage in the first place. I would highly recommend doing this if it is an option.
If that isn't an option, "meta-packages" do work (albeit awkwardly). I have my meta-PKGBUILDs on github.
Issues are package removal (not automatic unless you also add a "conflicts" to your meta-package) and managing configuration files.
I still don't have a good solution for managing configuration files; essentially, you can't do that with pacman.
The most reasonable idea I have right now is to use a tool I wrote called <code>patchman</code>, or maybe put patch files into a specific directory and use a couple of hooks to remove the old patch and reapply the new patch whenever the target file or the patch file changes.
Last edited by pypi (2017-04-21 09:08:57)
Thanks a lot for your reply. I'll check our your PKGBUILDS.
Yes, I suspected that pacman would not handle that directly since I could not find anything.
"Unfortunately" I have a machine per person, so would rather want to avoid manual configuration on all (even though more for the challenge, it is not a 100 person business either...).
I found suggestions in managing /etc as a git repo instead of multiple diff files.
Does the following make sense:
1. have a "master" machine where I undo the changes that would have erased my parameters at package updates thanks to git.
2. have a /etc managed by git on all other machines.
2. have the package that will include:
a. The dependancies that I want installed on the system,
it could also include files like ssl certificates etc of the nextcloud server if I happen to regenerate keys for example.
b. an ".install" that runs "pacman -Qdtq | pacman -Rscn -" to ensure no package not manually installed
c. and .install finally synchronises the git repo and pulls in the /etc.
3. have a pacman repo on my master machine so that this package is pulled periodically at upgrade by the clients.
There one needs to find a way to tell pacman to upgrade the system only when that package is updated, but keeping the internet repo to download the new versions of the system packages...
That seems as simple as possible and actually even powerfull enough for a multinational ?
Once created, regenerating the package on the repo after an upgrade should be enough to propagate smoothly.
That largely makes sense. Running pacman in a .install file seems fairly fraught (impossible?) and could lead to deadlock since pacman locks the databases - you should probably do that in a separate step.
I've tended to move away from putting most stuff in a .install file as it never seemed very maintainable - it is a lot easier just to periodically run some commands on the different computers manually, and document what needs to happen to bootstrap. 3 computers still isn't that many at the end of the day... and you will have to manually run updates anyway!