unbound: enable splitting of unbound_srv.conf and unbound_ext.conf

[AndreaBorgia-Abo]

📦 Package Details

Maintainer: @EricLuehrsen

Description:
allow splitting these config files into smaller chunks with a stable naming convention,
so the files are included in backups automatically

---

🧪 Run Testing Details

• OpenWrt Version: 25.12.3
• **OpenWrt Target/Subtarget: ipq40xx/generic
• **OpenWrt Device: AVM FRITZ!Box 4040

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

If your PR contains a patch:

• It can be applied using git am
• It has been refreshed to avoid offsets, fuzzes, etc., using

  make package/<your-package>/refresh V=s

• It is structured in a way that it is potentially upstreamable
  _{(e.g., subject line, commit description, etc.)
  We must try to upstream patches to reduce maintenance burden.}

[AndreaBorgia-Abo]

the changes are basically done, I am keeping it as draft until I can get the docker sdk running and check the results.

[dave14305]

The init script won’t include these extra files in the final configuration as it stands now. Where are they supposed to be included?

[AndreaBorgia-Abo]

Not sure I understand the question (or how the build works, until I can try it!)

Following discussion in the forum, I am trying to setup the package in such a way that, after installation, a user might create split configs with a given naming convention and have the files be included in the backups with no extra steps.

[GeorgeSapkin]

You can't have merge commits in your PR. Please squash them. The CI is not running since you're a first-time contributor. And you need to bump the PKG_RELEASE.

[AndreaBorgia-Abo]

assuming the build does what I expect (still checking), would the PR in the current form be acceptable?

[dave14305]

Why is this proposal better than just including the full /etc/unbound/ directory or /etc/unbound/*.conf? These new file name patterns are arbitrary and unique to your own convention.

[AndreaBorgia-Abo]

@dave14305 not including the whole directory was a goal to avoid potential issues and the name patterns are echoed in the supplied configs: it doesn't really matter as long as config and example are in sync.

[dibdot]

Adding to @dave14305's point about the init script not picking up these files: there's a fourth layer that breaks here, namely LuCI.

The luci-app-unbound frontend generates its configuration from UCI and has no knowledge of these split files. A user who drops manual snippets into /etc/unbound/unbound_srv-*.conf and then hits "Save & Apply" in LuCI ends up in a potentially inconsistent state:

LuCI rewrites the configuration from UCI, ignoring the splits
The init script emits the generated config, without include: directives for the splits
The manual files sit there but never reach the running unbound instance
sysupgrade dutifully backs them up though

The user is left wondering why "their" config has no effect after every LuCI action. Support burden incoming.

A proper splitting mechanism would need to address init script, LuCI, backup and naming convention coherently.

Bottom line, this isn't "a small improvement, the rest comes later" — it actively makes things worse, because users will reasonably assume the pattern is officially supported when in fact it isn't carried through anywhere else in the stack.

The underlying need (sysupgrade-safe user config snippets) is real and worth solving, but the solution needs to land coherently across init script, LuCI, and backup — ideally with @EricLuehrsen weighing in as the package maintainer first.

[EricLuehrsen]

What is the original problem that splitting the files solves? Maybe restate the foundation assumptions to generate a more generic solution. In the forum, it says upgrades broke a custom split design, okay. Please describe the reason for a split design. Otherwise it feels like a local preference rather than a design solution.

[AndreaBorgia-Abo]

The original problems were:

• my unbound_srv.conf was getting unwieldy: exceptions for sites known to misbehave with IPv6, the fake "dummy.nodomain" entries for SAP VMs / containers, vpn-specific settings, etc
• if I had to disable a section for testing, it meant changing a bunch of lines and possibly forgetting some of them: a single include line in unbound_srv.conf and a whole section is split out, easy peasy

Upgrade breakages, two specific instances:

• distant past: in 2022 because root.hints was not saved, I haven't checked if this is still needed because /etc/sysupgrade.conf now has an entry for this
• recent past, .2 to .3: I had split the config but crucially forgot to update sysupgrade.conf so I had to go back to an older backup (and also add the files to sysupgrade)

Hot on the heels of this second case, a suggestion was made to open a PR to upstream the changes. Although it is not a particularly difficult change, I felt it was the kind of little thing which make life easier for forgetful people (ahem...) and went with it: extend / create keep.d entries and explain the logic in the relevant files, with an example.

As far as I can tell, this setup has no trouble with LUCI updates because the includes are in two files (unbound_ext.conf and unbound_srv.conf) which are not touched by LUCI. Since sometimes I edit files via the UI and sometimes directly, I guess I would have noticed if a missing include led to a breakage and the two breakages I had were not caused by conflicts with LUCI.

There, better now? This was all meant as a convenience feature and staying out of the way of LUCI was a design goal, I know nothing about it and have no desire to mess with it :)