Puppet is definatly a sledge hammer approach, but if you have lots of
firewalls its great.
We run around 13 or 14 pairs of OpenBSD firewalls now, and puppet
allows us to maintain one common template based code base, and change
only a couple of things specific to each environment (where each
environment is a unique firewall pair).
This makes upgrading and looking after this many firewalls possible for
just one person.
If I tried to manage that many firewalls on my own without puppet I
would have lost the plot and all my hair by now.
Another nice example of an appropriate application is that by using
PuppetDB, a full IPSec VPN mesh is built automatically by puppet
between every firewall according to the subnets behind each firewall
pair. So if I add a single new subnet behind a remote office firewall,
the 12 odd extra tunnels all get created automatically.
But unless you are wanting to do stuff like that, then yes, I
completely agree with Nick puppet is major over kill..
Hope this helps.
Cheers, Andy.
On Tue 29 Jul 2014 12:52:29 BST, Nick Holland wrote:
On 07/28/14 23:21, sven falempin wrote:
On Mon, Jul 28, 2014 at 11:19 PM, Leonardo Santagostini
<lsantagost...@gmail.com> wrote:
Maybe puppet?
If this is your only fly, Puppet is one hell of a cannon to swat it
with. There are also things I think Puppet does well, and things it
does poorly. Manage 400 nearly identical machines? Good. Two
firewalls? Wrong tool. Systems like firewalls and DNS servers where
you sometimes need to test something and see if it fixes a problem?
dead-wrong tool.
Sorry, I've worked with Puppet zellots who's solution was "Puppet!
what's your question?", and they annoy me. If you need it, great. But
you now need PUPPET administrators, not Unix administrators, and good
ones are very few and far between. And not working at GE's incident
reponse group. Oops, did I say that out loud?
Regards
El jul 29, 2014 12:08 a.m., "Nick Holland" <n...@holland-consulting.net>
escribió:
...
The script is identical between machines, so if you lose EITHER
firewall, the other can be used to rebuild the missing system, including
the history.
If something goes horribly wrong, you just dig out the history file, and
revert the change. If something goes horribly wrong before you sync it,
log into the "other" firewall, and push the changes back.
Wonder why a rule is in the firewall? Look back through the change log
and read the comments.
I've done the same thing with DNS zone files and config files, (in my
opinion) better than the BIND "master/slave" model -- set up each node
as a master, and sync the data through scripts like this.
Nick.
where are you storing the change history ?
History was stored on another partition on the disks of the firewalls.
Everything should be self-contained in the firewall systems in my model.
Think disaster -- if you are worried about managing your firewall, they
apparently survived, no reason to assume something else survived, though.
Actually, my first model of this was a pair of machines with a 6G boot
disk and a 40G secondary disk on each of the two systems. This was
before the softraid days, so we used a combination of rsync and ALTBOOT
to keep the 40G disk a "mirror" of the 6G disk. The rest of the 40G
disk was used for history and config backups (tar files of the /etc
directory). As I recall, at the rate I was using that 40G disk, we'd
have had to upgrade the system (or delete backups or history) in fifteen
years or so. :)
The two internal drives were overkill. Not my best idea (though far
from my worst! :) ). But yes, put it on a separate partition, gives it
one more chance of survival.
Nick.
