I think my ‘name administration’ and your ‘logic’ mean the same thing.
I started to document the administration of names:
names of static hosts are stored in hosts.conf
fixed DHCP leases are stored in dhcp-leases.conf
dynamic DHCP leases are stored internally and read from dhcpd(?)
This list isn’t complete, I think.
On restart unbound should read the definitions of hosts known by dhcpd. Therefore unbound-leases-bridge must update these lists. Modifications to the DHCP name space in the running system should signaled by unbound operations which modify the unbound db.
A clear/build operation ( unbound reload ) should be avoided. My opinion.
So far the theory. The steps of @jon, @ms and myself try to realize this.
But it isn’t just a modification of unbound-leases-bridge without looking at whole local name space.
Perhaps, but on restart of unbound, unbound re-initialises itself by reading dhcp-leases.conf which could be days old as it is only maintained on dhcpd startup. Please see @ms 's comments 151 and 153 where he acknowledges the problem and solution.
A clear/build operation ( unbound reload ) should be avoided. My opinion.
is just burying your head in the sand. How can you expect your users to know something like that? Especially when the solution is easy. The solution then allows you to restart unbound whenever you need to.
We have already established that other firewall events can trigger an unbound restart. If a reload should be avoided, all these events need to be tracked down and blocked.
This is wrong. The leases bridge must update dhcp-leases.conf!
The goal of @ms was to minimize writes to this file. But as far as I see, the information is altered by fixed leases definitions only. The set of dynamic leases is empty at system start and updated with each REQ/ACK operation on the dhcp side.
My opinion: All internal unnessary restarts should be avoided.
Unbound restarts by the user ( from the CLI or by defining new DNS servers ) can’t be avoided, that is right. But all reload operations ( which yield a restart ) should be removed.
I disagree. The dhcp-leases.conf is only maintained during start up of unbound-dhcp-leases-bridge in @ms 's patch. There is no attempt to maintain it again and there is no need. It just creates a load more reads/writes and is unnecessary. It also risks external events such as a crash or something stopping just before a write is done causing the file to go out of kilter.
The dhcp-leases.conf only ever needs to be correct at the point that unbound is started, so why not just generate it then? It is a fast op and minimises writes.
Continually maintaining dhcp-leases.conf is a waste of effort.
Each user is able to do this from CLI. Where these commands are used inside the IPFire system, don’t know. I’ve not examined all places handling local DNS information, yet.
Command line jockeys always risk breaking the system, I’m afraid. I believe all that really needs to be catered for is for when people use the UI.
If you want to cater for everyone, in this case, it may be able to be done if dhcp-leases.conf is permanently maintained by unbound-dhcp-leases-bridge, but it is not done in @ms 's patch.
A decision is needed here, but the current approach does not appear to plug your or my holes.
And, FWIW, a lot of the software here won’t run properly if started manually using direct commands. Look at all the init scripts to see what other processing is done as part of the start up. All this gets bypassed if people start or reload apps outside the init system.