[openbeosnetteam] Re: our package

> Built-in "databases" is the best, yep.
> Having default "databases" as global data (arrays of structures, most 
> probably)
> make sense, until we didn't forget to look first for any customized settings 
> in
> locations like
> /boot/{home/system}/config/data/network/{services|protocols|networks|resolv.conf|you
> name it!}.
> If such file don't exists or key cannot be found, simply fallback to builtin
> data.
> 
> That way, Haiku's libbind.so/libnet.so will come ready out-of-box, without
> dependencies on external config files. Very BeOSish. :-)

Yes, that sounds nice.

> The bad news is this require changing BIND code :-(

Cool, you are on my side! :)
Seriously, this is a change that is worth the work, IMHO.

> BTW, I like the /boot/system/config/..., it make lot of sense...

You are as confused as I am. :) /boot/beos/system, but /boot/config is probably 
better.

>> Is /etc/networks only used by "route"? If so, we could possibly drop it? :)
> 
> I've modified my /etc/services to add SANE remote scanning protocol just 4 
> days
> ago. We can't assume any of these "databases" are static forever, even if
> /etc/networks is not often needed for... well, I don't even know what's his
> purpose!

I think it is for making "route" (bin) translate IP addresses into nice names 
(like reverse DNS, or "hosts"). Nothing useful for desktop users.

>> What is left is only resolv.conf. We should at some point replace it with a
>> kernel DNS handler (which could support temporary and static DNS entries, I
>> wrote this too often).
> 
> But we'll have still to support persistence of the static DNS entries after a
> reboot. Resolv.conf can be supported like others files in fact, except that
> instead of static arrays of default databases values, it should be a dynamic
> list of DNS entries.
> Empty at start, the list is filled by DHCP and
> /boot/{home|system}/config/settings/network/resolv.conf content(s), if any.

I thought of a driver_settings file. If you add a static DNS entry it is saved 
to disk, but if you add a temporary entry it is stored only in memory. After a 
reboot only the temporary entries are removed, while the static ones are kept. 
I wanted to implement this with net-module attributes (like in our newstack) 
and additional flags saying "static", "temporary". Static ones will be saved.
Alternatively, we could just add a driver_settings structure to every 
net-module and let the stack automatically load it on boot and save it when 
something changes. The API could look like this:
settings = aquire_settings(module_name, static/temp)
release_settings(settings).
On release, static settings get saved to disk.

> That means by default Haiku will access to Internet out-of-box if DHCP is used
> (Dialup or LAN, doesn't matter).

Is there a difference to Windows/Linux?

> Anyway, should we rewrite DNS handler as a kernel module.
> I feel so: DHCP support need to interact with DNS name servers list, and 
> network
> file systems will be happy to resolve names from kernel too.
> Plus post-R1 ZeroConf support will need multicast DNS responder builtin in the
> stack too.

Does IPv6 need this, too? It has some ZeroConf capabilities built-in. Well, it 
surely cannot handle host names, so DNS is still needed, right?
Does a multicast DNS responder need a simple DNS server (e.g.: complete BIND 
suite ;)?

> But I've fear about it.

Do you fear buffer-overflows because BIND is so popular?

> Do you guys know about good/better opensource (and compatible with Haiku
> licence) DNS resolver than BIND's one?

No, but BIND9 really looks good. I had a look at the older versions and they 
were really messy. BIND9 is rather clean, but huge. Axel, you see, we really 
need kernel-land-libraries. This would allow putting libbind into the kernel 
and creating a simple module that handles requests and routes them to libbind.

>> /boot/system/config would be better, IMHO. That would allow the same naming
>> scheme as in /boot/home/config.
>> But we already have /boot/system/add-ons. Should we replace it with a link
>> and move the folder to /boot/system/config (or /boot/config?) in order to be
>> more consistent with the /boot/home/config directory structure?
> 
> Ah. Well, that's right. Maybe /boot/system/"config" is not that great, then.
> /boot/system/data ?
> /boot/system/etc ?   ;-)
> 
> Hell, what's in a name!!!
> Starting from now, I'll refer it by B_COMMON_DATA_DIRECTORY only and don't 
> worry
> anymore. That's the purpose of using find_directory(), right!?
> :-)

:)
I think we can agree on /boot/config/{data, cache, settings}.

Bye,
Waldemar

Other related posts: