JoeSchmuck said:
Interesting read, well really scarey to be truthful. I had no idea the reasons a bit error could occur and thought it was merely a failing RAM chip. I still have the problem with money, well unless my wife hits the lottery. I do want to upgrade to a system with ECC RAM but if I do that then I'm buying a new MB, CPU and RAM. I don't need a particularly speedy CPU nor RAM but ECC RAM isn't cheap. At one time I recall CPUs being the most expensive part of a computer, well it's not any more.
On many recent AMD systems (even desktop-class) you get ECC essentially "for free". I've been building / buying Intel-based server hardware and for that I believe I still need to make sure everything has ECC support.
So buying a new MB, well if I have to spend that money I was thinking about buying one that has some kind of remote management capability since I place my server in the basement where it's nice and cool. But I'm not sure what this is called because I'm looking for basically a way to control the computer as if it were right in front of me when booting it up. I guess an Ethernet based KVM, assuming it could piggyback on my wired network.
It goes by a number of different names. Dell calls it DRAC (Dell Remote Access Controller). HP calls it ILO (Integrated Lights-Out [management]), and so on.
There are generally two ways those devices will let you into the system - emulated KVM, usually in a web browser as you mentioned; and SOL (Serial Over LAN) which gives you some sort of console you access with a terminal emulator. KVM is nicer, as long as you have a supported browser and your config, which might be locked down by corporate IT if you're in a business setting (I know you're not, but mentioning it for completeness) to prevent using ActiveX controls, running Java applets, etc.
You usually get IMPI thrown in for free on systems with remote management hardware. This will let you measure temperatures, fan speed, voltages and so on. You can check the "Hardware monitoring" section of my
RAIDzilla II project for a [static] example of what sort of data is provided.
Next is how those systems connect to your LAN. This could be a dedicated Ethernet connector port for remote management or a port shared between normal system use and remote management. The latter can be difficult, because each implementation is subtly different and the FreeBSD Ethernet device driver you're using needs to be aware that something else is sitting on the port. For example, while it might be useful to re-negotiate speed/duplex when FreeBSD brings the port up during startup, that will make the remote management unreachable during that interval.
All of this is probably overkill for the average home network - just have an old monitor and keyboard handy if you need to do any BIOS-level or single-user FreeBSD work on the box. All of my systems have remote management, but then again I have 10 or so systems and 140TB or thereabouts in my spare dining room...