Pihole Debian package

General
1

I stumbled over Pi-hole roughly 2.5 years ago. My wife's school had a lot of problems with kids downloading sexual content, games, ... onto school devices. As the small company running the infrastructure really couldn't come up with a solution, I looked around. And Pi-hole looked promising. So I donated two PI 3Bs to the school, installed them and the next day we already saw some very unhappy faces - since then basically no unwanted downloads happened anymore :grinning: So Kudos to the Pi-hole developers.

But what bugged me from day 1 is that there's no package available. This led to quite some issues. And also other schools showed an interest in our solution, but whenever I showed them how to install Pi-hole the show was over. From small 1-man to larger companies, no-one would go for a deployment without a package. That's where the story started. I took up many suggestions from others, finally resulting in the following design criteria:

  • Make a Debian package in the first place, ensuring proper dependency management etc. I try to be as much compliant to Debian policy as my time allows (e.g. respecting the FHS, dynamically link binaries, ...). Unfortunately this also means that the pihole Package isn't compatible with manual installs from Github. If you want to try the package, I suggest doing it initially on a new VM or something so you get the idea. If you want to keep it, save your Pi-hole DBs and dnsmasq.d files and go from there. Running "pihole reconfigure" right after initial install is your friend.

  • Don't touch any existing configurations. Some people have spent lots of times customizing their DHCP, Web, ... setups and Pi-hole shouldn't break any of them. So pihole just advises on changes that should be done, but in the end the administrator is responsible to integrate it into the existing setup. This is usually only required once for initial install.

  • Use of PHP FPM. That way the Pi-hole web interface can run as user 'pihole' and the need to grant sudo to the Web server account is eliminated.

  • Simplify the admin interface. It now uses an ini-style file for input which allows atomic application of any number of changes, not requiring lots & lots of individual pihole commands being submitted. This also allows for a more industrial style administration support, as you can build your ini-file on a test system and once find it ok, you can deploy these settings on your production machine with just a single command - or even automate it.

As part of this, the entire configuration shell scripts have been replaced by a family of Perl classes (Config::Pihole*) that do a very thorough analysis of both the existing config and the newly deployed ini-style file. If they find something looks broken, changes won't be made - so in case don't make things worse by messing around more.

