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.
