Feuerfest

Just the private blog of a Linux sysadmin

Blocking Googles AI answers in search results with uBlock Origin

If you have uBlock Origin installed as an extension in your browser there is a way to hide/block Googles AI answers.

  1. Click the uBlock Origin icon
  2. Click the button with the 3 wheels in the lower right
  3. Go to "My filters"
  4. Copy and paste the following into the field below: google.com##.hdzaWe
  5. Make sure the checkbox next to "Activate own filters" is set
  6. Hit "Apply changes" on top

Of course this only works until Google changes the name of the element, but if that happens there is usually a thread in https://www.reddit.com/r/uBlockOrigin/ with the new filter.

Or alternatively just put a swear word somewhere into your Google search query. Then the AI is also absent. 😂

Instead of: programname error-message
Google for: programname fucking error-message

😆

The udm=14 parameter

And the "cheat code" for AI free search with Google also still exists. Just add the udm=14 parameter.

https://tedium.co/2024/05/17/google-web-search-make-default/ has all the details and https://tenbluelinks.org shows you how to achieve that for various browsers.

Enjoy!

Comments

Termux and local DNS

The app Termux is an Android terminal emulator and provides an Linux environment. I have it installed on my phone to have many of the various command-line tools ready to use.

However, there is one big problem if you to have working local DNS resolution in your home network: Termux uses the Google DNS server 8.8.8.8 and 8.8.4.4 per-default. As this is a problem for many people, it is regularly discussed on GitHub: https://github.com/termux/termux-app/issues/130

And while I'm not having much expertise in regards to Android development it seems that Termux is not allowed to get the Android system DNS settings and hence can't properly update their resolv.conf whenever the DNS server changes.

Also it seems that some tools use the Android system DNS and others don't. nslookup for example uses the resolv.conf provided by Termux. This just adds to the confusion.

It doesn't matter if you've disabled private DNS in your network settings or not. As such they have little other choice but to ship their own resolv.conf file under /data/data/com.termux/files/usr/etc/resolv.conf with the Google DNS servers, which are also the default setting on Android:

~ $ cat /data/data/com.termux/files/usr/etc/resolv.conf
options timeout:2
options attempts:2
options rotate
nameserver 8.8.8.8
nameserver 8.8.4.4

My workaround

If I install vi (to have a useable editor) and edit the resolv.conf so that it only contains my local DNS server it works.

~ $ cat /data/data/com.termux/files/usr/etc/resolv.conf
options timeout:2
options attempts:2
options rotate
nameserver ip1.ip1.ip1.ip1
#nameserver 8.8.8.8
#nameserver 8.8.4.4

But the big downside is: As soon as my phone leaves my Wifi many things regarding Termux will simply stop working. I then have to change the resolv.conf back. Sure, it done easily and an easy script also comes to mind.. 

A more permanent and better solution?

Termux however has Unbound already installed. I could just add dnsmasq to the mix and configure it to send DNS queries for my local lan domain to my Pi-holes. This way the the resolv.conf can be left untouched.

Something like this should do the trick..

server=/lan/192.168.0.x

Has anyone already done that?

Others have come to different solutions

There is https://www.zenz-solutions.de/personaldnsfilter-wp/ which servers as a DNS filter for Android. And apparently one can somehow hook into the DNS resolution process on Android. Okayyy... Wild.

Comments

Pagerduty finally fixed Rundecks Java requirements

In my rant article Get the damn memo already: Java11 reached end-of-life years ago I used Pagerduty's product Rundeck as and example for heavily outdated software requirements, making it unable to be installed on many modern Linux distributions.

Looks like they finally got their things together:

As of version 5.10.0 the Self Hosted RBA and Rundeck Open Source support either Java 11 or Java 17 runtime (JRE).
Building from source still requires Java 11 (JDK).

https://docs.rundeck.com/docs/administration/install/system-requirements.html#java

In fact you want at least version 5.11.0 as version 5.10.0 still had the requirement for Java11 in the RPM- dependencies according to this Github issue: https://github.com/rundeck/rundeck/issues/8917

Finally!

Let's just hope they already have plans for Java 21 or even Java 25. As Java 21 support for Oracle already ended in September 2024. 😜

Comments

Using nebula-sync to synchronize your Pi-hole instances

