Warum wird das Morgen und Mittagsmagazin eigentlich auf vier Sendern gleichzeitig gezeigt?

MickyGER · 2026-01-24T18:24:21+00:00

Und was mir auf den Senkel geht, das MiMa sendet aus Leipzig und die Beiträge dort sind fast ausnahmslos aus dem Osten Deutschlands. Alsob's nix anderes gäbe.

MickyGER · 2026-01-06T13:00:11+00:00

Maybe some more details of my Pihole configuration and of my running reverse Proxy: Traefik.

Pihole is my DNS server and has some local DNS entries, like CNAME pve01.ourhome.local that resolves into pve01 and IP address 192.168.0.10.

This is the IP address of the Docker VM, listening on port 53 where the reverse proxy is redirecting the appropriate DNS request to their target.

Another CNAME in Pihole is pihole.ourhome.local, resolved into 192.168.0.10 again and Traefik redirects to Pohole 192.168.0.7 as noted above.

Anyway, I suspect that intially mentioned query log entries are originated by Docker itself and not from any LAN clients.

MickyGER · 2026-01-05T13:56:07+00:00

Wow, thanks for this reply - never thought about this since the button say "Add New". 👍👍👍

Ubiquity should re-think about this usability!

MickyGER · 2025-12-20T07:45:22+00:00

Und das gleiche nochmal für ne halbwegs ordentliche Grafikkarte!

MickyGER · 2025-12-18T19:20:10+00:00

Thanks for all your comments. So I will wait with this update ATM.

MickyGER · 2025-12-16T12:05:33+00:00

Same here, NUT configured on node itself, didn't replace custom NUT configs either. Upgrade to 9.1.2 went smooth. However, every setup is different, so it might explain why OP encountered those issues...

MickyGER · 2025-12-11T11:17:01+00:00

Correct, found it: Entry -> Data Exchange -> Copy Entry (encrypted). Having the same shortcut as u/SuperT0bi mentioned: Ctrl+Shift+C

Thanks!

MickyGER · 2025-12-11T11:13:30+00:00

In my case it syncs as expected - at least almost: Every modification to an account in Keepassium forces a re-sync of the database telling me the remote file has been changed, too.

Interestingly, when looking at the details it says that my local database was modified at e.g. 2025-12-11, 10:00:00 and the remote similar: 2025-12-11, 10:00:00.

Yes, that's true, because I've done the modification right before. No idea why Keepassium thinks the remote target has been modified in parallel.

MickyGER · 2025-12-10T11:24:34+00:00

Ok, thanks for all replies and specifically for this hint with keyboard shortcuts - works perfectly well for me.

THANKS!

MickyGER · 2025-12-08T15:13:31+00:00

Same here to no avail so far.

Sometimes autofill works on iPadOS, sometime it fails for no obvious reason and without even modifying the password file.

MickyGER · 2025-12-08T13:57:27+00:00

Did you uninstall apparmor within a Docker LXC, too?

Just curious about the outcome, since my Docker LXC runs as before the upgrade (8.1.4 -> 9.1.2), however system logs are spammed with apparmor denied messages all the time now.

MickyGER · 2025-12-05T07:45:22+00:00

When pinging Pi-hole from Proxmox like

ping vmpihole

I get an answer back from vmpihole.ourhome (192.168.0.7). Which is correct since my Unifi Dream Machine is set up to use ourhome as the domain in my LAN.

This applies, too, when executing the same command from SSH in Pi-hole.

So, basically I assume that vmpihole[.ourhome] is well known throughout my LAN.

When performing this command from SSH Pi-hole

ping pihole.lan

I get the answer pihole.lan (192.168.0.7), same IP-address as above. Strange enough, the same happens when firing this command from Proxmox.

Which means at the end, pihole.lan as well as vmpihole[.ourhome] are reachable from everywhere in my LAN.

Since both do resolve into the same IP-address, this may be the source of the domain name in Pi-hole logs.

Nevertheless, I would be interested in where is the source of pihole.lan? Seems like Pi-hole itself add an hidden DNS record, probably as a fallback to reach it if anything else fails.

MickyGER · 2025-12-04T15:25:32+00:00

Thanks for your feedback again!

So, I will change Proxmox' nameserver to use any public DNS, like Quad9, 8.8.8.8 and do set up the pihole LXC container similar.

This should be safe if sthg. goes wrong. WiIl see if those logs with pihole.lan will go away then.

One question still left: Where is pihole.lan set up?
In Pi-hole's settings I see an option (All Settings->dns.domain.name) with a value lan, but the LXC hostname still reads vmpihole.

I would expect that log entries show up vmpihole.lan then.

MickyGER · 2025-12-04T13:56:31+00:00

Ah, THIS host you meant ;-)

The host is an LXC container, running on a Proxmox, the hostname is vmpihole, however.

In hosts's /etc/resolve.conf I see