And yes, I know it's still limited in its features, e.g. no adlist management (but as everyone so far has been happy to use the web interface, this doesn't rank very high on the todo list).

  • The web interface is perfect, as far as I'm concerned. But still I made two changes here: First, config settings are now read from golden source and not (only) from setupVars.conf. This data duplication (being out of sync for different reasons) had led to some problems on some of my installations and so I worked on not being dependent on it. The config data is now stored in the session data and only re-read if any config file changed. Secondly, each call from PHP now evaluates the pihole command's return code and if something went wrong, the last few lines of output are appended to the error splash message for easier diagnosis (the full output can be found in lighttpd's error.log file).

If you're interested, the packages are available on https://c.gmx.net/@329593023048457079/YnjiHVTQRLuY7qJiW5pzbg. I currently don't have the means to set up a public apt archive, so this is the only way to download.

Feel free to send comments, suggestions, bug reports, ... I can't possibly test everything as I'm doing this just as a private hobby - so I'm also not on a fixed release schedule and changes to the packages are made whenever there's time.

Thanks & enjoy,

Mirko

2 Likes
2

Why do you think there is resistance to installing software without using a package? There is plenty of open source software available for Linux that doesn't use a package installer.

3

I didn't ask for their individual reasons. And I don't say it's required everywhere.

But working in a large IT organization myself I'm completely following their train of thought: Having a package gives you control. We on our side have our own repository, consisting of a mirror of the required base packages plus all the things developed ourselves. So we have full control over what can be installed on machines and what can't (any cool but not yet verified Open Source library -> have its code screened and bring it into the local repository).

As mentioned this started as a project triggered by local schools. In that environment there's usually little to no admin knowledge for day to day work. If anything comes up, they're going to call their service provider. And when discussing with those guys, without exception, installations w/o package on systems maintained by them are a "no go".

I know many people are happy with the way Pi-hole installation works today. I'm not intending to convince them something is wrong here. i just want to offer an alternative.

4

I understand your line of thought.

However, I still fail to see how an unofficial package from an (supposedly mostly unknown) third party would be viewed as a more trustful installation source than the script as officially endorsed by Pi-hole?

1 Like
5

I'm aware that I'm not a well known Internet celebrity :laughing: So I'm fine to be met with distrust - a smart move by anyone acquiring an unknown piece of software. But people now have the opportunity to dissect the package and see if it is fit for use in their environment.

As mentioned, I haven't interviewed the provider people for their reasons. I can only state my personal view:

  1. The current install/upgrade approach requires online access to public Github for the machine in question. In the IT world I live in this is a no-go.

  2. Packaged software gives you predictability. If you have examined the package once and understood what it does, it'll behave the same on any number of installs you do with it at any given point in time. With a direct update from a web source, you are (usually) not predictable anymore. You would basically need to re-examine the source daily to check if anything new - and potentially unwanted - came into the code before every single install/upgrade.

Again: For everyone who's fine with the current install/upgrade process: Thanks for reading and keep enjoying Pi-hole the current way.

I know the package is as of yet unofficial. The reason being that you need to be as clean in lintian as possible before even thinking about submitting the package to Debian. And that takes time. If making the package available to a broader audience can help ironing out a few things, that would be great!

I'm currently left with three (out of four) linitian warnings originating from Pi-hole's web interface:

W: pihole: duplicate-font-file usr/share/pihole/html/admin/style/vendor/bootstrap/fonts/glyphicons-halflings-regular.ttf also in fonts-glyphicons-halflings
W: pihole: embedded-javascript-library usr/share/pihole/html/admin/scripts/vendor/jquery.min.js please use libjs-jquery
W: pihole: truetype-font-prohibits-installable-embedding [preview/print only] usr/share/pihole/html/admin/style/vendor/bootstrap/fonts/glyphicons-halflings-regular.ttf

I haven't had yet time to investigate this further. Especially the jQuery bit bugs me, as both the file included in Pi-hole as well as the one from official libjs-jquery claim to be "jQuery v3.5.1" - but they differ. A lintian override most likely won't be accepted if it has to state "yes, it's the same version but still different".

6

Why not just compile Pi-hole once and keep that compiled copy local? Then you can install it locally on as many machines as you want.

Or, use the Docker image.

This is pretty much the case for any software updates on any platform. MacOS, Windows, Linux, Pi-hole, etc. all pull their updates from the internet.

Do you have local installers/updaters/packages for all of those as well?

Do you believe Debian will accept your unofficial package? Why would somebody trust such a package more than the installer written by the Pi-hole developers?

The installer script is open source, and you can see exactly what it is doing at every step of the install. You can see every line of our code on our GitHub, along with the complete change history for every line of Pi-hole.

How does your proposed package installer change this?

7

Pi-hole is much more than the FTL. And as mentioned: The people I've talked to will only accept Debian packages. So also Docker offers no way out for me.

Private machines of course can consume from the net, because they're usually expendable (a downtime of a few days or even longer isn't critical). But even then you're locked in for the most critical bits: MacOS will only consume signed packages from Apple update servers - equally for Microsoft Windows.

But machines like servers & routers in a controlled environment - only from local/controlled sources. At least in the IT world I live in. Because they can't afford to have a downed router because of some updated, but uninspected, package loaded from the net.

For Windows you usually have the update & license servers within your private network and controlled by your own AD. And for the Linux machines, yes, there are provider owned apt archives with only a basic set of packages (mirrored from e.g. Debian archives) and they'll only update machines in their responsibility from that controlled source. That's also the reason why they usually lag months or even years behind when it comes to update packages - they first need to make sure the new stuff doesn't break the infrastructure they're responsible for (and usually have signed a SLA with a guaranteed availability).

