I like the rolling nature of gentoo, but also the ability to lock yourself at certain software versions. But for sure the current setup has a major misconfiguration issue somewhere and I am determined to get to the bottom of it for sure. Just need beber to give me access to the system.
--- Regards, Jonathan Aquilina On 2017-06-12 11:50, o.schin...@ultimaker.com wrote: > On Sun, 2017-06-11 at 13:07 +0900, Carsten Haitzler wrote: On Sat, 10 Jun > 2017 19:51:27 +0930 Simon Lees <sfl...@suse.de> said: > > On 10/06/17 15:20, Jonathan Aquilina wrote: Good Morning All, > > There is lots of food for thought in this thread. > > Here is some food for thought. What about using a microservices > management platform such as puppet for example to manage > everything on > the primary server as well as the secondary one in france? > > As I said on IRC given the small scale of what we need I suspect > its > going to be overkill on our setup, on the other hand, having every > config file thats modified in a git repo somewhere probably makes > sense. > On the small number of machines I configure I tend to type "git > init" in > /etc as about the first thing I do. this actually would be by far the most sensible thing. have all cfg files in a git repo. symlink the real ones to the ones in this repo. While a debian developed package, gentoo also has this already automated for you! 'etc-keeper' i believe is the package name. It makes sure all changes in /etc are always tracked automatically (or manually for certain changes if you want it to be so. It creates a git repo of /etc and commits after each merge for example automatically. For files outside of /etc, they'd need to be brought in. Gentoo does this for some packages already, for example transmission-daemon likes to store its config in /var/lib/transmission/config which is symlinked to /etc/transmission on gentoo making it so we can track that too. Just some food for thought :) Olliver > we now have a very simple: > > 1. list of anything that is modified on the system(s) that isn't a > default > 2. history of changes being tracked. > > indeed i don't see puppet as being better. just complexity. if we had > dozens or > 100's of machines... i'd definitely see the value. artificially > having dozens > of machines imho is not worth it. if it's containers or vm's we only > need a > small number. where we REALLY do need vm's is for jenkins > builds/tests, but > these are not "services" as such. they are a target jenkins is > bnuilding on and > testing on, so is really part of the whole jenkins services itself. > >> -- >> >> Simon Lees (Simotek) http://simotek.net >> >> Emergency Update Team keybase.io/simotek >> SUSE Linux Adelaide Australia, UTC+10:30 >> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
