Getting pi-hole into Debian

Hello, thanks for pi-hole! It is a great project. I'm a Debian Developer, and I'm here to offer my help. I would like to work to get pi-hole into Debian (and therefore Ubuntu, Raspbian, etc) so that people can optionally just apt-get install pi-hole. That is the long term goal, so I'm here now to assess:

  • Are the pi-hole devs interested in that happening?
  • Are there easy stepping stones, like could I package some dependencies first?
  • Can I help upstream changes into dnsmasq so pi-hole can use the upstream version plus some config?
  • Any guess as to how much work will this all be?

One possible approach would be to start by packaging pi-hole for so that the latest version is always available, separately from the Debian release cycle.

1 Like

Welcome to the Pi-hole forum, eighthave, and thank your for your offer.

Currently, Pi-hole's installation is tied quite closely with lighttpd as its webserver, which may conflict with Debian's packaging policies.

That is about to change with upcoming Pi-hole v6, so you probably shouldn't waste any effort on scrutinising v5.
The development team should be able to feed you with more specifics.

That said, ArchLinux already maintain a separate package for Pi-hole (where 'separate' means that we usually defer support requests to them) - see AUR (en) - pi-hole-server.

I don't see a conflict being closely tied to lighttpd. The package can just
have a Depends: lighttpd. That seems kosher to me if that's the reality. If
it is just a strong preference for for lighttpd that can also be represented.
The Archlinux package seems to also allow nginx.

Sure, now probably isn't the best time though as there are major changes planned.

All of our current dependencies are covered by packages already.

That's up to Simon Kelley but I doubt many of our changes would be used/acceptable to dnsmasq.

A whole lot. It's been tried in the past and never really got anywhere. It's nice to have of course but it's not something we'd be investing any real developer time in.

I looked around but didn't find any previous work. Could anyone point me to that?

As for upstreaming changes to dnsmasq, that is not a requirement for packaging,
just good to have.

using raspbian ( Raspberry Pi OS Lite) here.
I don't know if you have any saying in this, can only ask...

The current method of installing pihole consists of a single command, which turns up as the first result (duckduckgo). The installer does a pretty good job, apart from the occasional 'unsuported OS' topic, there are seldom any topics, that report problems AND, it's under full control of the developers.

The latest version (bullseye) has some things on board, that prevent pihole + unbound to function. The last time (first use of bullseye), I spent almost a day, figuring out why this didn't work anymore (dns loop), read here. Since then, there have been countless topics where the 'simple' solution (once you have found it) needed to be applied, this to make pihole work.

personally, whenever I deploy a new raspbian image, the first thing I do is:

# remove openresolv, install resolvconf
dpkg-query -s 'openresolv' &> /dev/null && sudo apt-get -y install resolvconf
if [ -f "${file}" ]; then
        sudo rm "${file}"
sudo sed -i '/^unbound_conf/ s/./#&/' /etc/resolvconf.conf
sudo sed -i '/^dnsmasq_resolv/ s/./#&/' /etc/resolvconf.conf

a reboot is required after this, dns resolution fails after this
simple, once you found the cause...

this 'unbound' configuration, preventing pihole to work, is there as you first boot a fresh deployed image, unbound isn't even installed at that time.

Do you have any impact on the decisions made for a new OS release, this to ensure raspbian doesn't prevent proper pihole + unbound functionality?

This example is great for demonstrating where getting pi-hole into Debian will
pay off. Debian is a collection of integrated packages. We make sure the
packages work together, and have automated test mechanisms (autopkgtest) to make
sure that stays the case. If someone can put together an automated test, then
it would be included in the package. Then those tests are run whenever the
pi-hole package or any of its dependencies change. So if a change in a
dependency breaks something for pi-hole, it would be much easier to find and
fix. Sounds like using Depends: resolveconf in the pi-hole package would go a
long way to addressing that problem. And if one package always causes problems
with pi-hole, then there is the Conflicts: mechanism.

The existing install script is great for people to hack with, or devote a RPi
to. But they don't cover use cases that need higher security install methods.
I would not feel comfortable using some install script on the internet for
production for the kind of work I do. Debian packages are fully verified on
install, the source code is checked, and they are reproducibly built.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.