tell me the most ass over backward shit you do to keep your system chugging?
here’s mine:
sway struggles with my dual monitors, when my screen powers off and back on it causes sway to crash.
system service ‘switch-to-tty1.service’

[Unit]
Description=Switch to tty1 on resume
After=suspend.target

[Service]
Type=simple
ExecStart=/usr/local/bin/switch-to-tty1.sh

[Install]
WantedBy=suspend.target

‘switch-to-tty1.service’ executes ‘/usr/local/bin/switch-to-tty1.sh’ and send user to tty1

#!/bin/bash
# Switch to tty1
chvt 1

.bashrc login from tty1 then kicks user to tty2 and logs out tty1.

if [[ "$(tty)" == "/dev/tty1" ]]; then
    chvt 2
    logout
fi

also tty2 is blocked from keyboard inputs (Alt+Ctrl+F2) so its a somewhat secure lock-screen which on sway lock-screen aren’t great.

  • dosse91@lemmy.trippy.pizza
    42·
    4 months ago

    I think this one beats them all.

    My home server keeps a few services up, including an instance of Jitsi Meet. The server runs nixos and the nixos package for jitsi is incomplete to say the least and doesn’t even support authentication, so I use the docker-compose version and I have a script that runs periodically to keep it updated. So far so good, right? Well, no.

    Because the server is at home, I have a dynamic external IP address, so I have to use a DDNS provider, but jitsi doesn’t expect this and uses a stun server at startup to determine the public IP of the server once, so if my connection goes down or is restarted and the IP changes, jitsi needs to be restarted or it won’t work anymore.

    The solution?

    • My router runs OpenWrt, so I am able to run a script that checks for external IP changes. When a change is detected, it uses SSH to connect to my server to restart jitsi
    • Because I don’t want the router to just be able to run any command, I created a jitsi-restart user that has no shell
    • When the router tries to log in with its pubkey, sshd creates a file called restartasap in the jitsi folder and closes the connection
    • On the server, there’s a systemd unit running a script as the jitsi user that periodically checks for that file, and if it exists it deletes it and restarts jitsi

    I’ve been running this setup since mid 2020 and I expect this to continue until IPv6 becomes the norm.

      • dosse91@lemmy.trippy.pizza
        2·
        4 months ago

        The jitsi user is a system user so it can’t login even if you set a key for it. Besides, I wouldn’t risk it anyway since that user is in the docker group, if it gets compromised somehow, the attacker would have very high privileges.