I run pi-hole in a container on my proxmox and the OS of choice for me is Fedora. I tried to set up and run this version and had a bunch of issues. The main one is that setting capabilities to bind to 53 was failing, and hence pihole-FTL refused to start.
Given the limited time I have I just gave up and went back to master. However, if someone else with more time (perhaps one of the core devs) has a second to dive into a Fedora install and see what's up then that'd be awesome.
Hey @DL6ER, thanks for responding. Here's a subset of the output:
[root@pi-hole ~]# systemctl status pihole-FTL
● pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/rc.d/init.d/pihole-FTL; generated; vendor preset: disabled)
Active: inactive (dead) since Mon 2018-04-16 02:36:29 UTC; 6min ago
Docs: man:systemd-sysv-generator(8)
Process: 797 ExecStop=/etc/rc.d/init.d/pihole-FTL stop (code=exited, status=0/SUCCESS)
Apr 16 02:36:06 pi-hole pihole-FTL[604]: /etc/rc.d/init.d/pihole-FTL: line 37: which: command not found
Apr 16 02:36:06 pi-hole pihole-FTL[604]: unable to set CAP_SETFCAP effective capability: Operation not permitted
Apr 16 02:36:06 pi-hole pihole-FTL[604]: /etc/rc.d/init.d/pihole-FTL: line 38: /sbin/resolvconf: No such file or directory
Apr 16 02:36:06 pi-hole su[623]: (to pihole) root on none
Apr 16 02:36:06 pi-hole pihole-FTL[604]: dnsmasq: failed to create listening socket for port 53: Permission denied
Apr 16 02:36:06 pi-hole systemd[1]: Started LSB: pihole-FTL daemon.
Apr 16 02:36:29 pi-hole systemd[1]: pihole-FTL.service: Failed to reset devices.list: Operation not permitted
Apr 16 02:36:29 pi-hole systemd[1]: Stopping LSB: pihole-FTL daemon...
Apr 16 02:36:29 pi-hole pihole-FTL[797]: Not running
Note that if I run pihole-FTL debug directly from the command line as root, it works. If I run pihole-FTL directly without the debug parameter as root, it doesn't daemonize.
Re: proxmox -- no I don't think the environment can be blamed. Pihole master runs perfectly fine without any issues, it only breaks when I try to use this new branch.
Yes, you're correct, the architecture is x86_64.
Thanks again, sorry for not posting this information originally.
I still think it is a problem with proxmox, because of:
Note that there is a fundamental difference in the security concept we are using in FTLDNS compared to master. On master, we use dnsmasq which is started as root. With FTLDNS, we, however, don't want to do this! In contrast we start FTLDNS from an entirely unprivileged user (it couldn't even access the data from other users or change anything on the system!). However, we obviously have to grant the executable some permissions. Those are:
Binding to a port < 1024 (port 53 for DNS)
Network admin permissions (for being able to handle DHCP packets)
Raw network sockets (for creating ICMP sockets, needed for IPv6)
As things stand, it very much looks like proxmox (or your OS!) doesn't allow us to grant the executable these permissions (see your message above).