On Sat, Aug 02 2014 at 09:01, Nick Holland wrote:
> 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.
Thanks a lot for the time you invested to write such email. I have
the basics to write my own script now.
Best regards,
Claer
