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

help-circle
  • Nginx Proxy Manager is probably perfect for you.
    Pick a domain (like mylab.home or something), set up your home network to resolve that domains IP as your docker hosts IP.
    NPM will do self-signed certs. So, you will get a “warning, Https is insecure” kinda page when you visit it. You could import NPMs root cert into your OS/browser so it trusts it (or set up an “don’t warn for this domain” or something).

    If you don’t want per-client config to trust it, then you need to buy a domain, use a DNS that supports letsencrypt DNS-challenge, and grab certs that way (means you don’t need a publicly accessible well-known route exposed)










  • VMix popularity exploded during the pandemic. A lot of conferences became a blend of teams/zoom/Google and VMix.

    Might be hardware based like a multi-m/e video mixer (blackmagic make cheap ones), or maybe more of a screen manager (like barco e2, analog way livecore). But, unless there are production requirements, vmix is much more likely. It’s (now) proven, and much cheaper!

    OBS can absolutely do it. There are other open source softwares that can do it.
    I’ve seen people bastardise Resolume into something that looks decent.
    There are some online studio systems so everything you do is virtualized. Streamyard used to be like this, till it was bought by hopin (I think it was hopin)


  • You can do reverse proxy on the VPS and use SNI routing (because the requested domain is in clear text over HTTPS), then use Proxy Protocol to attach the real source IP to the TCP packets.
    This way, you don’t have to terminate HTTPS on the VPS, and you can load balance between a couple wireguard peers so you have redundancy (or direct them to different reverse proxies or whatever).
    On your home servers, you will need an additional frontend(s) that accepts Proxy Protocol from the VPS (as Proxy Protocol packets aren’t standard HTTP/S packets, so standard HTTPS reverse proxies will drop them as unknown/broken/etc).
    This way, your home reverse proxy knows the original IP and can attach it to the decrypted http requests as x-forward-for. Or you can do ACLs based on original client IP. Or whatever.

    I haven’t found a way to get a firewall that pays attention to Proxy Protocol TCP headers, but I haven’t found that to really be an issue. I don’t really have a use case




  • I think the supposed risk to electronic voting machines is that there would need to be thousands of them, are distributed, somewhat unattended, and operated by people that don’t know them.
    The possibility of an exploit or misconfiguration increases, and the ability to compromise someone supervising one of the polling station increases.
    If there is are centralised systems, fewer higher skilled people would be required to secure/monitor/run the system. It can also be airgapped.

    While some of these risks are also applicable to in-person and mail-in voting, these systems have been around for ages, are not proprietary, and anyone can figure out “how it works” and can make sure “how it happened” matches.
    As soon as you get into cryptographic vulnerabilities and security, 99.99% of people would be lost in the woods

    The rest of the questions, I feel, are more systematic things.




  • Yeh, immutable distros… You can install software, it’s just you have to declaratively define what software you want, then apply that as a patch.
    You don’t just apt install cowsay, you have to create a file that defines the installation of cowsay.
    This way, if you have to change how cowsay is installed, you tweak that patch file and reapply it.
    If you have to wipe & reinstall (or get a new computer or whatever) you just apply all your patches, and the system is the same again.