Daily automated turning on and off of adlist (for blocking Facebook)

The issue I am facing:
API question. I understand the Pihole web gui well enough, and I know how to create cron jobs on the command line. But I'm new to the world of APIs.

I found a list of Facebook servers to block in pihole (as an "Adlist"; I enter that URL into "Adlists" -> "Address:" textbox, "Comment:" is "Facebook" -> then I update the gravity list).

I really like how I can enable and disable the slider for this Adlist manually. But how to automate that daily? I want to selectively disable and enable one adlist (for Facebook), but leave the default adlist permanently enabled (for blocking Ads). Can the API allow that?

Say a household wants to keep the kids off Facebook from 7:30pm to 9pm daily, to get some quality family time instead?

Can anyone give me a quick clue as to how to use the API, from the crontab on the pihole, to accomplish this?

Details about my system:

What I have changed since installing Pi-hole:
Added my own Adlists, for different social media sites.

I've used the approach detailed in the post below. That allows you to turn groups on and off with cron.

  • In Groups create a new group called Kids
  • In Adlists edit the Facebook adlist to remove it from the Default group and put it into just the Kids group
  • In Clients find the kids devices in Clients and click Add, then change their group so that they are in both Default and Kids groups

You can then turn the Kids group on and off as needed using the technique below.

  • All the normal devices get the usual blocking all the time from the Default group
  • All the kids devices get the usual blocking plus the Facebook blocking from the Kids group, because they are in both groups
  • Turning the Kids group on and off enables and disables the blocking from adlists in that group, which in this case is just that Facebook adlist
  • Use cron to enable the Kids group at 7:30pm and disable the Kids group at 9pm each day

[ You may be able to turn the list off and on directly using a similar technique, but the advantage of using Groups is that you can consolidate all blocking – lists, specific domains, regexes – related to this function in one place and enable/disable in one go. ]

1 Like

I was hoping to not need to have to put every device into a group, as it arrives, but rather do this to all devices (which come and go randomly, changing considerably over time, like say if the kid's schoolmates come over for a visit, and bring their own devices).

If I'm going to reach into sqlite and manipulate it directly (and not go through an API call), would it be advisable to temporarily lock the database, by stopping the lighttpd systemd service temporarily? I don't have a sense of how concurrency-safe such a change as yours would be.

Furthermore, if I'm going into SQlite directly, then my sense is that I can also find the Facebook Adlist, and turn it on and off manually, just like the group can be enabled and disabled.

30 19 * * * /usr/bin/sqlite3 /etc/pihole/gravity.db "update 'adlist' set enabled = 1 where comment = 'Facebook'" ; /usr/local/bin/pihole restartdns 2>&1
0 21 * * * /usr/bin/sqlite3 /etc/pihole/gravity.db "update 'adlist' set enabled = 0 where comment = 'Facebook'" ; /usr/local/bin/pihole restartdns 2>&1

OK, this works.

Note: I also have to schedule the wifi radio to turn of and on (as in, "/etc/init.d/network restart") over in my OpenWRT router at the same time, to force the wifi clients to renew their DHCP leases. This will force a flush of the DNS queries cached by Operating Systems like Linux and Android. Then a Browser page refresh (not just tapping the "Reload" button in Firefox or Chrome) on the clients will give results as expected.

1 Like

That's a good point; Groups are perhaps better for more pre-defined scenarios. You can mix and match both approaches as needed.

As far as I know it's the same effect as clicking the Enabled/Disabled button on that adlist, group, domain, etc, so no special database prep needed.

Thanks, that's useful to know for future visitors searching how to do this.

1 Like

Glad you've got that working (not least because you have included your OpenWRT router in the solution in a creative way :wink: ).

I'll just add my general note that Pi-hole is not a parental control system.
It is a DNS filter.
As such, it relies on the explicit intention of its users to filter DNS requests.

By-passing it is as easy as manually configuring a public DNS server on a device or switching from wifi to mobile network on a tablet or smartphone (and your kids ar going to find out sooner or later :wink: ).

Even if DNS isn't by-passed, client-side DNS caching (which is not uncommon) may permit access to some sites for as long as a DNS reply stays in the client cache, which may be much longer than you intend to allow.

All in all, DNS filtering by itself wouldn't be sufficient to excercise parental control on your kid's devices.
You should consider other network-side measures as well as in-built parental control support of certain OSs.

Pi-hole could be used that way if you'd consider putting your kid-specific block in Pi-hole's Default group, and use specific groups for other blocking intents.

2 Likes

Thanks for the comments, everyone. I'm taking a closer look at what OpenWRT can do, in the way of actual firewalling. It doesn't have an inbuilt "Parental controls" feature, per se, but I can can time-restrict access to the internet at large, based on the MAC addresses of each device that the kids can access. This obscure functionality is hidden way, way deep... in "Network" -> "Firewall" -> "Traffic Rules" -> "Add" button -> "Advanced Settings" -> "Source MAC address" -> then under the "Time Restrictions" tab, set up the desired Start and Stop times (of restriction) -> "Save" button -> "Save & Apply" button.

Maybe astute parents could have a little family meeting with the kids, and say to them upfront, something like this:

"Ok little Susie and Billy, you are spending too much time on Facebook. It's time for a family intervention to try to bring some moderation to your usage, to teach you how to bring balance to your online lives. The first thing we parents are going to do is just block Facebook from 7:30pm to 9pm every night (as in, using the Pihole-related cron jobs just above). If you get clever, and hand-edit your network settings, to circumvent these blockages, don't think we parents won't notice that! We parents can see whether your devices are using DHCP leases or not in the OpenWRT router (look in OpenWRT's "Status" -> "Overview" -> "Active DHCP leases" section, as well as "Associated Stations" section below that, to find wifi-connected devices which might have an IP, but NOT a DHCP lease to go with it. That's Susie and Billy circumventing the Pihole Adlist for Facebook. Furthermore, turn down the lease time to be short: like 1 hour. That's set in OpenWRT in "Network" -> "Interfaces" -> "Edit" button for the LAN interface -> "DHCP server" tab -> "General Setup" sub-tab -> "Lease Time:", set to 1h -> "Save" button -> "Save & Apply" button)

You must use the DHCP leases, Susie and Billy. If you don't, once we catch you, we parents will turn up the "dial of atonement" another notch. We'll create timed firewall rules (as above with the "Time Restrictions", based on MAC address) to block all your internet access from 7:30pm to 9pm - not just Facebook.

The more we catch you squirming in various ways to get around these measures, we'll just keep turning up the "dial of atonement" even more, as we catch you. We can make the "Time Restrictions" even larger, or, if we need to get heavy, even (gasp) turn off the wifi altogether (in OpenWRT, "Network" -> "Wireless" -> "Disable" button, "Save & Apply" button), thereby allowing wired devices only (force the kids to use a wired laptop right beside Daddy's desk, where he can easily shoulder-surf them), etc."

