• 0 Posts
  • 92 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle





  • Here’s one I have saved in my shell aliases.

    nscript() {
        local name="${1:-nscript-$(printf '%s' $(echo "$RANDOM" | md5sum) | cut -c 1-10)}"
        echo -e "#!/usr/bin/env bash\n#set -Eeuxo pipefail\nset -e" > ./"$name".sh && chmod +x ./"$name".sh && hx ./"$name".sh
    }
    alias nsh='nscript'
    

    Admittedly much more complicated than necessary, but it’s pretty full featured. first line constructs a filename for the new script from a generated 10 character random hash and prepends “nscript” and a user provided name.

    The second line writes out the shebang and a few oft used bash flags, makes the file executable and opens in in my editor (Helix in my case).

    The third line is just a shortened alias for the function.




  • How does the xz incident impacts the average user ?

    It doesn’t.

    Average person:

    • not running Debian sid, Fedora nightly, Arch, OpenSUSE Tumbleweed, or tbh any flavour of Linux. (Arch reportedly unafffected)
    • ssh service not exposed publicly

    The malicious code was discovered within a day or two a month of upload iirc and presumably very few people were affected by this. There’s more to it but it’s technical and not directly relevant to your question.

    For the average person it has no practical impact. For those involved with or interested in software supply chain security, it’s a big deal.

    Edit:
    Corrections:

    • OpenSUSE Tumbleweed was affected; Arch received malicious package but due to how it is implemented did not result in compromised SSH service.
    • Affected package was out in the wild for about a month, suggesting many more affected systems before malicious package was discovered and rolled back.




  • Even if you need something just once, just install it and then uninstall it, takes like 10 seconds.

    apt install foo && apt remove foo
    

    That’s essentially what nix-shell -p does. Not a special feature of nix, just nix’s way of doing the above.

    Actually using it though is pretty convenient; it disappears on its own when I exit the shell. I used it just the other day with nix-shell -p ventoy to install ventoy onto an ssd, I may not need that program again for years. Just used it with audible-cli to download my library and strip the DRM with ffmpeg. Probably won’t be needing that for a while either.

    The other thing to keep in mind is that since Nix is meant to be declarative, everything goes in a config file, which screams semi-permenant. Having to do that with ventoy and audible-cli would just be pretty inconvenient. That’s why it exists; due to how Nix is, you need a subcommand for temporary one-off operations.








  • The way I have my monitoring set up is to poll the containers from behind the proxy layer. Ex. if I’m trying to poll Portainer for example:

    ---
    services:
        portainer:
        ...
    

    with the service name portainer

    from uptime-kuma within the same docker network it would look like this:

    Can confirm this is working correctly to monitor that the service is reachable. This doesn’t however ensure that you can reach it from your computer, because that depends on if your reverse proxy is configured correctly and isn’t down, but that’s what I wanted in my case.

    Edit: If you’re wanting to poll the http endpoint you would add it before like http://whatever_service:whatever_port