this post was submitted on 21 Aug 2024
283 points (98.3% liked)

Linux

48287 readers
647 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] dosse91@lemmy.trippy.pizza 47 points 3 months ago* (last edited 3 months ago) (2 children)

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.

[–] princessnorah@lemmy.blahaj.zone 2 points 3 months ago (1 children)

why not just run the IP check script on the box jitsi is on? a quick google gave me this: dig +short myip.opendns.com @resolver1.opendns.com and this: wget -q -O - checkip.dyndns.org | sed -e 's/.\*Current IP Address: //' -e 's/<.\*$//'

[–] dosse91@lemmy.trippy.pizza 6 points 3 months ago (1 children)

I already had a script on the router that I used to notify me of network outages, IP changes, keep the DDNS updated, etc. and I thought it was easier to just add a couple lines to that

[–] Takios@discuss.tchncs.de 1 points 3 months ago (1 children)

Couldn't it be possible to set a script that restarts jitsi as that user's login shell?

[–] dosse91@lemmy.trippy.pizza 2 points 3 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.