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

help-circle




  • How are the alternatives any better? Download a DEB that executes arbitrary code, signed with some .asc that’s sitting in the same webserver? Download an EXE?

    Your comment is so rambley that I can’t understand whether you’re criticizing the distribution method or the packaging. Both of those are very different in terms of attack surface, if you’re talking about supply chain attacks.




  • I could be wrong here, but I think the common interpretation here is wrong. The risk is not that the wires overheat and cause a fire. The risk is that the card draws too much current from a single 12V power rail on your PSU, sustained for a long time, and that burns out the power rail on your PSU.

    I have a 6950 XT that I used with a 850W PSU that was connected incorrectly according to the diagram, with multiple connectors coming off a single rail. After about 6 months, one day my SSD stopped working, and after some tinkering, I realized that if I plugged it into a different 12V connector, it started working! I had burned out one of the 12V rails on my power supply, and I strongly suspect it was my incorrect wiring into my 6950 XT that caused it. (edit: I got a new PSU and never looked back)





  • Your post couldn’t be more true. Decades ago I was sold on MythTV, this PVR software but it only ran on Linux and you had to compile it yourself. So I gave Linux and MythTV a shot. As it turned out, both MythTV and early desktop Linux were a buggy, frustrating mess. X broke all the time. Incomprehensible, ungoogleable compile errors all the time.

    I spent so much time troubleshooting MythTV and compilation problems that I ended up learning Linux inside and out and the C programming language to be able understand the compile errors. I went on to lead a major open source project and have had a long career as a programmer, using all the knowledge I gained that started with fighting MythTV.


  • I don’t see anyone else actually telling you how to figure out if you’re being DoSed, so I’ll start:

    Check your logs. Look at what process is eating your CPU in htop and then look at the logs for that process. If it’s a web application, that means the error and access logs for it. If you see a flood of requests to a single URL, or some other suspicious pattern in the log, then you can try blocking the IPs associated with them temporarily and see if it alleviates the load. Repeat until the load goes down.

    If your application uses a database, check your database logs too. IIRC postgres logs queries that take longer than 5 seconds by default, which can make it easy to spot a slow query especially during a time of high load.

    I don’t think DNS amplification attacks over UDP are likely to be a problem as I think most cloud providers filter traffic with forged src addresses (correct me if I’m wrong). You can also try blocking all inbound UDP traffic if you suspect a UDP flood but this will likely break DNS lookups for you temporarily. (your machine should not have any open UDP ports in any case though if you’re just running Lemmy).

    If you want to go next level, you can use “perf” to generate a system-wide profile and flamegraph which will show you where you’re burning CPU cycles. This can be extremely useful for troubleshooting performance or optimizing applications. (you’ll find that even ipfilters takes CPU power, which is why most DDoS protection happens on dedicated hardware upstream)