On 08/01/14 08:12, Claer wrote:
> On Mon, Jul 28 2014 at 07:23, Nick Holland wrote:
...
>> 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)
>
> Could you share it please ?
well, no, in large part because I left the employment of that employer
rather suddenly, and it seems I didn't save a copy of THAT script,
though I do have some notes that will help (my DNS version). (and yes,
it's legit -- it wasn't a software company, and I had an understanding
with the people that hired me that I could use any of the stuff I wrote
however I wished. The person who escorted me out I'm sure would
disagree, but he got escorted out shortly afterwards. BTW: if you ever
find yourself being escorted out of a job for doing what you are
confident is right, a great line is to politely ask, "would you like me
to deactivate my accounts, as you don't have anyone else left here to
do it?" That's when the yelling began).
Here are some code snippits that might be useful. Nothing magical here,
but there are a few tidbits I had to work out, but be forewarned, I
probably did it the hard way (I'm proud of the ssh diff between two
boxes, but that probably means I made it way too difficult. This script
is completely untested, I'm sure it won't work as is, and you get to
provide your own error handling. I'd call what I did an "administration
script" not a "user application".
I'm assuming you have sudo access, and are SSH'ing to the first firewall
with -A (agent forwarding) and have key access on both systems.
# start. Note the lack of #!/bin/sh, I'm not calling this a
# complete script!
TMPLOG="/tmp/~config.log"
# /backup was a file system on a second disk in each FW.
CHGLOG="/backup/changelog/`date "+%Y-%m-%d-%H%M%S"`.diff"
# Figure out who I am and who my partner machine is.
# Our name -- easy.
HERE=`hostname -s`
# Other machine's name. Assumption: machine names are in the form
# *1 and *2, so that swapping the 1 and 2 will indicate the other machine.
# This is a non-trivial assumption...but it works for us - fwa-1 <-> fwa-2
OTHER=`echo $HERE |tr 12 21`
# Generate a temp file with the diff between the old and new
# file. Should probably be with mktemp, but as there is a lack
# of locking to protect against multiple users, there are bigger
# issues here.
echo %% Change by ${LOGNAME}@${HERE} on `date`: >$TMPLOG
echo >>$TMPLOG
echo >>$TMPLOG
ssh $OTHER "sudo cat /etc/pf.conf" | sudo diff -u - /etc/pf.conf >>$TMPLOG
# Toss a marker to indicate when the change file was first made.
touch ${TMPLOG}.tag
chmod 664 ${TMPLOG}.tag # makes it easier for other admins to delete.
# Call up editor
vi -c ":3" $TMPLOG
# If the temp log file is not newer than the .tag file, it apparently wasn't
# edited, which means the commit was aborted. Bail. Note: IIRC, there were
# some rough edges here.
if [ ! $TMPLOG -nt ${TMPLOG}.tag ]; then
echo
echo
echo "** Sync with $OTHER aborted!! **"
echo "NOTE: DNS servers are likely out of sync!"
echo
rm $TMPLOG ${TMPLOG}.tag
exit
fi
Save the change log HERE.
mv $TMPLOG $CHGLOG
# Copy stuff over to $OTHER server
echo Syncing with other server
scp $CHGLOG $OTHER:$CHGLOG
scp /etc/pf.conf $OTHER:/tmp/pf.conf
ssh $OTHER "sudo mv /tmp/pf.conf /etc"
# install. you DID test this, right? Note the lack of error handling!
ssh $OTHER "sudo pfctl -f /etc/pf.conf"
rm ${TMPLOG}.tag
That's pretty much the strategy. Lots of site specific assumptions,
lots of things that could be done better in the script. As noted,
one major flaw is the handling when two admins are making
changes at the same time, but then, at this site, the two of us were
both familiar with the OpenBSD ways, and always tried to get an "ok"
from the other before making a change, which ensured that we both
knew a change was coming. Its handling of issues like admin A starts
but never finishes the update, then B comes along and does an update
are crude, but if you write your own, you know what the errors mean.
If I were doing this again, I'd probably put in some kind of
comparison of hostname.carp* files, as we found if those are not in
sync ugly things happened.
My favorite part, though is the changes are almost self-documenting,
so easy that the administrator won't object, and having the change
diff stuffed in your face is just an overall good plan, I think.
And, to find why a particular line was made, use "grep" to find
when the line was changed/added, and look at the commit message.
I've been told I should use rcs or cvs or similar...but I really
prefer the "one change per file" and all text file format.
Nick.
