<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/16/2015 10:48 AM, Steve VanSlyck
wrote:<br>
</div>
<blockquote
cite="mid:1429195729.516686.254633137.1806E129@webmail.messagingengine.com"
type="cite">
<pre wrap="">Is there anyone here who has ever set up more than two servers? I am
curious about what you may have thought of or done in terms of
automating the process.</pre>
</blockquote>
<br>
I have to ask: virtual or physical? <br>
<br>
Great responses enumerating some of the "sanity tools" available to
us these days. <br>
<br>
If things are virtual, take advantage of it. There are things you
can do in that space that you cannot do with discrete boxes. <br>
<br>
<br>
<blockquote
cite="mid:1429195729.516686.254633137.1806E129@webmail.messagingengine.com"
type="cite">
<pre wrap="">For example getting the sudoers file the way you want it... Adding your
public key... Configuring your bashrc file... You know, all the little
things you do to make the server yours. Not necessarily software
installation although that could be done also.</pre>
</blockquote>
<br>
When the servers are virtual, I like to install once, tweak it, then
clone. (Maybe install twice to be fully aware of what actually got
installed.) The master copy will have Ansible or Puppet or whichever
you like. Naturally the master will have your SSH keys and <font
face="Courier New, Courier, monospace">/etc/sudoers</font> and the
rest. <br>
<br>
But you can do better. <br>
In virtualization, cloning is all the rage, but by itself only gives
you ... well ... just clones. You can do better by sharing
filesystems. <br>
<br>
I've made (bad) mistakes in the past by not conveying the full
story. <br>
I've been part of cumbersome implementations. <br>
But shared filesystems is a Good Idea. <br>
I have several systems, on different HW architectures, with shared
op sys. The OS is R/O and each "client" has its own root with its
own /etc and /var. But the rest is maintained in one place. Works.
Skipping the details unless someone cares. <br>
<br>
And then there's the containers game. (Docker being the hottest
player lately.) Depending on what you're doing, that may be better
still. <br>
<br>
<br>
<blockquote
cite="mid:1429195729.516686.254633137.1806E129@webmail.messagingengine.com"
type="cite">
<pre wrap="">I am looking for something that will make the job a little easier to do
than simply writing down on a piece of paper every single thing I do to
configure the box and then following my notes for the next server I set
up.</pre>
</blockquote>
<br>
Low tech works. Don't shred the idea of using paper for some things.
<br>
<br>
This is where scripting comes in. Better than paper for the sake of
reproducibility. (As noted, doesn't scale too well, but may be a
good starting point.) <br>
<br>
<br>
<blockquote
cite="mid:1429195729.516686.254633137.1806E129@webmail.messagingengine.com"
type="cite">
<pre wrap="">Maybe there is a method of running some sort of diff between the two
servers that would focus only on the kinds of things a server admin
would do the first day (assuming he could remember it all, and not
necessarily every single difference between every single file, which
would of course be overwhelming.</pre>
</blockquote>
<br>
Harder to do with physically discrete machines. So ... back to that
question: phys or virt? Either way, maybe run checksums against the
files you're interested in and then 'diff' the output. <br>
<br>
-- R; <><<br>
<br>
<br>
<br>
</body>
</html>