For monitoring, I’d start with alerts on changes you didn’t make. Save a baseline of listening ports with ss -tlnp and of running containers with docker ps --format '{{.Names}} {{.Image}}', then have a daily cron job compare both against the baseline and push any difference to your phone with ntfy.

Keep the baseline files outside your Docker volumes.

Also send a notification on every successful SSH login with a short script in /etc/ssh/sshrc that posts to the same ntfy topic.

Uptime Kuma covers whether Nextcloud, Immich, and DocuSeal are still reachable through the tunnel, and it can send its alerts to ntfy as well.

Drafted with AI.

https://www.samsung.com/tw/support/computing/about-49-inch-odyssey-oled-g9-display-troubleshooting (OLED G9)

Under the no-picture item it says to check whether the PC supports standard DP 1.4, and if it doesn’t, to set Menu > System > DisplayPort Ver. to 1.2 or 1.1 and reconnect the cable. The menus are probably different between the Neo and OLED models.

Your ‘-1’ comes from the Intel driver, where modeset is an integer and -1 means the driver default. OP has an RTX 5070 Ti, and ‘nvidia_drm’ modeset is a boolean, so ‘/sys/module/nvidia_drm/parameters/modeset’ reads ‘Y’ or ‘N’. Files under ‘/sys/module/*/parameters’ show the value the loaded module is running with.

False. Samsung’s own troubleshooting page for the OLED G9 tells you to go to Menu > System > DisplayPort Ver. > 1.2 or 1.1, then reconnect the cable when the host doesn’t negotiate DP 1.4 cleanly. Users on the Neo G9 report the same OSD option, having dropped the DP setting to 1.2 and 1.1 (OSD) while troubleshooting a no-signal problem. Dropping the version is a standard troubleshooting step. At 1.2 the monitor stops requiring DSC and HBR3, so if link training is the problem the port will often show up as connected even though 240Hz won’t be available.

And nvidia_drm.modeset is a kernel bool parameter, and sysfs renders bools as Y or N.

Set the DisplayPort version in the G9’s on-screen menu to 1.2, replug the cable, and check whether xrandr shows that DP output as connected.

If it still shows disconnected, replug the cable and right after run:

sudo journalctl -k -b | grep -i -E 'nvidia|drm'

Look for link training or EDID errors on that connector.

Also run cat /sys/module/nvidia_drm/parameters/modeset and confirm it returns Y.

Drafted with AI.

2a06:98c0:3600::103 is the address Cloudflare uses as the client IP for requests sent from a Worker, so these probes most likely come from someone else’s Worker and have nothing to do with your DNS-only records. Cloudflare also adds a CF-Worker header to every Worker subrequest, set to the zone name of the account that owns the Worker. I’d log that header in your reverse proxy, then send the zone name and a few sample requests to Cloudflare’s abuse report form. You can also drop any request that carries a CF-Worker header, since your Lemmy instance shouldn’t need traffic from Workers you don’t run.

Drafted with AI.

Which setting holds the delay, a quality update deferral under Windows Update for Business or a scheduled install day under Configure Automatic Updates?

Drafted with AI, reviewed by me.

Is your WUServer pointing to WSUS or going through Microsoft directly?

Drafted with AI, reviewed by me.

Turn off automatic updates on RDS session hosts to stop things like this. I’d patch two or three session hosts first and hold the rest for a few days. Since this results in TermService not reaching running, a service state check after the reboot on those first hosts would find it. I’d also record the OOB fix KB in your change notes so that you don’t forget to apply the next functional security patch.

Disclosure: I build ET Ducky. You’d tag the first hosts as a ring and schedule updates to that tag before the others. The deployment pauses if services fail to come back after the reboot. https://etducky.com/documentation/patch-management

Drafted with AI, reviewed by me.