CIRCLE WITH A DOT

We can also see the bad network performance in the CPU usage charts, showing up as increased dom0 iowait time due to CephFS operations lagging

The SSD is slightly cooler, other than a short spike right after boot that might be before the fans spun up fully or something

Historical network traffic before and after the recent reconfiguration.

I wonder why all my virtual desktops are so slow?

Post fan/GPU upgrade, and some additional fan RPM tuning via IPMI: VM server is running a lot cooler, for the most part. CPU VRM temperatures during a big compile job are less than the *idle* temps previously.

But I'm now seeing NIC temperature and it's concerningly hot. I'm not sure why it wasn't showing up before so I have no idea how toasty it was.

I'm also seeing what appears to be poor / unstable network performance.

The ConnectX6 is passively air cooled and sits just to the right of the new 80mm fans (as seen from the rear panel), and I suspect what is happening is that the negative pressure from the new fans is drawing front-to-back airflow slightly to the left and reducing airflow over its heatsink. Thermal engineering is hard.

I have another PCIe slot exhaust fan on order coming tomorrow so hopefully things are tolerable between now and then.

@nnnilabs Yay HMC804x. I love my HMC8042s.

My only complaints:

* After ~10 years in service the white LEDs are wearing out, the most common settings I typically leave them on are super dim while if I change to an oddball configuration they get really bright. I was offered an RMA to swap the LEDs but haven't wanted to take them out of service to do it

* The firmware is a little slow, I wish I could get more updates per second over Ethernet

@dimin at least Intel makes most of their nic chipset info public

Does anyone make a LOTO for DC barrel jacks? Found my echo dot while cleaning up the lab earlier and I feel like I really should have a lockout on the power source

@jaseg something something xkcd emacs spacebar heating

@gsuberland Maybe for DDR5 modules.

Have you seen what Digikey wants for loose DDR4 ICs? $300+ for a single 16Gbit IC

@dch The overall flow is that incoming traffic to my site hits the core router / firewall which blocks requests to unrecognized ports or from blocklisted IPs etc.

Then anything headed to port 443 or 80 goes to the VM server where a single nginx instance does HTTPS termination as well as serving some static web endpoints like my blog. Non-HTTPS traffic is 301 redirected to HTTPS.

A bunch of other endpoints like the CI dashboard and API are reverse-proxied (currently with no TLS but I will eventually be using internal enterprise-CA certificates here just to be extra safe) to other VMs on the same physical host, like the one the dashboard is hosted by as well as the one the webhook API endpoint lives on.

Since the main TLS termination host needs to accept connections from anywhere on the internet, I would need IP filtering in that nginx instance to drop stuff going to the API endpoint from non-GitHub IPs. While doable, the hash is fast enough I don't think it is going to really protect me from much. The whole point of the HMAC itself is that anyone without the preshared key can't spoof requests.

@dch the hmac is fast enough it's not a viable DoS vector. My inbound pipe will saturate before I'll run out of CPU doing hashes.

If somebody wants to DDoS my API endpoint there's not a whole lot I can do about it.

@cr1901 The downstream bash scripts will do no further sanitizing, as it's assumed the branch and ref are valid by the time you get to them.

Right now these arguments are ignored and I always build latest master, but that is about to change and I want to not get pwned when that happens

@cr1901 The checks on line 54 and 65 are intended to make sure that $branch is only alphanumeric characters and dashes, and $after is only lowercase hex characters.

After that, they should be safe to e.g. "git checkout $COMMIT"

The question is...
* Did I do that right? I'm not a regex expert
* Is there any way that this can lead to me checking out a branch/commit from a fork rather than the upstream repo via some github server side weirdness?

One trust boundary I'm trying to maintain here is that the orchestrator node (the box that runs this hook and launches the actual runner instances) is slightly more trusted than the runners.

While right now, we're only building from master on the upstream repo, I would like to eventually use the same platform to test pull requests after a cursory human review.

The runner VMs are ephemeral and blown away after a job completes and live in an isolated sandbox network, so the damage they can cause if compromised is limited (assuming nobody cares enough to burn a Xen hypervisor escape on me).

But I want to avoid any opportunity for pivoting to the orchestrator which e.g. will be able to publish build artifacts to other servers

It's been a while since I've done web stuff. Did I screw up anything too horribly here?

https://github.com/ngscopeclient/scopehal-ci-scripts/blob/main/api/github-hook.php

This is a web hook that is only triggered by the 'push' event on ngscopeclient/scopehal-apps.

Goal is to ensure that

a) nobody but github can trigger builds (to prevent DoSing the CI platform with a ridiculous number of builds etc)

b) a compromise of GitHub's webhook infrastructure can trigger builds of real commits in the repo, but not run arbitrary shell commands on the CI runner or pull from an untrusted fork (i.e. no shell command injections etc in the branch/commit strings which will be fed to a zillion bash scripts downstream)

@lasse @janamarie i mean uv also is a wide spectrum normal glass will let through a lot more 365nm than 193

@s0 yay large memory systems lol.

I could probably offer someone 256GB without too much work and 384 if it was important enough I was willing to temporarily pause some of my other stuff.

But it's super nice to have lots of space on a VM server so you can just be your own cloud big iron for your own or friends/family needs when something like that comes up

The deep memory and fast refresh rate of the ThunderScope is a godsend for stuff like this, I can see fast transients over a long time and trigger basically as fast as the data can come in.

Top is the source of the MOSFET. The supply is configured for a 50ms soft start and has a somewhat linear ramp (probably distorted a bit by supply wire inductance) from 0 to 19V as expected.

Bottom is the drain. Flatlined.

I was expecting to see it rise a little bit, then the overcurrent protection kick in (whether false positive or true doesn't matter, there should be *some* increase) after some delay.

It's not even trying to go up. So the FET isn't turning on at all./

Back to the ADP3450 debug probing the power MOSFET on the ADM1270

@X00001 EDM: the world is fucked, let's have a rave

Death metal: the world is fucked and we're all doomed