Another hack … if you want it to show disabled for the disabled
[root@ipfire sbin]# diff -u rpz-metrics.orig rpz-metrics
--- rpz-metrics.orig 2025-02-06 13:11:24.664758395 -0600
+++ rpz-metrics 2025-02-06 15:09:13.047136262 -0600
@@ -105,9 +105,15 @@
# is this RPZ list active?
theActive="disabled"
- if grep --quiet "^${theName}\.rpz" <<< "${ucListAuthZones}"
+ line=$(grep "^${theName}\.rpz" <<< "${ucListAuthZones}")
+ if ( test -n "$line" )
then
- theActive="enabled"
+ if [[ $line =~ "no serial" ]];
+ then
+ theActive="disabled"
+ else
+ theActive="enabled"
+ fi
else
[[ "${rpzActive}" == enabled ]] && continue
fi
Probably not elegant or complete … just another hack. I’m sure you will find a proper solution by the time this makes into an official add-on.
Cheers, @jon and thanks for all the good work.
unfortunately this keeps the allow list as disabled in metrics when its enabled. the only true way to show the allow list and blacklist as enabled or disabled would be to read the /var/ipfire/dns/rpz/customlists.conf
below is the conf file with the whitelist disabled
with further research i find that the enabled/disabled does not matter for the zone files either because they are either there/not when enabled/disabled
technically if the zone file is enabled its shown in the metrics list. writing the code to show if the allow list/black list is enabled or not is more likely to be where this should go but if your looking at the WUI then that makes it null and void because the check boxes would let you know which state they are in…just my 2 cents
maybe take out the active column? (didnt fixed the spacing properly)
Thanks @jon for this very interesting add-on leveraging the Unbound RPZ feature, I hope it is going to be included in the standard IPFire installation soon. I would like to ask a question on how it relates to the Squid proxy for content filtering.
From what I know relying on the Squid proxy is the most effective content filtering approach, first of all because it can block website access attempts through direct IP address entering (which would bypass DNS altogether), but also for the reasons explained at section “Take advantage of the web proxy” of the Firewall configuration recommendations for IPFire users guide. Also see section “Blocking sites by using proxy servers” of the OpenWrt Parental Controls guide.
So my question is if the RPZ add-on would provide any benefits when used on top of the Squid proxy, or would only be useful when the Squid proxy is not used for whatever reason.
Short classification of the filtering/blocking features:
The proxy handles HTTP(S) traffic only. There content filtering ( Urlfilter ) can filter those connections only.
IP Adress Blocklists demand that the access is to (fixed) IP. The blocklists must contain all possible IPs for a certain FQDN, and must be up to date.
DNZ RPZ blocks on level of name resolution. Changing IPs are no problem, if the lists are updated frequently ( which is done automagically by unbound itself ).
All three types are based on external lists.
Cases 1 and 2 are well-known since years and the sources of lists are selected in an acknowledge manner by the core devs.
Case 3 is new to IPFire. There is much less experience with the quality of the various lists. First inspections show that unbound has some memory requirements, which are not negligible.
for everyone interestet on the topic here
i would like to give a recommendation for
an extraordinarily good read: https://lists.ipfire.org/development/02C0C954-80A6-4090-9056-EA114E8CB36B@ipfire.org/T/#t
Jon, many of us truly appreciate your hard work on RPZ. I can only hope that what, to me, sounded like a very harsh answer was simply due to time constraints, frustration with old projects, or perhaps even a case of talking past each other. I’m quite certain that, deep down, you all want the same thing—a well-functioning IPFire with features that users need and that work reliably.
And I truly believe your RPZ addon will contribute to that, but I’m worried that right now, you just feel like throwing everything in the trash. Please don’t—there are many of us who have been waiting for a solution like this.
Take a few deep breaths, and let’s try to look ahead.
Maybe you could ask as an example Bernhard if he can and would be willing to take the lead in discussing the way forward at the meeting on March 10? What features do they want to offer, and what do they not want to offer? Then we can get a clearer idea of the next steps. First, an entry for the Roadmap? What steps come after that, so we can move forward gradually, step by step?
No matter what Jon, please know that we truly value everything you do. Your work makes a real difference, and we appreciate it more than you know. Hang in there Jon!
@jon
good to see you are still alive and kicking
did you notice the loss of information:
-- links below jump to the message on this page --
2025-02-06 16:35 [PATCH] RPZ: update code to include WEBGUI and additional languages Jon Murphy
2025-02-06 19:35 ` Bernhard Bitsch
2025-02-06 20:13 ` Michael Tremer
2025-02-08 18:41 ` jon
2025-02-08 19:27 ` Michael Tremer
[not found] ` <C28A0D7E-6C16-4F6F-9366-A8498F40631E@ipfire.org>
2025-02-14 12:07 ` Michael Tremer
2025-02-14 12:58 ` Bernhard Bitsch
2025-02-14 13:52 ` Michael Tremer
2025-02-14 14:16 ` Bernhard Bitsch
2025-03-01 10:18 ` Adolf Belka
[not found] ` <3BF29525-C9F4-4FD2-834D-FBE791E99E8C@ipfire.org>
2025-03-02 10:51 ` Adolf Belka
2025-03-10 17:47 ` jon
