Installation on a RPi is pretty easy and straight-forward. I can't seem to find ANY kind of documentation on how to install the software manually. What are the actual system requirements? What privileges are needed to do the install? To run the daemon?
While I'm probably capable of 'reverse engineering' the process and such from code and/or README type files, I'm looking for something that's already documented. Anyone have a link to something?
TIA!!!
The installation is very complex, which is why our installer does most of the work. You may also want to read how Pi-hole™ was originally made as a guide to setting it up from scratch.
root access since we install several system-wide services including DNS and a Web server.
I can appreciate it being a complex design of sorts, but the install requirements seem extremely simple.
Web Server: Whether on a RPi or something else, it would seem that having a choice of using a stock http daemon with a specific configuration or using the lighttpd from pi-hole should be a choice somewhere along the line. When I installed this on a RPi, I reconfigured the lighttpd to listen on 8080 and access the admin page using the default web server. For me, this is extra resources being chewed up that don't need to be.
DNS Server: Using the dnsmasq utility provides some flexibility here, I'm sure, but using a stock DNS server (BIND, available on just about every linux distro) should work too. And, in environments like mine where I have an extensive in-house network that leverages DNS, I can't just point everything to the RPi install and have everything work without rebuilding DNS "over there".
root access for install sounds about right, what about permissions for the daemon?
512MB RAM needed for the total system, or available to pi-hole? How much does it take advantage of cacheing?
You've listed some specific distros that pi-hole can be installed on but didn't link to any docs. Should I presume that they all use the install script?
Why couldn't I simply make a config change to my DNS to support a specific file of blacklist domains, create a cron job to download the current lists, pass them through a parser like you've written to standardize the format, and implement a "catch-all" host on my existing web server to serve up the blank content to replace ads?
The work that has been put into creating this standardized installer / distro of the pi-hole solution has its obvious benefits. But, wouldn't this reach a MUCH larger audience if it were thought of and offered as more of a "Service" and not just a "Product"? The installer works very well, but is limited in where it can be used. Having a more flexible method of leveraging what pi-hole does instead of only offering it to the small community of folks with RPi's (and some with other Debian-based boxes) seems like it's limiting the potential user base.
To be blunt, I don't use Debian and have two decades of experience managing a couple of other distro's that I stick with because they lend themselves better to the commercial world. With the other BSD-based systems that I manage, I kind of have my plate full on keeping track of differences between systems already. 
Yes. At it's core, Pi-hole™ is just a DNS server with a Web server for the front end. The same thing could be accomplished with any DNS server and any Web server. dnsmasq and lighttpd are very fast and perform well, even on small systems.
Pi-hole isn't a daemon itself--it takes advantage of the dnsmasq and lighttpd daemons, so whatever permissions those have is what Pi-hole needs.
512 on the system should suffice. Pi-hole is very low on resource usage, so other software can run along side it.
Pi-hole caches 10,000 queries, which is the limit of dnsmasq
What sort of docs are you referring to? Our install script is designed to run on these systems. The nice thing about this method is we do not need a different package for each package manager (rpm, apt, etc.).
This is also what makes the installation straightforward for most users because they can run the command on a supported system, answer a few questions, and have a fully-functioning DNS server in a matter of minutes.
You can. And if you have enough knowledge to do that, you probably don't need us. But you likely won't be able to get a functional DNS server up and running in a few minutes if you were to manually install and configure each component yourself. This is where our installer shines.
In addition, Pi-hole's Web interface has a lot of settings and features that work with the DNS backend, many of which would normally require some technical changes to a config file.
In some ways, yes, you are correct. But with the right coding, it can be used on anything that can run a shell script.
Pi-hole has it's origins on the Raspberry Pi, but we have evolved to support several other distros.[quote="ember1205, post:3, topic:2458"]
To be blunt, I don't use Debian and have two decades of experience managing a couple of other distro's that I stick with because they lend themselves better to the commercial world
[/quote]
The nice thing about software is that you do have a choice. If you like Pi-hole, use it. If you don't, use something else.
We (the developers) are building a product we want to use. It won't be for everyone, but we make it freely available to anyone who wants to try it out. And since we are open source, Pi-hole can be forked to work elsewhere or you can submit pull requests to our repo to make it part of the main project.
i got it working on apple tv 1 with osmc happy testing
Good info. Thanks.
Is there any documentation on how to -uninstall- the product should I want to, say move it to a different RPi?
You can run pihole uninstall. Before doing that, if you want to copy your whitelist, blacklist, or adlists over to a new install, simply use the Pi-hole Teleporter option in the web interface settings.
I successfully installed Pi-hole on a thin VM with Alpine Linux (Virtual), here are the steps I took to do so, you should be able to adapt those to install to any compatible Linux distro:
Pi-hole FTL installation: pihole-ftl_installation.txt (1.6 KB)
If you're installing on Alpine Linux, first follow the steps to setup Nginx with PHP 7: https://wiki.alpinelinux.org/wiki/Nginx_with_PHP#Nginx_with_PHP7
If you're installing on another Linux distro with systemd, you can grab systemd compatible service files from: https://aur.archlinux.org/packages/pi-hole-ftl
Pi-hole AdminLTE installation: pihole_installation.txt (4.3 KB)
For some reason, on Alpine Linux, the sudo would keep asking for a password when executed from PHP, which would break the admin panel's functionalities, unless I specified ALL applications...
Which means there is no reason that the official Pi-hole Docker image to use Debian as a base, I hope they will switch to Alpine in the future since it has a lot less overhead. 
Just for the webserver, you can skip its install by saying "no" at the related installer question or --disable-install-webserver and then serve the web interface via any other webserver. Check the official lighttpd.conf for some useful settings (none are required, some are security related) and setup PHP with intl json xml and sqlite3 modules + add webserver user to pihole group to allow query database access.
I agree with the suggestion that offering Pi-hole as a service would have several benefits. E.g. comparing with Nextcloud which just has a full documentation about what is needed and admins are at their own to flexibly set it up as required and reasonable on the own environment. However, the downside is as clear, as the setup requires quite some knowledge and time, which is why many users use compete appliances which then again ship a moreless fixed environment with limited flexibility. A large difference as well is that the Pi-hole team offers full free end-user support here in the forum, which in turn requires an aligned setup across users to work. On Nextcloud you have to hope for the community or pay, as devs do zero free user support. It's simply two completely different approaches about how software is provided and Pi-hole made the choice to offer it as a free compete product ready to run in minutes without much technical knowledge and the related limited flexibility that this implies.
However I agree that a broader documentation would be great to give all required information for advanced use-cases to set it up manually, at least partly. But this will be a community task for sure 
. A bid of a problem is that Pi-hole lays out its scripts at quite a few different locations, which makes the manual setup more complicated: /etc/.pihole for the raw Git repo, from what as well some scripts, at least the installer (for updates + repair) and uninstaller, are called. Most scripts are however copied the /opt/pihole and calling each other from there, then you have configs at /etc/pihole (that is pretty fine) the main pihole script at /usr/local/bin but the FTL binary (dnsmasq fork) at /usr/bin, the web UI + blocking page of course at /var/www/html/admin|pihole, probably I forgot some. And the web UI + pihole command (related scripts) require all files at exact that locations to function correctly (all features). Also updating calls the installer or otherwise a constantly maintained own method is required. It is not one directory you copy (or git clone) at any location with all internal references being relative to that dir. So currently Pi-hole is not really designed for fully flexible setup as long as you want to keep web UI and CLI functionality.
Well, why do you download the patched version for ArchLinux? I see that the Pi-hole team compiles a binary they call x86_64-musl which is actually compiling on alpine:3.10 using their automated CI system.
Maybe reduce complexity by just using their source code. Or is there something special in ArchLinux repositories which makes this work while the official code does not? I'm confused.
I don't, I only use those to get certain files, like pihole-FTL.conf, pihole-FTL.db & nginx.conf, that's it. Everything else comes from the official Pi-hole github.
You don't have to use them if you want to use LightHttpD instead of Nginx
This almost works with just a copy and paste. I had to add a /etc/pihole/setupVars.conf and replace the default nginx.conf to remove the default server and include the pi-hole.conf. Other than that this was well-crafted setup scripts.
I have not connected it to my network yet so I don't know if it's working. I am trying to automate the setup to work as a Proxmox LXC deployment in my project WorldBuilder
Which Alpine version did you use? I've followed your steps on Alpine 3.13.4 and was not able to start the service
FATAL: create_shm(): Failed to create_shm shared memory object "/FTL-lock": No such file or directory
I don't remember exactly, but I think it had to be 3.11 or 3.12
3.12 gives me the same error. I'm using lxd containers by the way. I'd like to replicate your setup, do you remember details on the vm setup maybe?
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.