for i in `pgrep -u $USER gnome-shell` ; do echo $i: ; cat /proc/$i/environ | tr '\0' '\n' | grep -E 'DISPLAY|XAUTHORITY' ; done
pripadne:
ps -C gnome-shell -o pid=
#
# asi pri vypnutem monitoru:
#
export DISPLAY=:1
export XAUTHORITY=/run/user/$(id -u $USER)/gdm/Xauthority
xrandr --query
xrandr --output DP-0 --off
sleep 2
xrandr --output DP-0 --auto
Viz https://www.tansi.org/hybrid/
The key is the option "write-mostly" passed to hdd.
mdadm --metadata=0.90 --create -n 2 -l 1 /dev/md1 /dev/ssd -W /dev/hdd
For an existing array, add a new ssd (after ssd failure)
mdadm --manage /dev/md0 --add /dev/sda1
--write-mostly is a per-member setting stored in the md metadata for that member device (and also maintained in-kernel while the device is in the array). It should survive on the hdd.
quote: You can enable "write-mostly" for a RAID component in the following way:
echo writemostly > /sys/block/md0/md/dev-hdd/state
and disable it this way:
echo -writemostly > /sys/block/md0/md/dev-hdd/state
(nicmene, po pridani noveho ssd disku se ve vypisu vlastnosti /dev/hdd write mostly ukazovalo. Teprve az po echo writemostly > ...)
(napsal GeminAI podle strucnych poznamek)
Upgraded to Ubuntu 24.04 LTS and saslauthd won't start, preventing Postfix authentication? The daemon is failing because it cannot reliably create its PID file in the default location while also being configured to place the socket inside Postfix's chroot (/var/spool/postfix/...).
The solution is to use a systemd override to force saslauthd to place its PID file in the same, accessible directory as its socket, and ensure it runs with the necessary group permissions.
Open the Override Editor:
sudo systemctl edit saslauthd.service
Add the Configuration Stanza:
Paste this into the editor to specify the correct PID location and the required sasl group:
[Service]
Group=sasl
PIDFile=/var/spool/postfix/var/run/saslauthd/saslauthd.pid
Restart Services:
Save the file, then restart to apply the fix:
sudo systemctl restart saslauthd
sudo systemctl restart postfix
This simple configuration adjustment resolves the conflict, allowing saslauthd to start successfully and communicate with Postfix inside its chroot.
(prispevek zformuloval GPT chatbot na zaklade mych velmi strucnych poznamek)
After a long-planned upgrade from Ubuntu 18 LTS straight to Ubuntu 24 LTS, I discovered that outgoing e-mail was no longer being signed with OpenDKIM. What followed was a small adventure involving masked services, silent failures, and a missing package. Here is the full story for anyone who runs into the same issue.
Right after the upgrade, outgoing mail lost its DKIM signatures.
A look into /var/log/mail.log showed a clear clue:
Port 8892, where OpenDKIM normally listens, was not responding:
So the DKIM milter was simply not running.
My next step was obvious: check the service.
Status confirmed it:
Why the upgrade masked the service is unclear, but unmasking is straightforward:
This time the service started—at least according to systemd.
But DKIM signatures were still missing.
To see what was going on, I enabled more verbose logging by adding to /etc/opendkim.conf:
After that:
The service looked healthy, no visible errors... but still no signs of DKIM signing.
Running locate gave the final hint:
It essentially returned nothing.
At this point it became clear: the service files were present, but the actual OpenDKIM binary was not installed (a side effect of the distribution jump).
A quick explicit install solved everything:
And — voilà — DKIM signing immediately started working again.
Upgrading directly from Ubuntu 18 → 24 can leave some services in a strange state. In my case:
opendkim.service was masked after the upgrade
The service files survived, but the binary package was missing
Postfix failed to talk to the milter (Connection refused)
Installing OpenDKIM manually restored full functionality
https://www.procustodibus.com/blog/2022/06/multi-hop-wireguard/#internet-gateway-as-a-spoke
routovani default routy skrz wireguard mezi peerama:
on the client, 172.20.24.15 set
wg0.conf
[Interface]
... Address = 172.20.24.15/32
[Peer]
... AllowedIPs = 0.0.0.0/0
ip route add wg_server_ip via 192.168.122.1 dev eth0
ip route add default via 172.20.24.10 dev wg0
on the gateway, 172.20.24.10
iptables -t nat -A POSTROUTING -s 172.20.24.0/24 -o vlan2 -j MASQUERADE
(a mozna i neco z toho:
iptables -t nat -A POSTROUTING -o oet1 -j MASQUERADE
iptables -A FORWARD -i oet1 ...?
)
(list: iptables -t nat -S POSTROUTING )
on the hub (wg server) 172.20.24.1
wg:
wg set wg2 peer rdwrtQdE7Z0SqZcJmoydFD74vXLLTnf+gk9go5pDWRw= allowed-ips 0.0.0.0/0 (namisto 172.20.24.10/24)
(klic je klienta gateway)
routing:
echo "123 wgfrompeer" >> /etc/iproute2/rt_tables #tim se nastavi jen jmeno
ip route add default via 172.20.24.10 dev wg2 table 123
ip rule add iif wg2 table 123 priority 100
(list: ip route show table 123 , ip rule show )
firewall:
# neco z tohodle:
sysctl -w net.ipv4.ip_forward=1 (to uz je zrejme jako default)
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wg2 -s 172.20.24.0/24 -j ACCEPT
iptables -I FORWARD -i wg2 -o wg2 -j ACCEPT
https://askubuntu.com/questions/1341909/file-browser-and-file-dialogs-take-a-long-time-to-open-or-fail-to-open-in-all-ap
Fast solution:
pkill gvfsd-trash
Brute force permanent solution:
mv /usr/libexec/gvfsd-trash{,.bak}