NAT: Handbook vs mailing list

[Michael Powell]

Olivier Nicole wrote:

[snip]
>>
>> The mailing list message linked above suggests that the handbook
>> information is the "old way" and that the correct way is to set
>> ipfw_enable and natd_enable in rc.conf.  "Then /etc/rc.d/ipfw will
>> load ipfw.ko, and if natd_enable is set, will invoke /etc/rc.d/natd,
>> which loads ipdivert.ko at the right time."
> 
> From what you copied/explained, natd_enable will load ipdivert.ko and
> the handbook suggests that you load ipdivert.ko, so either way the
> module will be loaded.
> 
> I'd go with the ipfw_enable and natd_enable as it may also do other
> needed things than just loading a kernel module.

+1 on this. It is also present in the /etc/defaults/rc.conf this way as well 
(of course, use /etc/rc.conf for override customization). The original 
situation referred to early in the mailing-list content was a timing related 
problem where the ipdivert module would fail, even after ipfw loading _did_  
succeed.

Most of the 'old way' is a holdover from before the init system brought in 
the rc.subr startup scripts (imported from netbsd if memory serves). There 
have been a couple of hiccups along the way concerning the order things are 
started. For example, it doesn't really work to start a dhcp client prior to 
successful network initiate completion. Over time the rc.subr system has 
evolved and been cleaned up. 

A long time ago I eschewed running mergemaster when doing source-based 
upgrades. Just didn't like it and it never seemed like not doing it hurt 
anything. For quite some time I never experienced any problem with this 
approach. However, this eventually did bite me in the rump in a very bad 
way!  :-)

When running mergemaster while upgrading to a new release you may see these 
scripts being updated. So they are continuing to evolve, and a lot of this 
is to start up and configure things as the system comes up in a 'correct' 
and coherent order. So imho the Handbook is a wee bit outdated.

-Mike