Pihole v6 beta baremetal on Alpine?

General Beta 6.0
1

With the Pihole v6 Alpine docker images means this that we can (maybe now in beta?) install pihole on baremetal alpine?

2

You'll need to add bash at the bare minimum but the only way to know for sure is to try.

3

Yea and no.

Take a look over the docker file to see how we set it up, which basically "manually" runs specific parts of the install script

2 Likes
4

Thanks! :slight_smile: I think stay with container. Alpine as VM and Docker together are so lightweight, that i don't really feel a difference (when used network_mode: host).

An awesome thanks for the work and alpine Container :+1:

5

Probably a good decision, much easier to keep up to date than having to manually go through the install steps each time :slight_smile:

1 Like
6

Would it be possible to "convert" the dockerfile to a simple shell script to make life easier for us Alpine Linux user?

I don't use Docker (my Alpine Linux vm is in a jail on FreeBSD) so it would be really helpful!

7

Copy paste from a Reddit question asking the same thing:

Yes and no.

The no part:

The install script will not allow you to install on Alpine, as it is not officially supported on a bare metal system. That's not to say it wont in the future - it's just not a focus currently. I imagine the number of people running Alpine on bare metal is relatively minimal.

The yes part:

Pi-hole will run on Alpine, but you would need to manually configure everything. Things like the update script etc would not work.

The docker image is switching from a Debian base to an Alpine base - it should be farely trivial to manually follow what the Dockerfile is doing... or you could also just install Docker and run the container version :wink:

10

The question stemmed from that thread, actually, where you suggested to follow what the dockerfile was doing.
I took a peek inside and it looked to me like a series of commands which could be translated to a bash script for bare metal installation, hence my question on converting it.

My current situation is that I installed pihole a long time ago via yvelon / pi-hole · GitLab but with the last update it half-borked the installation because the FTL and "main" pihole stayed at the "custom" version and the web part updated at v6.

My fix was to manually download the official v6 FTL because I figured that now that Docker image is using Alpine, the newer FTL builds are probably compatible "out of the box", which was the case.
I then had to redo part of the configuration via the web interface and it is now working.

The only thing that I don't really like much is that now I have the "base" pihole stuck at commit 0c6b70fa of yvelon / pi-hole · GitLab and the web interface and FTL at the latest "official" v6 and everytime I update I have to manually update the FTL by downloading it and replacing it (which I can definitely script it when running pihole -up, but still).

I don't know what yvelon has done with his pihole fork, but now that "official" FTL and webUI are working out of the box with Alpine, how hard would it be to make it completely compatible?

11

Some additional changes would still be needed in the main Pi-hole repo for it to work.

The main issues I can think of:

  • package manager support, would need apk adding
  • service/systemd scripts - are they nessacerily compatible with an OOTB alpine install?
  • update scripts etc may not work due to bash dependency. In an ideal world we would make all the scripts posix compliant, but it's a lot of work!

Although the Docker image is now running on alpine, it's not following the bare metal installation methods, i.e we set it up manually and don't worry about any of the incidental scripts/service wrappers etc - and we can do this because each release is self-contained and is updated by replacing the entire image.

Not saying it's impossible, it's just probably not a priority at this stage

12

I'm an Alpine maintainer and I've been using the Docker image for a while but really wanted to move to installing it on my base system without using Docker. I've got a working package in review on Alpine GitLab. For the average user this would work just fine and in-fact I'm running this now.

Although to make this work I'm carying a relatively heavy set of patches to change pathing assumptions in FTL and the management scripts. I'd really like to get some of these patches upstreamed if the project is willing to take them.

The changes logically amount to:

  • Don't use /etc for mutable state. Most of the mutable state files have been moved to /var/lib/pihole. There's still some work to be done to be able to generate the config file at packaging time but for now I'm just letting Pi-hole write it at first startup.
  • Don't assume that Pi-hole is the only user of /var/www. I've moved the web admin to /usr/share/pihole/admin-web.
  • Don't assume binaries and scripts are located in /opt and /usr/local. I moved the binaries to /usr/bin and the scripts to /usr/share/pihole
  • Disable some script functionality that takes too much control of the host (such as the pre-start scripts and the update mechansim). This fits pretty well into the domain of the apk package manager so there's minimal lost functionality just letting the package manager own that stuff.
  • Adding init scripts and cron jobs to the distro-specific places

I can fix almost all of the FTL assumptions with some cmake updates but the scripts are a lot harder. To drop our patches I think that there would need to be a make step in the script repo to preprocess files with the correct paths as well as some rather minor consolidation of paths into variables.

