On 11/30/2006 04:25:12 AM, Sergey Prisyazhniy wrote:
Yes, Luca :). The think is, that I want, for example, to setup
remote machines
via siteXYtools (also load to pf.conf).
And as you can get, I don't know anything about the remote
NIC's, so in this case
I wana make fully automatical process... :)
This relates to a problem I have, carp failover
of 2 firewalls that do not have identical
nics. Normally, changing the macros in /etc/pf.conf is no big deal,
but in this case you're faced with maintaining
almost-duplicate pf.conf files on
two boxes, files that differ only in the nic cards used.
This is a pain.
(OTOH, _duplicating_ pf.conf ie easy with rsync.)
To think out loud here, suppose you custom configured
/etc/hostname.if and added a description to the interfaces
that indicate the purpose of each interface.
What would be the right way to use that description to
establish appropriate pf macros to abstract those interfaces?
This would still require you know _something_ about the interfaces,
but you'd at least have only one place to maintain the information.
My inclination would be to activate pf manually in rc.local, after
running awk on the output of ifconfig to find out the
right device names, and then feeding the result to m4 to
generate pf.conf from a m4 file. The flaw here is that any
other sysadm coming in to look at pf.conf would hate me,
even if the generated pf.conf file had a big warning at the
top saying where to look for the real pf.conf file.
The clean solution would be if pf had some sort of #include
mechanisim. Then the macros that abstract the interfaces could
be written into include-ed files and everything else would be
sane.
Anybody else have any ideas?
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