Yes, that's the whole point of Debian: To allow anyone to contribute. Of course you can't upload directly to Debian's archives - it takes a very long time before you've earned that status. First you'll always have a mentor and a sponsor. And these guys will questions every bit & piece of your submitted package. That's why I wrote above it doesn't yet make sense to submit the pihole package, as there's still too much stuff open that lintian doesn't like.

You might want to have a look at https://www.debian.org/doc/manuals/maint-guide/start.html#socialdynamics.

And it's great that Pi-hole is open source. Only that way it's possible at all to build a Debian package for it at all. And everything in the package can be checked as well: The Debian package installer mechanism is very well documented and the maintainer scripts can easily be extracted from any Debian package and be verified - there's nothing hidden. The changelog.gz in my Debian package btw. contains a reference to your Github and therefore allows also to check every single line of Pi-hole code change.

My aim is just to have something which can be installed by using a simple "apt-get install" or "apt-get upgrade" call from a (possibly third party controlled) apt archive.

I'm not replacing just the installer by something else and still pull the rest from Github. Code in the Debian package is fully self-contained and includes everything for that release to set up a running Pi-hole. So once the package has been verified and been accepted into an apt repository, it's frozen - and it'll give you the same code on every install.

Let's say I have 2 servers. One I install on Friday, the next on Monday. Using the same Debian package I'm 100% guaranteed I'll get identical installs on both. If I use curl -sSL https://install.pi-hole.net | bash the install on Monday can be a different one if you released something during the weekend.

So packaging Pi-hole is a way to make Pi-hole available to people who for whichever reason can't or don't want to use the net install or Docker. It's just another way of making it available and not taking anything away that already exists.

8

The Docker image contains all of Pi-hole. What is missing in the Docker image?

As you would if you used the same Docker image or the same locally compiled version of Pi-hole.

How would users of such a package get updates to Pi-hole? Wait for you (or the package maintainer) to update the package?

Are you going to provide all the support for users of your package?

10

Yes, as with all packages any update would require a new package release.

Regarding support this is a fair point. But I can't predict how people will react. It may well be that issues pop up on your channels. As the FTL code is unchanged and the web interface max. 5%, you might be interested to hear about them as well. The Perl code obviously is exclusively on me.

11

I don't think we would be interested in providing support for your modified version of Pi-hole.

12

First of all, do not waste time to think about an official Debian package before Pi-hole v6 has been released. Currently it's tied too much into a specific webserver configuration and as such cannot satisfy Debian policies without major changes. When the webserver is part of FTL with Pi-hole v6, things look different and also large parts of the installer are not required anymore, remaining dialogs can be turned into debconf templates.

A package maintainer is needed that has sufficient trust in the Debian community and would be responsible for update and bug tracking. Members of the Pi-hole team can be part, but do not necessarily need to, and also it is not uncommon that a Debian package is not "supported" by upstream developers but Debian respectively the package maintainer(s) is fully responsible for the build. Such btw exist already in Arch Linux: https://aur.archlinux.org/packages/pi-hole-server/

14

Thanks for sharing your views. I see that there's no interest in having a Debian package. So I'll revert my focus again back to supporting the local schools.

And thanks again for making Pi-hole available.

15

At least from my end I didn't say that I had no interest, but I think it isn't overall beneficial when it requires too many major changes to have any chance of being accepted by Debian (as I underhand this is your goal as only way for being accepted and trusted by the clients you mention) and not becoming a major support factor for the Pi-hole team because of issue and bug reports that do not apply to the regular latest Pi-hole release. With Pi-hole v6 things should become easier. Then it may be worth to have another look whether the remaining parts of the installer/updater can be translated into debconf dialogs and maintainer (pre/postinst) scripts for a Debian package.

One remaining major issue I see is that AFAIK Debian packages must not contain files in /var/www, so the PHP scripts (which AFAIK remain dedicated files while only webserver and PHP interpreter are integrated into FTL?) would need to go e.g. to /usr/share/pihole. With a single variable for this it would be fine but currently the /var/www path AFAIK is still hardcoded into several parts of the code.

16

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