I think it can be made into a game of sorts, where the parents engage in these kinds of tit-for-tat measures to bring on increasing restrictions on the kids, if necessary. Then the kids are governed to stay within reasonable behavior, over the long run. Naturally, the kids see what they can get away with, then the parents catch them, and pare back their usage by cramping their style.

Edit: I cross-linked to this post over on the OpenWRT Discourse here.

FWIW: here's a neat trick to "Force All DNS Queries Through PiHole with OpenWRT".

DHCP leases are not significant/relevant here. (click for more)

DHCP has no control over DNS, it just may suggest a client OS to use a certain DNS resolver.
Independently, client software may be configured for alternate DNS resolvers in a multitude of ways, none of them requiring tampering with DHCP leases.

In addition, since some OSs started to enable MAC address randomisation for wifi access by default, without further measures you may not be able to identify your kid's devices by looking at MAC addresses alone.


Yes, having your router's firewall redirect port 53 traffic in your network does address one possibility of by-passing Pi-hole, and it makes sense to apply it - provided your router supports it.
But it does not address other kinds of by-passes which can be configured on a client, like forcing a browser's usage of DoH or a smartphone using DoT, or using a VPN.

This serves to demonstrate and underpin my previous statement:

Some parting thoughts, as this is now quickly moving further and further away from Pi-hole. ;) (click for more)

DNS blocks can play a (minor) part in parental control strategies, but they do not exactly lend themselves to time-based controls, and they won't obsolete other network-wide and on-device measures - and certainly neither non-technical, more important educational measures.

I personally believe that any such technical action you take is only a fraction as effective as face-to-face attention and direct conversation with your children.
I think you should do both - protect them while they are still too young, but also teach them how to fend for themselves as they grow older - which would mean explaining why you apply DNS filters, why it is a good idea to do so, and why they should vow they won't try to evade it.

It may make sense to agree on a solution for age-appropriate usage together with your kids, and additionally use Android's or Apple's on-board parental control tools, which can be used to implement device-related (and not only home network-related) security.
The disadvantage of this is that the necessary linking of accounts means that family relations and other individual data must also be disclosed to the respective providers.


Further discussion may be more well-suited for forums specialising in parental control. :slight_smile:

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.