Re: named, VARMFS=yes and FILESDIR

Doug Barton schrieb am 30.11.2009 04:54 (localtime):
> Harald Schmalzbauer wrote:
...
>> while building an embedded slave DNS I recognized that running named out
>> of the box with VARMFS enabled would fail.
>> Now I could easily fix it for my device only, but I think it's better to
>> solve it upstream.
>> VARMFS=Yes is a standard option, likewise named_enable.
> 
> There are lots of standard options that are not compatible with each
> other.

Sorry for this long silence. Unfortunately I have only some hours/month 
spare time to work on this.
There are kind of "to be expected" incompatible options, of course, but 
this one hit me some years before. Especcially for newbies, it's not 
clear why these options shouldn't work together.

>> My idea is to create a namedb directory in /usr/share (like there's one
>> for sendmail) with duplicate entries of src/etc/namedb
> 
> Why not just set named_chrootdir to /usr/share/namedb ?  It's not 100%
> clear to me what you're trying to accomplish. Can you please go into a
> little more detail about your goals, rather than potential solutions?

I think rc.d/var should be able to populate a named compliant /var. 
Therefore it needs at least named.conf and named.root.
My idea was to save them in /usr/share, where many other (sendmail e.g.) 
template duplicates also reside. When chrooting to /usr/share/namedb, it 
also fails if I don't have the original installed /var, like if /var is 
a freshly populated memory file system.

>> P.S.: named_conf definitions in rc.conf get lost. 
> 
> Yes, that's something that needs improvement. I have it on the list
> but since it's not common for people to alter the path to the conf
> file, and since in the past in order to do so you've had to add -c to
> named_flags anyway, I don't regard it as urgent.

Is there anything wrong with my patch?

Thanks,

-Harry