Ipmi is a bit of a double-edged sword. Network-connected access to a serial console (including uefi/bios console redirection) and the reset button can be a total lifesaver, I agree. I wouldn't want to be without a serial console and remote reset button either.
But ipmi cards are little network-attached linux boxes which run prehistoric kernels and userspace, exposing as many services as the half-wits who put together the firmware image can shovel in, and are rarely if ever patched by the vendor unless there's some really public scandal.
The standard thing to do is to isolate them on some kind of private management network in an attempt to shield the wider internet from the full majesty of the firmware engineers' dazzling skills, but that might be harder to do in the simple 'beginner' scenario Rachel describes.
One good simple version when you get up to two servers instead of just one is to cross-connect so each machine has ipmi access to the other, but neither ipmi service is exposed to the wider world.
Even if your server does not have proper IPMI, most colo providers have an assortment of ip-kvms, you can ask for those and access your server from any modern browser.
I'm pretty suspicious of trusting the firmware on things like that either, to be honest. (Personally, I tend to use serial cables and a little custom board to turn serial breaks into resets, but I know my NIH instinct is probably a little on the high side. It would be unreasonable for me to suggest someone new to colo start making random extra boards to stick inside their machines!)
You do not need to stick it inside, it plugs into monitor and keyboard ports. Power-on and reset are usually done manually on request. And you do not need it plugged in all the time, only to reconfigure network or boot values.
That's definitely a level of remote-hands intervention I've not had from the handful of places I have racks of colo kit. You're right, it might be something some of them do for other customers though; I've never really asked. They'll certainly push a reset button, swap a drive or rack a server that's shipped to them. (Though hardware's reliable enough nowadays and I have go to data centres so rarely that it's a bit of a fun novelty, and I like doing it myself.)
I've been colo'ing forever. I'd consider a Lantronix spider ipkvm available on request to be like minimum viable colo service. It's usually up in 5 minutes when I submit a ticket to the NOC.
I bet your provider has something like that. It's a godsend when you screw up, say, the hypervisor running state somehow and need bare metal access to unbork it :)
My version of this is to use a serial console server for direct access, rather than vga + keyboard. If the kernel is still running fine but network access is down, I have a getty running on the serial port. If the kernel has locked up too, I hit the reset button by sending a 500ms+ serial break (special circuit, highly recommended) and the bios has serial redirect, so I can do stuff like hit del to drop into bios setup or uefi shell at that point.
But I expect you're probably right some or all of the providers we use do have something like that, as I speculated in the previous post. I've just never understood the point of vga-type stuff when bios/uefi serial redirect exists and serial console is more convenient anyway once the kernel has started, so never asked the question.
Yeah, I like the idea of a bmc but the implementation sort of sucks. What I want: a small soc pony engine that controls the main computer. On this soc I want to install my own os. I like openbsd so that would be my ideal os, but the point is it should be my os not the vendors.
Serial console + reset line control for the win here, if you want easy to diy. I guess there are lots of arm32/arm64 embedded boards that run openbsd you might repurpose and be able to mount inside a machine and which will have near zero power footprint compared to the hardware itself?
I've often wondered about actually replacing the kernel and userspace on the vendor BMCs themselves, to substitute something more competent, but I've not found anyone who's successfully done it.
But ipmi cards are little network-attached linux boxes which run prehistoric kernels and userspace, exposing as many services as the half-wits who put together the firmware image can shovel in, and are rarely if ever patched by the vendor unless there's some really public scandal.
The standard thing to do is to isolate them on some kind of private management network in an attempt to shield the wider internet from the full majesty of the firmware engineers' dazzling skills, but that might be harder to do in the simple 'beginner' scenario Rachel describes.
One good simple version when you get up to two servers instead of just one is to cross-connect so each machine has ipmi access to the other, but neither ipmi service is exposed to the wider world.