PromoFaux, is that something you'd be willing to accept as patches? I'm totally happy to do the work and submit PRs if you're open to merging those changes.

14

Thanks for your effort to pack Pi-hole into a Alpine package. The points you mentioned are all breaking changes and personally I don't see them being included soon. It's not only the changes we need to discuss, we also would need a lot of migration code for existing installations.

Having a Pi-hole package distributed by the OS had advantages and disadvantages. The downsides I see: Updates might get pushed slowly (maybe not on Alpine :slight_smile: compared to pihole -up; testing will be harder (if not impossible at all) due to disabled pihole checkout

But let's see what the others think.

15

Yeah, I definitely understand that those are some major changes for the ecosystem. I actually re-built my patches to make them all configurable and to default to the current paths and functionality that's in Pi-hole in an attempt to minimize impact to the Pi-hole ecosystem while still giving distribution packagers the flexibility to package in a way that fits their distro.

Here are my patches to FTL (GitHub). In my opinion all of those should be safe to merge if you're willing to do so. I'm happy to modify them however you like to make them fit more into your development flow.

These are my patches to the scripts (GitHub). Everything except "Use FHS paths" should be safe to merge with no regressions to the current behavior. I still think that while this is an improvement because it consolidates paths into a few variables it's not an optimal end state. A build process (even something as simple as just Make) that replaces variables in the scripts and allows a distribution maintainer to override those variables at build-time would be optimal. I'm willing to build that if there's a general consensus that such a thing would be welcomed by the project.

As for the pihole -up process, yeah, this would basically eliminate that on Alpine for the sake of using the package manager. Looking at the release cadence for the project and how quickly we typically turn package updates around, I don't think Alpine users would lose anything.

For developers and testers, I wouldn't recommend using the downstream package at all. Your checkout scripts work well for that. Although, rather than making your own APKBUILD file and inling it into your script you could just pull ours from downstream and extract the dependency lines (which seems to me to be the only real purpose of the APKBUILD that I saw in the two PRs).

16

Yes, on first look, they seem to be fine and we can merge them when you open a PR to our development branch. One minor nitpick, though:

FILE* fp

should be

FILE *fp

because the star applies to the variable, not the type. It is not only the kernel coding style, but also reduces misunderstandings. Assume the following example:

int* a,b;

What does this actually define? A pointer a but a regular integer b. One might have expected int* to be a type and both being a pointer. If you'd have written

int *a,b;

what actually happens is more obvious. And when you wanted two pointers, you'd anyway have to write

int *a, *b;

(disclaimer: I am currently swamped with work and am only commenting on this one aspect - I have not read the entire discussion here!).

17

Oh yeah that makes sense and does seem a bit more clean. I've fixed it in my patches. I'll split these into 3 PRs (since they're really three separate pieces of functionality) and submit them. Thanks!

18

We end up getting in to the never-ending debate on linux FHS and which distro is the one true way.

The problem I have with packaging is the additional overhead and policy decisions that have to be made by people outside of Pi-hole. I think it's a major reason that a lot of software packages have eschewed apt or apk or dnf and external repositories.

Arch maintains their own scripts and their own support of their scripts. Making massive changes like moving file locations is done at the major release level and breaking changes.

19

FHS can be a bit of a bikeshed that I don't feel too terribly pedantic about. That being said, most distros use it as a baseline so ensuring that a piece of software can at least be configured to change paths seems reasonable even if the upstream project had differences of opinions about what those defaults should be. IMO Pi-hole does pretty reasonable things with their default paths and my patches for the most part just allow someone to override them at build time.

Hopefully packaging for Alpine is minimally invasive. It doesn't have the large bureaucracies that are found in other distros. As a downstream maintainer I'm definitely happy to work to make sure there's minimal impact on the upstream project.

The Arch scripts seem reasonable but I would prefer to stick closer to FHS in Alpine because that's what other packages do and thus is prevents fewer surprises for users accustomed to those conventions. If you're willing to merge my config options in CMake I think we can get the best of both; no current paths change but Alpine can override them to FHS downstream.

20

I think this would be possible. Feel free to open a PR

21

The changes that Arch makes in the AUR include nerfing the debug process and warning that all issues need to be opened and addressed with the AUR maintainers. That needs to happen with Alpine as well.

My goal is to have Pi-hole run on Alpine and it basically does at this point. If you or another user would like to take on the support burden that goes along with changing paths and modifying scripts or binaries then that's great but that burden needs to be on them, not on the volunteer Pi-hole support team.

1 Like