PiHole DNS not Responding, disk full
The Internet seemed unreachable at my house. After checking with the provider I determined it was due to my pihole being down.
Logging into the dashboard of my pihole showed "Lost Connection to API". This indicated an issue with the pihole-FTL service.
After logging in the Unify CloudKey where I installed pihole I used df -h to determined that the disk was full
root@UniFi-CloudKey:~# df -h Filesystem Size Used Avail Use% Mounted on aufs-root 2.9G 2.9G 0 100% / udev 10M 0 10M 0% /dev
It was due to 3 things:
apt cache at "/var/cache/apt/archives"
CloudKey backups at "/data/autobackup"
pihole-FTL database at "/etc/pihole/pihole-FTL.db"
You can cleanup the first using "apt-get autoclean". For the second, you can manually delete some of the old backups but perhaps you should set a better backup policy in your CloudKey.
The third one accumulates all the queries ever done against your pihole (18M in the past 2 years for me) unless you set something like MAXDBDAYS=90 in /etc/pihole/pihole-FTL.conf. Mine was 1.4GB.
You can stop the pihole-FTL with "service pihole-FTL stop", delete the file, and restart it, if you want. Or perform a more surgical cleaning directly deleting old entries from the database before restarting it.
2 notes
·
View notes
A follow up to Proxmox, PiHole and IPv6
So, per that post, I "needed" the IPv6 ULA addresses for PiHole.
Learning is growing, and growing is learning, and it turns out, you just flat out didn't need the IPv6 ULA addresses - I sussed this out as part of the great USG to UCG migration. These ULA addresses were done in config.gateway.json, which does not exist with the UCG line.
So back to these two jobs:
Tell PiHole where to send forwarded requests (in this case, the UCG)
Configure the network to use PiHole
Nice and easy!
Copy the UCG's Link-Local IPv6 Address and paste it in as an IPv6 forwarder
Copy the Link-Local IPv6 Address of the PiHole, and paste it in as the "DNS Servers" heading under the IPv6 DHCP settings. Ensure that the DNS "Auto" settings are not enabled to allow the DNS servers to be modified.
That's it! Easy! Done!
0 notes
Prepare for a lunar odyssey and celestial celebration in today's episode of Astronomy Daily - The Podcast. As we lift off into the vast unknown, we're tracking China's Chang'e 6 probe on its ambitious journey to the dark side of the moon to retrieve precious lunar material. We'll also marvel at the youthful origins of a moonlet orbiting the asteroid Dinkanish, discovered by NASA's Lucy mission. And hold tight as we count down to the launch of Boeing's Starliner, set for a historic crewed flight test that could herald a new era in space travel.Join us as we delve into the explosive beauty of solar flares with a recent X-class eruption that dazzled our solar observatory, and honor the trailblazing legacy of Eileen Collins with a collectible patch celebrating her achievements as the first female spacecraft commander. Plus, we're toasting to Astronauts Day, a tribute to the brave souls who venture into the cosmos, and unveiling the inaugural Astronaut Rockstar Awards.1. **Chang'e 6's Moonlit Mystery**: China's daring mission to the moon's far side.2. **Lucy's Young Moonlet**: Unveiling the age of asteroid companion, Selim.3. **Starliner's Stellar Ascent**: Boeing's crewed test flight to the ISS.4. **Solar Flare Spectacle**: The impact of an X-class eruption on Earth.5. **Commander Collins' Patch**: A symbol of shattered ceilings and space exploration.6. **Astronauts Day & Rockstar Awards**: Celebrating space heroes and their cultural impact.For an immersive experience of the cosmos, visit our website at astronomydaily.io, and join the stargazing community on X (@AstroDailyPod) for continuous updates and celestial conversations. Until our next stellar encounter, this is Steve reminding you to keep your eyes on the skies and your curiosity ever soaring. Clear skies and boundless wonder to all our fellow space enthusiasts!This episode is presented with the support of our cosmic companions at NordPass. Secure your interstellar journey with our special offer by visiting www.bitesz.com/nordpass. Support Astronomy Daily the Podcast and access the commercial-free episodes by checking out our supporter link.Become a supporter of this podcast: https://www.spreaker.com/podcast/astronomy-daily-the-podcast--5648921/support
And for more Space and Astronomy News, listen to past episodes, check out sponsor links etc...just visit our website at astronomydaily.io
0 notes
The not-so-great USG to UCG Migration
This post is about the big old move from Ubiquiti's EdgeOS based USG line to their new UnifiOS range at two sites. There were a few reasons for me doing this to myself;
Old/Legacy devices - the USG line was recently made "Legacy" by Ubiquiti - this has the obvious implications of it in the future no longer receiving security and feature updates
Complex to do anything not in the controller - I refer of course to "config.gateway.json". I'm sure some people love it, but frankly I hated it, and especially with one of my sites being remote, I dreaded making a change in that space because it may bring things down and throw me into a provisioning loop
Site Magic - Site Magic is the "new" way to do Auto IPSec VTI, and is instead done with WireGuard. It also means you don't have to do as many changes when a new site's added, and subnets can be added/removed from the "SD-WAN" as needed
Downsizing - I'm trying to downsize the presence of any on-prem equipment at one of the sites, and if it means I'm running a few less VMs and containers for VPN and a Unifi Controller, then it's a win in my book.
Power savings - The USG-Pro-4 has a max power consumption of 65W! Crazy! The UCG Ultra has a max of 6.2W, so much friendlier!
Beefier CPUs - The USG-Pro-4 didn't seem to be as much of a problem as the USG 3 here, but both were beginning to show their age a bit
Mostly feature parity - the things I used config.gateway.json for were more or less null/void after many years of updates to the UnifiOS platform. For example, Conditional DNS is now a thing in UnifiOS. I also didn't really have a need for virtual interfaces any more.
So the USG-Pro-4 is being replaced with the UCG-Ultra, and the USG-3 is being replaced with the UCG-Max
On with the fun!
First was the UCG Ultra.
And my gripes with this start with the fact that, there's no real clear documented process on moving from a USG on a self-hosted container - for all intents and purposes, it's just "backup and restore", which did not bear much fruit for me.
My trouble starts as below:
Take Settings Only backup and a Site Export and restore those to the UCG
-No good - the Controller just rotates the loading symbol and doesn't export the Settings Only backup. The Site Export works a treat, but the UCG won't import it
Try and SSH into the controller and get a copy of the generated Settings Only backup file
-No good - the UCG does not accept it
Use an older backup file which can be downloaded from the controller
-No good - when restored to the UCG, it restores as you would expect. But because in Unifi-land, you can only have one gateway per site, the UCG just doesn't work and essentially ignores the settings etc. in the backup file. The devices show, but the UCG itself does not act as if it's connected/part of the network, instead referencing a "Third-Party Gateway". Very confusing and the lack of doco on this was just bonkers
A power outage mid-restore
-Definitely no good. This happened mid-restore and didn't help as I'd left that site in an absolute state and had to talk someone through getting things back up and running with the USG-Pro-4
So I left this, and given the power was due to be back at 7pm the next day, I went to the other site, and attempted that.
I more or less encountered exactly the same, with the exception of, there was no power outage there. Bummer.
However, I did have some time, once things were up and running from Point 4, to investigate the issue with the Settings Only backup. Turns out, there was an older config.gateway.json file that was using incompatible characters in the file name. Once that was taken care of, the Settings Only backups started.
The next afternoon, I attempt to get this going again.
Armed with a working controller, I follow the below steps:
Take a Settings Only backup from the controller
Forget the USG-Pro-4 from the Controller and unplug it from power
Take another Settings Only backup from the controller
Ensure the UCG is connected from its WAN port into the modem, and connect the power. Leave the LAN connected to the device that's being used to connect
Set up the UCG as you see fit
Open the Unifi Network application on the UCG and restore the 2nd backup (from Step 3). As I was running Multi-Site, I was prompted to pick which site I wanted to restore from and confirm.
Give it 5 or so minutes, and restart the UCG
It should fire up using the original network details/IP addresses/range etc. as the original USG - confirm this is the case
Any additional Unifi Devices (Switches, APs, etc.) will show as offline - this is expected as they're still associated with the old controller.
Unplug the device you're working on from the UCG and back into the "old" network. Set a static IP and navigate back to the controller
In the settings, set "override set-inform host" to be the IP address of the UCG. The devices will show as Offline in the old controller.
Plug the device you're working on into the UCG, and plug the UCG into the LAN also. Devices should appear and show as adopting/provisioning.
That should be it - for me, things were cooking and working as expected, so I was glad that was it after that. Any changes etc. can be made and will be applied. I recommend taking a backup at this point also
So that's the UCG Ultra done. Sweet!
That night, I go to tackle the UCG Max. See below:
Navigate to the self-hosted controller and forget the USG 3. I didn't power mine down, but I did unplug the LAN/WAN
Take yet another Settings Only backup
Refer to the above steps for the UCG setup (4-9)
I note now that I have devices that aren't associated, but this time, not to any controller - strange. I SSH into the devices and set their set-inform to the Dynamic DNS host I have for the site where the self-hosted controller lies. No change, and they still don't show up in either controller
I re-SSH into the devices noting that of course, override set-inform was still set and overriding what I set in ssh... Hmm.
Navigate back to the controller, disable override set-inform
SSH into the devices, set the new set-inform URL
The UCG now showed the switches and APs, and all was fine and well with the world. I took a backup and now I can rest.
How tiring...
0 notes