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 ? -- --------------------------------------------------------------------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\
