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.
