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