pi-hole and ConsolePi don't coexist about consolepi HOT 8 CLOSED

Good Point, That's something I already had on my list, The readme already instructs users to use dnsmasq.d for DHCP reservations (i.e. for Tasmota outlets). I have a wired-dhcp feature in the works that will pull all of it's config from outside of the main dnsmasq.conf.

For now the original PiHole configuration should be backed up in /etc/ConsolePi/bak. You can restore the pertinent details or restore it entirely and if using AutoHotSpot place those bits in dnsmasq.d as suggested. Then touch /etc/ConsolePi/src/overrides/dnsmasq.conf ... placing a file with the same name in the overrides directory tells the upgrade script not to evaluate that file/ leave it alone.

FYI: I'm close to merging a pretty major update, but it'll essentially require Raspbian Buster for the full menu mdns discovery of remotes, etc. The requirement is actually Python ver >= 3.6, where stretch is 3.5 ... so Buster.

from consolepi.

UPDATE: I think we'll want this to be a completely separate systemd unit file, and separate config dir. I'll do some testing, but the issue I see is... AutoHotspot controls start/stop of dnsmasq currently. It's not enabled on startup, for PiHole you want it running all the time. For AutoHotSpot we want dhcp disabled on the WLAN interface... So I'll test with moving all of the autohotspot specific config to a folder within /etc/ConsolePi then creating a separate service and putting the appropriate checks in the upgrade script to ensure the main dnsmasq.conf and the ConsolePi specific settings for autohotspot don't conflict.

The pending update on the dev branch does add an option to disable autohotspot functionality.
To do this manually for now you would just sudo systemctl disable autohotspot Then the hotspot script won't run on boot, so it won't attempt to start/stop dnsmasq (it stops it if it finds an SSID to connect to as a client)

from consolepi.

This is now implemented in the dev branch, which I'll be merging into master in the near future. It won't change anything if it was already deployed the old way, but on new installs -or- if you restore the backed up dnsmasq it will deploy a new systemd file (consolepi-autohotspot-dhcp) along with 01-consolepi in dnsmasq.d. The latter ensures the default instance of dnsmasq excludes wlan0. You can then have 2 independent services.

The only thing I'm not sure about because I don't run PiHole on an actual Pi, is if a user on the HotSpot would still resolve to the resolver PiHole is impacting. In order to have 2 independent services (which we need in this case, because you'd want dnsmasq running all the time if you are running PiHole, and the dhcp for autohotspot only runs when wifi can't find an SSID to connect to and falls back to hotspot)... In order to make that happen the dhcp service for autohotspot excludes the loopback (I leave that bound to the system default dnsmasq instance)

from consolepi.

I'm happy to test if you can point me to a deployment script that includes these changes.

Deleting /etc/ConsolePi should be enough to restore my system or do you suggest a new buster image?

Thanks for working on this.

from consolepi.

If you replace the dnsmasq file ConsolePi deployed during install (revert to the original backed up to bak dir) you should be able to run consolepi-upgrade which will determine the dnsmasq.conf is not the one created by ConsolePi... so it will deploy using the new method.

I know upgrade is giving you issues per #55 but expect that to resolve once group membership is rectified on the new user.

from consolepi.

I'll rescue a on-duty RPi one of these days to play with the dev branch. As indicated in #56, I'm looking for a similar configuration that can live alongside other apps.

Thanks.

from consolepi.

no need to tinker with the dev branch all of the new changes have been merged into the master. So you should be able to restore your original dnsmasq.conf from the bak dir and run consolepi-upgrade and it will use the new autohotspot specific instance of dnsmasq. The only thing it does with the default instance is add options:
except-interface=wlan0
bind-interfaces
added via file in dnsmasq.d so it shouldn't break anything previously configured.

re #56 The installer will eventually be enhanced to prompt for the option to create additional users, with appropriate group membership, in addition to modifying existing users if any have been created. I've tested it locally, just haven't added it to the install script yet.

from consolepi.

Latest merge prompts user for consolepi user (change in behavior vs. previously just configuring consolepi group), and any additional custom users they desire... configures with correct perms to work with consolepi. It'll be up to the user to delete the pi user, if they desire.

New Install Only For Upgrades you still need to do it manually per the docs (any users added need to be members of consolepi and dialout groups to work with ConsolePi)

from consolepi.