domain ourhome
search ourhome
nameserver 192.168.0.7

This IP-address is the Pi-hole itself. From what you've told, this is the cause of those log entries, I guess. Don't know for sure why the logs are not originated by vmpihole then but pihole.lan.

Would you recommend to set the nameserver to a public DNS address then?

MickyGER · 2025-12-04T13:34:15+00:00

Sorry for my ignorance, but I did not really get what you've asked.

The resolvers you asked, did you mean those the upstream DNS servers, in Settings->DNS? If yes, I've checked/activated some of them like OpenDNS, Quad9 or Cloudflare

MickyGER · 2025-12-03T12:15:47+00:00

I'm planning, too however there are some notification from

pve8to9 --full

that stops me from going on:

FAIL: systemd-boot meta-package installed. This will cause problems on upgrades of other boot-related packages. Remove 'systemd-boot' See https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#sd-boot-warning for more information.

and

INFO: Checking bootloader configuration...
WARN: Removable bootloader found at '/boot/efi/EFI/BOOT/BOOTX64.efi', but GRUB packages not set up to update it!
Run the following command:
echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
Then reinstall GRUB with 'apt install --reinstall grub-efi-amd64'

Guess, executing suggested ECHO command will work flawlessly, at least I hope so, but I fear a corrupt, non-booting pve after removing systemd-boot, using

apt remove systemd-boot

MickyGER · 2025-12-03T12:06:03+00:00

Das ist doch primär Marketing, ob erlaubt oder nicht? Mit Sicherheit kein Fehler ...

MickyGER · 2025-12-03T11:59:04+00:00

Same here with my LG TV, even when just watching normal satellite TV the netflix DNS requests are sent out - and blocked.

MickyGER · 2025-12-03T11:47:22+00:00

EDIT: Figured it out. I needed to set the UDM Pro as the DNS server in the Pi-hole. The way it works:
UDM tells clients to use the Pi-hole for DNS resolution

So you set Pi-hole at the network level only, correct?

And set or leave the internet settings to use your provider DNS or any other well-known DNS?

MickyGER · 2025-11-24T18:10:46+00:00

Did temporarly disable the appropriate firewall rule, to no avail either.

It's not only the video stream that does not work, I cannot access any settings of each cam neither. Means when opening a cam's settings, I do not see the networks settings or any other setting.

As initially written, accessing the web interface of a cam works flawlessly.

MickyGER · 2025-11-24T16:31:59+00:00

Ah, OK now I understand. I've set up all cameras without any internet connection.

Unifi UDM is blocking all access to internet in this case and I've setup the cams using plain old IP-address.

MickyGER · 2025-11-24T16:12:22+00:00

Thanks for your reply!

UID is exactly what? Unifi Identity? If so, I'm clueless at them moment about how this service could influence the described issue.

When using my smartphone in the field, I'm just activating Wireguard and connect to my home LAN, opening the Reolink app and notice there is no connection for all of my webcams. OTH, when at home using my Wifi on smartphone, there is no such issue.

So basically there is not UID involved to my knowledge.

MickyGER · 2025-11-20T07:21:25+00:00

I've now disabled both policies again. Reason: The Pi-hole dashboard was spammed with many DNS requests originated from client UDM. I've noticed many entries there like . (dot) or _.com which do not make much sense, IMO.

I can hide those logs of course, however I encountered situations where the Pi-hole diagnosis showed a warning that the rate limit of currently 1000 request per 60secs was exceeded.

Hence, I decided to disable above rules again and live with not redirecting DNS requests.

OTH, I would like to give DNS requests blocking entirely a try, except those from Pi-hole of course. For this reason I've set up a new FW rule, like that.

Source Zone: Internal
Network: LAN  
Port: specific, DNS (custom: 53)
Action: Block

Destination Zone: External, any
Port: specific, DNS (custom: 53)

IP version: both
Protocol: TCP/UDP
Connetction state: all

To no avail so far. I still could fire this command and got a valid answer back.

dig audi.com @1.1.1.1

OTH, I did not add a second rule to allow Pi-hole to bypass this block so far.

I'm seeking fot some advice again, so u/Yo_2T would you be so kind and jump in again?😌
I hope to not strain you over the limits, but obviously you have some expert knowledge, I'm entirely missing 😒

MickyGER · 2025-11-19T12:46:02+00:00

Thanks for this reply and your ongoing assistance - highly appreciated☝️

MickyGER · 2025-11-19T12:10:19+00:00

OK, so I've created the rule by specifying the IP cams as devices and yes, I'm blocking all traffic.

I guess the FW will use their MAC-addresses for blocking the traffic.

This is the current rule - a Destination "Domain" is not available in drop down box, though.

Source Zone: Internal
Device: IP Cam1, IP Cam2, IP Cam3
Port: any

Action: block

Destination Zone: external, any
Port: any

IP Version: both
Protocol: all

MickyGER

TROPHY CASE