As I have 2 running Pi-hole instances I have the problem of keeping them in sync. I do want all local DNS entries to be present on both. Also I do want the same filter lists, exceptions, etc.

Entering: nebula-sync. After Pi-hole released version 6 and made huge changes towards the architecture & API, the often used gravity-sync stopped working and was archived.

As nebula-sync can be run as a docker image the setup is fairly easy.

I just logged into my Portainer instance and spun up a new stack with the following YAML. I disable the gravity run after nebula-sync as this currently breaks the replica. The webserver process is killed and doesn't come back. Hence no connections to port 80 (HTTP) or 443 (HTTPS) are possible and therefore the API can't be reached either.

This is currently investigated/worked on in the following issue: Pi-hole FTL issue #2395: FTL takes 5 minutes to reboot?

---
services:
  nebula-sync:
    image: ghcr.io/lovelaze/nebula-sync:latest
    container_name: nebula-sync
    environment:
    - PRIMARY=http://ip1.ip1.ip1.ip1|password1
    - REPLICAS=http://ip2.ip2.ip2.ip2|password2
    - FULL_SYNC=true
    - RUN_GRAVITY=false   # running Gravity after sync breaks the replica, see: https://github.com/pi-hole/FTL/issues/2395
    - CRON=*/15 * * * *
    - TZ=Europe/Berlin

And if everything works we see the following:

2025-05-26T16:01:24Z INF Starting nebula-sync v0.11.0
2025-05-26T16:01:24Z INF Running sync mode=full replicas=1
2025-05-26T16:01:24Z INF Authenticating clients...
2025-05-26T16:01:25Z INF Syncing teleporters...
2025-05-26T16:01:25Z INF Syncing configs...
2025-05-26T16:01:25Z INF Running gravity...
2025-05-26T16:01:25Z INF Invalidating sessions...
2025-05-26T16:01:25Z INF Sync completed

When I did have RUN_GRAVITY=true in my stack I would always see the first sync succeeding. This run would however kill the webserver - hence the API isn't reachable any more and the nebula-sync container would only log the following error message:

2025-05-26T16:34:29Z INF Starting nebula-sync v0.11.0
2025-05-26T16:34:29Z INF Running sync mode=full replicas=1
2025-05-26T16:34:29Z INF Authenticating clients...
2025-05-26T16:34:31Z INF Syncing teleporters...
2025-05-26T16:34:31Z INF Syncing configs...
2025-05-26T16:34:31Z INF Running gravity...
2025-05-26T16:34:31Z INF Invalidating sessions...
2025-05-26T16:34:31Z INF Sync completed

2025-05-26T16:35:00Z INF Running sync mode=full replicas=1
2025-05-26T16:35:00Z INF Authenticating clients...
2025-05-26T16:35:02Z INF Invalidating sessions...
2025-05-26T16:35:04Z WRN Failed to invalidate session for target: http://ip2.ip2.ip2.ip2
2025-05-26T16:35:04Z ERR Sync failed error="authenticate: http://ip2.ip2.ip2.ip2/api/auth: Post \"http://ip2.ip2.ip2.ip2/api/auth\": dial tcp ip2.ip2.ip2.ip2:80: connect: connection refused"

Comments

Sweet memories

At one of my previous employers we were allowed to create our own groups in the Intranet portal. There I created a group called "Christian's curious cyber content cabaret" and renamed it to "Christian's curious Corona cyber content cabaret" during the pandemic years.

The image below is the header image from that group which - as far as I am informed - still exists today. Years after I left that company. Albeit nobody posts there anymore.

Comments

Installing Unbound as recursive DNS server on my PiHole

I run a Pi-hole installation on each of my Raspberry 3 & 4. As I do like to keep my DNS queries as much under my control as I can, I also installed Unbound to serve as recursive DNS server. This way all DNS queries will be handled by my Raspberry Pis.

Pi-hole is already installed using one of the following methods: https://github.com/pi-hole/pi-hole/#one-step-automated-install. If you don't have that done yet, do it first.

There is a good guide at the Pi-hole website which I will basically following.

https://docs.pi-hole.net/guides/dns/unbound/

root@host:~# apt install unbound

Regarding the configuration file I go with the one in the guide. However as I did have some problems in that past I needed to troubleshoot I include the following lines regarding loglevels and verbosity:

