Date: Sun, 10 Oct 2021 20:25:12 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: David Christensen <dpchrist@holgerdanske.com> Cc: freebsd-questions@freebsd.org Subject: Re: best software for managing multiple freebsd & linux machines ? Message-ID: <a1d60e49-c469-5a7c-69f2-f19594369573@pinyon.org> In-Reply-To: <9fd7c5b4-cf27-9940-f058-0762c4fc4a97@holgerdanske.com> References: <YWMHYDbyRyAVAhWa@ceres.zyxst.net> <cffbffec-acc0-9d86-f990-1bdab49abfce@holgerdanske.com> <YWNPxSlhowr0SwHt@ceres.zyxst.net> <31ee138b-243f-ad88-aa46-9cbf5204aa03@pinyon.org> <9fd7c5b4-cf27-9940-f058-0762c4fc4a97@holgerdanske.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi David, On 10/10/21 17:37, David Christensen wrote: > On 10/10/21 15:26, Russell L. Carter wrote: >> I use a single machine to keep host specific files git vc'd, > > > One Git project per host, or one Git project for everything? I don't think it matters, does it? I just use one for now. I make a flat set of OS dirs, then underneath each of those the OS specific hostnames. That way I can share common OS assumptions, included in the lower sh(1) scripts. > >> and then I just write scripts > > > What scripting language(s)? sh(1) > >> for tasks and rsync them over and execute them from the config box via >> ssh. > > So, the configuration of each host is determined by installation (e.g. > full configuration) followed by a sequence of task scripts (e.g. > differential configuration)? Yes, this is basically what something like salt does under the hood. So things like postfix/dovecot or postgresql or yadifa/unbound are going to need a bunch of post install actions. You can write them in the CMS DSL or you can write them in whatever you like. I detest sh(1) for anything complex, but realized that simple sh(1) is just fine for almost everything in configuration space. > > What if a script fails? Fail stop. A failure needs a postmortem, and then a response. Best to halt on first failure. > > Rollback? I thought this might be important when I was starting out but for my non-mission-critical stance, I rely on fail stop. I ought to state explicitly that watching py-salt fail, made me realize that rollback only works if you have the resources to do 2-phase deployment. You've got to vet that the deployment will (should?) succeed in a test environment first. Could be live, but it's still a test environment. I should also add that rollback is part of an audited infrastructure, and no, the overhead of that is something that I am not going to worry about as the sole person responsible for my infrastructure. Add significant money and of course it is required. > > > Idempotentcy? Cattle, not pets? Yeah, I do care about this. Things like sysrc(8) are helpful here, but I still don't have a good password file management story. Basically I bring a big hammer to the job if it looks complex: if things fail, stop. Triage and then fix the script(s), and then restart from the beginning. > > Do you record what scripts have run for each host, and the outcome? I should; when I have been paid to make things succeed, I always did. But for my personal systems, nope, fail stop, then triage. Never had a reason to regret that. I did regret all the time on py-salt, before I rebuilt using the lessons it taught me. > > How do you determine the configuration of a host at some point in the past? That's what the git repo is for. > > What if you perform configuration tasks by hand? I think this is a great idea when you're just starting out, or you are deploying a new software configuration, etc. Automate what you already understand. Great questions! HTH, Russell > > David >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a1d60e49-c469-5a7c-69f2-f19594369573>