I came across this last night and got a start on porting. There is still much to be done from the looks of things, but here is the progress I've made so far: GitHub - freqlabs/FTL at freebsd-wip
So reading a bit through the comments, I checked on a few things.
- gcc is available for FreeBSD (I installed it)
- I figured out how to force cmake to use it. It gets a slight bit farther.
- I removed -Werror from src/CMakeLists.txt
I am guessing trying to build it with gcc will be more useful than with clang? This is with the pi-hole archive, not the WIP version from freqlabs
My edits to the build.sh script:
# Configure build
mkdir -p cmake
cd cmake
#cmake ..
cmake -DCMAKE_C_COMPILER=/usr/local/bin/gcc ..
# Build the sources
#cmake --build . -- -j $(nproc)
cmake --build . -- -j 2
Now it gets here:
I do not know what sys/prctl.h does, is it in kernel headers?
~/FTL$ bash ./build.sh
-- The C compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/local/bin/gcc
-- Check for working C compiler: /usr/local/bin/gcc - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: /home/kgrider/FTL/cmake
Scanning dependencies of target database
[ 1%] Building C object src/database/CMakeFiles/database.dir/common.c.o
In file included from /home/kgrider/FTL/src/database/common.c:11:
/home/kgrider/FTL/src/FTL.h:35:10: fatal error: sys/prctl.h: No such file or directory
35 | #include <sys/prctl.h>
| ^~~~~~~~~~~~~
compilation terminated.
--- src/database/CMakeFiles/database.dir/common.c.o ---
*** [src/database/CMakeFiles/database.dir/common.c.o] Error code 1
make[2]: stopped in /usr/home/kgrider/FTL/cmake
1 error
make[2]: stopped in /usr/home/kgrider/FTL/cmake
--- src/database/CMakeFiles/database.dir/all ---
*** [src/database/CMakeFiles/database.dir/all] Error code 2
make[1]: stopped in /usr/home/kgrider/FTL/cmake
Scanning dependencies of target sqlite3
A failure has been detected in another branch of the parallel make
make[2]: stopped in /usr/home/kgrider/FTL/cmake
--- src/database/CMakeFiles/sqlite3.dir/all ---
*** [src/database/CMakeFiles/sqlite3.dir/all] Error code 2
make[1]: stopped in /usr/home/kgrider/FTL/cmake
2 errors
make[1]: stopped in /usr/home/kgrider/FTL/cmake
*** [all] Error code 2
make: stopped in /usr/home/kgrider/FTL/cmake
1 error
make: stopped in /usr/home/kgrider/FTL/cmake
So I found this:
https://www.netroby.com/view/3595
The headers I got were:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/11.3-RELEASE/src.txz
I installed the headers and looked for sys/prctl.h and found nothing like that. I expected it here:
/usr/src/sys/amd64/amd64. I have no idea if this is right or not.
There is a ton of Linux-specific stuff (such as prctl) in the code. Those parts will need to be properly abstracted and reimplemented.
Well, yes, because FTL is meant to be Linux-only. Everything else is experimental.
I'm not sure this is a good idea. I mean, well, it first sounds like one, but then, once this is done, it may limit us in what we can do because, for everything we add, we need to find not only a Linux-specific but also another method¹. And without having such a system floating around in all my development environments (partially mobile, partially fixed systems), it will become difficult.
Just to make this clear, it may stretch what we can do and even when we have the help to port some things over to FreeBSD, I'm not sure if we can always do this in the future (where adding new features may very well break FreeBSD compatibility once again).
We should discuss how to proceed. So far, my first thoughts are that it may actually be a better idea to have some fork from someone regularly using FreeBSD (looking at @freqlabs right now) for FreeBSD compatibility with some clear note somewhere that this is a user-maintained fork providing FreeBSD-compatibility. While the developers are aware of this and have nothing against this, it is still a side-project and debugging FreeBSD systems running code from this fork is out of the capabilities of the core team.
I mean, you get what I'm trying to say. Nothing bad, no show-stopper here, I'm just not convinced a flood of #if LINUX / #else / #endif all over the place will be maintainable in a way that is not limiting the future development of FTL. In the end, we're all just developing on Linux and I'm not even aware if something like the concept of capabilities does even exist in other operating systems while it is of crucial importance for Linux to allow FTL to run as a non-priviledged daemon. This is a security measure the fewest other codes do for you - doing everything as root is much simpler.
¹: I do apologize for many commas in one sentence.
Certainly, just warning what's in store for someone trying to port this to another platform.
To explain where I'm coming from, I'm not a pi-hole user. I am on the OS team at iXsystems (the developers of FreeNAS). I happened to see some guides for running pi-hole on FreeNAS. The method described running it in a VM, which seemed ridiculous given that jails are a much lighter weight way of installing third party software. But on looking deeper into it I discovered there is no FreeBSD port for pi-hole. Much reading about how "FreeNAS developers don't care" later, I ended up here.
I wanted to see how difficult it would be to port, and while it doesn't seem out of the question, it is not a trivial project. There doesn't seem to be much essential functionality that couldn't be implemented on FreeBSD. We have something like capabilities, called capsicum. We also have jails, so even if FTL had to run as root it could be done in a sandboxed environment without risk to the rest of the system.
That said, if the project isn't interested in FreeBSD support I don't intend to maintain a fork myself. This was a personal experiment, not something the FreeNAS project is actively pursuing, to my knowledge. The freebsd-wip branch I linked to is just how far I got in a night looking at the code to see why people were running it in VMs instead of jails. I'll probably continue hacking on it a bit more in my free time until I get distracted by something else. If someone else picks up that work and stays on top of it when I'm done, then great.
My branch builds and runs on FreeBSD now, but I haven't ported the tests. I just stubbed out the capabilities check for now since that is the main non-trivial part but it isn't strictly necessary. I may try getting the full set of tests to run, but a few manually tested basic DNS queries are working at least.
2 Likes
Have you updated your git? I just tried by first running 'bash ./build.sh' and go no further then made the edit to use gcc and tried again and got just as far as I had previously?
Can you give some instructions so I can build it as well?
Yes my github repo is up to date. Don't need to install gcc or bash, I think you need a library or two installed, like libidn, but just ./build.sh works.
You need to check out the freebsd-wip branch, though. It's not the default branch.
If there's any needs for testing environments I can provide DigitalOcean droplets for use.
Thanks the git is built. Now to continue my script checking. The script fixes I have made so far will work on both systems. I do not have time today to mess further, but thanks for the leg up!
Please let's keep this positive. It looks like this part came together in just a few days. Personally, I think this project will be quite interesting for the FreeBSD folks and am sure someone will take it up. After all, pfsense runs on freebsd and this a lot of sense for pfsense, IMO.
Just in case it could be useful to anyone here, I managed to install Pi-hole on a thin Alpine Linux VM in FreeNAS/TrueNAS Core: Install on "non-supported" distro? - #8 by malbeth
Hi,
Any news with such great feature?
I would add one more vote, my vote, for FreeBSD support.
Another to add to this request please!
Add me to the list as well.
Hi guys, have you had any update on this? 
No.
@Whisky Im trying to get it to work. Wish I knew more about FreeBSD, so far I can run pi-hole FTL and the web interface but need to get a rc script in place to replace the init script used on linux.
Ill repost what I said in another topic,
Used @freqlabs github to build pi-ftl, it starts and listens on port 4117 and 53. Setup a caddy webserver to serve pi-admin files and copied pihoole to my bin directory.
I get a webpage with some errors about not being to open /proc/cpuinfo (which is fine) but it reports FTL service as not running. Does it check if the FTL file is in some path or just listening on port 4117 ? Maybe I missed some config file. Otherwise the web interface is working.
I've been playing with the work done by @freqlabs and created an initial attempt for a freebsd port: GitHub - exeba/FTL-freebsd-port: FreeBSD port of pihole-FTL
So far I've tested only DNS capabilities and it seems to work.
For the GUI part you can try the freebsd branch on GitHub - exeba/AdminLTE: Pi-hole Dashboard for stats and more
Help & Feedback is very welcome
2 Likes