Hi,
Puppet or Ansible would be the best choice as then you can
normalise/manage every service (from pf.conf to named.conf, ipsec.conf
to isc-dhcp, and ospfd.conf to bgpd.conf) etc on the firewall pairs.
We do this and we are now managing over 50 files including Snort and
OSSEC etc..
Cheers, Andy.
On Tue 29 Jul 2014 04:21:46 BST, sven falempin wrote:
On Mon, Jul 28, 2014 at 11:19 PM, Leonardo Santagostini
<lsantagost...@gmail.com> wrote:
Maybe puppet?
Regards
El jul 29, 2014 12:08 a.m., "Nick Holland" <n...@holland-consulting.net>
escribió:
On 07/28/14 07:50, Peus, Christoph wrote:
Hi all,
is there a standard or recommended way to keep the pf.conf on the CARP
cluster
members in sync?
Thanks!
No one standard or recommended way, but lots of ideas, as you can see.
Here's mine, but for the moment, I'll leave you to develop the script.
My design philosophy:
1) No additional hw, other than the two firewalls.
2) EITHER machine should be able to act as master.
3) EITHER machine should be able to provide all the info to rebuild the
failed machine.
4) Change control is good, just not how managers usually like to
implement it.
5) uses no other packages (rsync to move pf.conf around? I don't think
that's needed)
So... I wrote a relatively simple little script which
* Figures out which the "other" machine is
* does a "diff -u" of the changes between the local machine and the
"other" machine (assuming the "other" machine is the old config)
* Displays the diff to the user, and asks you to explain the change.
* records the diff and your explanation to a file with a date and time
stamp as a file name into a change log directory.
* copies the pf.conf and the change log file to the corresponding
directory in the "other" machine.
* pfctl -f /etc/pf.conf's the other machine.
So...you make a change on one box (EITHER!), test it, when satisified,
you run the sync script. It compares the changed file to the other
system, shows you the diff, and you can:
1) comment it and save it to both
2) Realize you made a typo, and deleted something you didn't intend to
or fat-fingered something you didn't intend to, fix.
3) Realize that you made some other changes that weren't sync'd on
either machine
4) etc.
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 ?
