Bug 247305

Summary: dns/unbound: start earlier because it can provide local name service
Product: Ports & Packages Reporter: Andriy Gapon <avg>
Component: Individual Port(s)Assignee: freebsd-ports-bugs (Nobody) <ports-bugs>
Status: Open ---    
Severity: Affects Only Me CC: fernape, jaap, rgrimes
Priority: --- Keywords: patch
Version: LatestFlags: jaap: maintainer-feedback+
Hardware: Any   
OS: Any   
Description Flags
proposed patch
alternative patch none

Description Andriy Gapon freebsd_committer 2020-06-16 11:26:36 UTC
Created attachment 215610 [details]
proposed patch


I am configuring a small LAN -- mostly a gateway / router for it -- and I am
using unbound for a local DNS and isc-dhcp44-server for DHCP.
I have a few hosts with static IP addresses (for various reasons).
So, in unbound.conf I have an entry like
  local-data: "hipster.home.arpa. IN A"

and in dhcpd.conf  have:
  host hipster {
    hardware ethernet 40:74:e0:xx:xx:xx;
    fixed-address hipster.home.arpa;

I am using a DNS name to avoid hardcoding the same IP address twice.
But obviously this depends on the local DNS server starting before the HDCP
server if they are on the same host / router.
It seems that at the moment there is nothing to ensure that order.

It's been pointed out that both local_unbound and bind (in the default configuration) start earlier.  local_ubound start even before NETWORKING while bind starts before SERVERS.

I am proposing to change unbound port to do the same thing as bind ports.
START_LATE port option is provided for those who would need to start unbound at its traditional stage.
Comment 1 Andriy Gapon freebsd_committer 2020-06-16 11:29:27 UTC
Created attachment 215611 [details]
alternative patch

I have written an alternative patch.
It changes the startup order less drastically, so that unbind starts between SERVERS and DAEMON.  That's enough for my use case.
Comment 2 Rodney W. Grimes freebsd_committer 2020-06-16 14:50:55 UTC
(In reply to Andriy Gapon from comment #1)
I am ok with this, but I think it is fixing to narrow a set of cases, specifically only a subset of cases, ie DAEMONs that want to use dns in the configurations.  That set is large enough that this is a productive change.

I still wonder about the base system vs ports being different.  That just rubs me the wrong way.
Comment 3 Fernando Apesteguía freebsd_committer 2020-06-17 12:28:48 UTC
^Triage: Reporter is committer, assign accordingly.
Comment 4 Andriy Gapon freebsd_committer 2020-06-17 12:37:57 UTC
(In reply to Fernando Apesteguía from comment #3)
I am an src committer and never commit to ports.
Comment 5 Fernando Apesteguía freebsd_committer 2020-06-17 13:00:44 UTC
(In reply to Andriy Gapon from comment #4)

Hi Andriy

Any committer may commit to any repository with an accepted review from any committer with existing access to that repository.

Committers may obtain review via a Differential in Phabricator, adding the "Contributor Reviewers ($Repository)" group as a Reviewer, reaching out to other committers; directly or via mailing lists, or setting the attachment flag to: maintainer-approval ? <person-youd-like-to-review>
Comment 6 Andriy Gapon freebsd_committer 2020-06-17 13:27:48 UTC
(In reply to Fernando Apesteguía from comment #5)
I am aware that I *can* do it.  I am just letting you know that I am not doing it.
There is the maintainer who makes a decision if the proposed change is good.
There are port committers who are fluent with committing to ports.
I am just a reporter.
Comment 7 Fernando Apesteguía freebsd_committer 2020-06-17 13:48:28 UTC
(In reply to Andriy Gapon from comment #6)

Sure, thing. It was not my intention to annoy or lecture you :-)

Back to the pool.
Comment 8 Jaap Akkerhuis 2020-07-27 10:52:06 UTC
(In reply to Andriy Gapon from comment #0)
Given the discussion I'm actually leaning towards using the same ordering as the default in the base (local_unbound).

That has the benefit of the least surprise (I think).

Comment 9 Jaap Akkerhuis 2021-02-25 13:52:14 UTC
Overtaken by events (newer releases).