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.

  • The Doctor@beehaw.orgEnglish
    14·
    4 months ago

    Some years ago, I had a client with a really fucked up set of requirements:

    • Must run Gentoo Linux. (No, I don’t know why. But it was written into the project specs and everybody who had to sign off did.)
    • Must use LUKS for FDE.
    • Login (loosely interpreted as “booting up”) must have MFA.

    This was during the days when booting into a LUKS encrypted Gentoo install involved copy-and-pasting a shell script out of the Gentoo wiki and adding it to the initrd. I want to say late 2006 or early 2007.

    I remember creating a /boot partition, a tiny little LUKS partition (512 megs, at most) after it, and the rest of the drive was the LUKS encrypted root partition. The encrypted root partition had a randomly generated keyfile as its unlocker; it was symmetrically encrypted using gnupg and a passphrase before being stored in the tiny partition. The tiny partition had a passphrase to unlock it. gnupg was in the initrd. I think the workflow went something like this:

    • System boots up.
    • Script in the initrd prompted the user for the passphrase for the tiny LUKS partition. (first authentication step)
    • User entered passphrase.
    • Script in the initrd unlocked the tiny partition and prompted the user for the passphrase to decrypt the root partition’s keyfile stored therein.
    • User entered the symmetric passphrase for keyfile. (second authentication step_
    • Script used the passphrase to decrypt the keyfile to stdout, piped into an evocation of cryptsetup to unlock the root partition.
    • /dev/mapper/root mounted, /boot mounted, boot process continued.
    • User logged into the box.

    I don’t miss those days.