root@host:~# head /etc/unbound/unbound.conf.d/pihole.conf
server:
    # If no logfile is specified, syslog is used
    logfile: "/var/log/unbound/unbound.log"
    val-log-level: 2
    # Default is 1
    #verbosity: 4
    verbosity: 1

    interface: 127.0.0.1
    port: 5335
root@host:~# 

You can add that if you want but it's not needed to make Unbound work.

Next the guide tells us to download the root hints. A file maintained by Internic which contains information about the 13 DNS root name servers. Under Debian we don't need to download the named.root file from Internic as shown in the guide. Debian has its own package for that: dns-root-data.

It no only contains information about the 13 DNS root name servers but also the needed DNSSEC keys (also called root trust anchors). And together with unattended-upgrades we even automate updating that. Saving us the creation of a Cronjob or systemd timer.

root@host:~# apt install dns-root-data

In order for Unbound to have a directory and logfile to write into we need to create that:

root@host:~# mkdir -p /var/log/unbound
root@host:~# touch /var/log/unbound/unbound.log
root@host:~# chown unbound /var/log/unbound/unbound.log

As we are running under Debian we now need to tweak the Unbound config a little bit. Else we will get problems with DNSSEC. For this we are deleting a Debian generated file from Unbound and comment out the unbound_conf= line in /etc/resolvconf.conf so that it isn't included anymore.

root@host:~# sed -Ei 's/^unbound_conf=/#unbound_conf=/' /etc/resolvconf.conf
root@host:~# rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

Now all that is left is restarting Unbound.

root@host:~# systemctl restart unbound.service

Testing DNS resolution:

root@host:~# dig pi-hole.net @127.0.0.1 -p 5335

; <<>> DiG 9.18.33-1~deb12u2-Raspbian <<>> pi-hole.net @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46191
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pi-hole.net.                   IN      A

;; ANSWER SECTION:
pi-hole.net.            300     IN      A       3.18.136.52

;; Query time: 169 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Sun May 25 18:21:25 CEST 2025
;; MSG SIZE  rcvd: 56

And to verify & falsify DNSSEC. This request must return an A-Record for dnssec.works.

root@host:~# dig dnssec.works @127.0.0.1 -p 5335

; <<>> DiG 9.18.33-1~deb12u2-Raspbian <<>> dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14076
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dnssec.works.                  IN      A

;; ANSWER SECTION:
dnssec.works.           3600    IN      A       46.23.92.212

;; Query time: 49 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Sun May 25 18:22:52 CEST 2025
;; MSG SIZE  rcvd: 57

This request will not result in an A-Record.

root@host:~# dig fail01.dnssec.works @127.0.0.1 -p 5335

; <<>> DiG 9.18.33-1~deb12u2-Raspbian <<>> fail01.dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1552
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;fail01.dnssec.works.           IN      A

;; Query time: 19 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Sun May 25 18:23:41 CEST 2025
;; MSG SIZE  rcvd: 48

Now all that is left to connect our Pi-hole with Unbound. Logon to your Pi-hole website and navigate to Settings -> DNS. Expand the line Custom DNS servers and enter to IP and Port to our Unbound server. 127.0.0.1#5335 for IPv4 and ::1#5335 for IPv6. If you don't use one of these two just don't add the line. After that hit "Save & Apply" and we are done.

Creating a logrotate config for Unbound

Sadly Unbound still doesn't deliver a logrotate config with its package. Therefore I just copy & paste from my previous article Howto properly split all logfile content based on timestamps - and realizing my own fallacy.

root@host:~# cat /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
        monthly
        missingok
        rotate 12
        compress
        delaycompress
        notifempty
        sharedscripts
        create 644
        postrotate
                /usr/sbin/unbound-control log_reopen
        endscript
}

Troubleshooting

fail01.dnssec.works timed out

The host fail01.dnssec.works tends to not answer requests sometimes. Others noticed this too. dig will only show the following message:

root@host:~# dig fail01.dnssec.works @127.0.0.1 -p 5335
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out

; <<>> DiG 9.18.33-1~deb12u2-Raspbian <<>> fail01.dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; no servers could be reached

If that is the case, just execute the command again. Usually it will work the second time. Or just wait a few minutes. Sometimes the line ;; communications error to 127.0.0.1#5335: timed out will be printed, but the dig query will work after that nonetheless.

Comments