It’s certainly not very fast

My latest project runs on a VM I use vscode’s ssh editing feature on. I edit the only copy of the file in existence (I have made no backup and there is no version control) and then I restart the systems service.

So what if I mess it up? Big deal. The discord bot goes down for a few minutes and I fix it.

Same goes for the machine configs. Ideally the machines are stable, the critical ones get backups, and if they aren’t stable then I suppose the best way to fix it would be in prod ( my VMs run debian, they’re stable).

I feel i’m kinda vaccinated against the junior feeling because week 2 of my first job out of college, I crashed both sides of a cluster, leaving the client’s factory responsible for half of their European production dead for 3 days.

I panicked for a few days then they asked me to do an incident report and I thought I was cooked and then literally nothing happened to me. Nowadays if shit hits the fan at 16h59 then I’m gone at 17h00 anyway and so should everybody that’s bothered by the smell.

Si tu veux te barrer, dm ton CV. Je te présenterais bien l’entreprise mais au point où t’en es je sais que tu t’en fous donc c’est toi qui voit

https://youtu.be/Erp8IAUouus explains it pretty well

Pretty much all monitoring solutions on the market track cert expiration nowadays. I get an alert when any of my certs have <5 days left

It seems your assessment is correct. You’d be surprised at the speeds you can get on poor wifi when you don’t care about latency. The average speed marching up with your download is a dead giveaway too. The fact that maximum over 5 minutes exceeds it is a bit weird, but it could be explained by some networking equipment in the middle (probably at your ISP if I was to guess) terminating MTUs for whatever reason. A common one is misconfiguring various solutions for capping internet speeds to subscribers, where your local MTU will be set correctly but the outgoing ones will be set to the maximum speed of the link.

Sorry I 'ever saw this, that sucks.

Turns out mine was broken too. I put the CPU in my gaming rig and it worked fine, so I bought a new motherboard and the problem is gone.

Syslog is considerable overkill for home lab monitoring.

SNMP does what you want. You just need a good monitoring solution that’s not as involved as Prometheus+grafana (I feel you, I’ve been there)

I really enjoy PRTG, but it’s way too expensive for a home lab, still throwing it out there if you feel like you have money to burn.

I hear good word about libreNMS, it’s next on my list when my PRTG licence runs out.

Be warned that monitoring is ultimately a fickle thing; what you don’t write in yaml config for grafana, you get to dig through obscure SNMP libs to find out (though I find that’s easier for me, ymmv) for other tools.

I recommend against: nagios (I like it but if you hate Prometheus it’s definitely not for you), checkmk (throw checkmk into the sun please it just fucking sucks), cacti (NO!), solar winds (why?)

if you feel like you want to become a datacenter admin: zabbix scales very very well, both in performance and ease of admin against hundreds of servers, but it’s overkill for a home lab, and it can get you lost in configs for hours.

It’s a gigabyte ab350m gaming-3 rev 1.0. it boots grub fine but then crashes right after displaying “loading Linux 6.x”, CPU led flashes then dram led stays on, I have to turn it off with the PSU switch.

Either it’s a rev 1.0 bug which is a thing on those motherboards, or the CPU (or igpu) is defective.

https://superuser.com/questions/1854228/proxmox-doesnt-boot-after-cpu-change

I’m currently waiting on support from both the seller and gigabyte but I don’t expect anything out of it, though I’m still yet to test it in a different motherboard.

Oh wow congrats, I’m currently in the struggle of stretching an ab350m to accept a 4600G and failing.

You’re right, you should hit PCIe 3 speeds and it’s weird, but the fact that the drives swap speeds depending on how they’re plugged in points to either drivers or the chipset.

I’m not fully familiar with the overheads associated with all things going on on a chipset, but it’s not unreasonable to think that this workload, plus whatever the chipset has to do (hardware management tasks mostly), as well as the CPU’s other tasks on similar interfaces that might saturate the IO die/controller, would influence this.

B350 isn’t a very fast chipset to begin with, and I’m willing to bet the CPU in such a motherboard isn’t exactly current-gen either. Are you sure you’re even running at PCIe 3.0 speeds too? There are 2.0 only CPUs available for AM4.

It might be that the data to both disks saturates a common link before the second disk reaches full iops capability, and thus the driver then writes at full speed on one disk and at half speed on the other, for twice as long.

DevOps was a lie pushed on devs to make them become sysadmins, unfortunately.

So obviously this sucks, however.

Look into timewarrior+taskwarrior. They’re the only tools I’ve ever seen for these types of tasks that don’t fucking suck ass.

Can’t really go wrong with the old school nagios+thruk. The learning curve is a tad steep but it teaches you a lot of things about your systems.

It’s a very educated guess based on the following:

The crash is a null pointer dereference, which a linter ought to catch.

The crash does not happen if you have crowdstrike sensor installed, which is weird because crowdstrike sensor’s job is not to prevent any crashes.

Hence the guess: the update the pushed tries accessing memory in sensor, but if it’s not installed the pointer is null and that’s Bye-Bye.

Oh but they did. Turns out that this is specifically caused by one driver expecting another to be installed, the other one being for another of their products. If you have the other product installed, it doesn’t crash, so it didn’t crash on their machines because they have all their products installed and apparently not a single element of their test matrix has the single most common configuration they service