I'm still on the quest for a means to use Linux clients to remotely access server hardware (not access the OS ... I mean access the BIOS and bootloader). Apparently the VNC access often mentioned as associated with IPMI is only functional once the OS is running. Yeah, some people use VNC to access the Linux console. Those must be GUI freaks.

I need to be able to access servers to:
1. Power cycle or hard reset them to force them to boot when "stuck"
2. Choose an alternate boot device in BIOS (and other BIOS settings)
3. Choose the system to load in the bootloader

A net access power strip can accomplish #1 if the BIOS settings are right (e.g. the "always boot up when power loss" setting enabled). If there was a video chip that could also do keyboard and mouse, and talk VNC (or better yet, VNC over SSL or SSH), that should work.

Is there any alternative out there do to this with open source software on the client?

you need to use hardware devices known as light out management cards. like all the modern servers have these kind of facility.
DEll have DRAC, HP have ILO, IBM have RSA.

i don't think that you can access BIOS remotely with any softwares.

As stated VNC or SSH will only work after the operating system has loaded.

Servers have special hardware (out of band management) for remote console access. As an alternative there is also KVM over IP which as it sounds is a remote keyboard, video, mouse switch with an ethernet port. Those are the only two methods I am familiar with that will give you the capabilities to access the BIOS or boot loader remotely.

AFAIK there isn't any software server or client that will do what you want.

Yes, despite many people saying that it is available. I think they, too, are victims of sales speak which tries to make people think everything will solve every problem.

So what protocol do they use for this out of band management? And out of what band? The VGA/PS2 connections? I would not call that "out", but different.

KVM over IP? Yeah, I've seen that, quality and reliability is horrible (at least on the Avocent system we tried). And it's not compatible with anything, so I have to use their box on both ends. Not useful at all for a "remote from home" solution.

Then I have to go back to be original suggestion of a few years ago that others tried to shoot down with these fictious "solutions". My suggestion was to create a chip to be used on motherboards or an add-on card which functions for the video, keyboard, and mouse, and communicates over a dedicated ethernet port using VNC over SSL as its protocol. No need for expensive KVM infrastructure and its limited fan-out architecture. VNC clients exist for all desktop OSes (BSD, Linux, OSX, Unix, Windows). So whoever first implements this won't have to do any more for the client end than just gathering up some free software links.

well, out of band management or light out management card have serial console and ethernet port. on these cards have small flash memory and they're capable to show you server screen web based like vnc but they are not using vnc protocol , they either works on serial console, ethernet + ssh or telnet and web based on port 80.

check out wikipedia source about it. it will give you better idea.

http://en.wikipedia.org/wiki/Out-of-band_management

I work for Dell and wanted to provide some info here I hope will be of general utility even on a non-Dell server. While Dell's DRAC/iDRAC does provide advanced features, basic IPMI support is available without it, and that should be the case on most server-class hardware regardless of vendor.

Once you have established your server does support IPMI you would need to configure the baseboard management controller's network settings and a user/password. The BMC will have a different IP address from the host even though they may use the same physical Ethernet interface. On Dell you can set this up with Ctrl+E during POST; other vendors may be similar. Then you can use an IPMI client from your Linux machine such as ipmitool, freeipmi, or openipmi. I only have experience with ipmitool where you can do things like this:
$ ipmitool -H 10.1.2.3 -I lanplus chassis power reset
That would prompt you for a password (must be pre-configured in the remote machine's BMC) and uses the lanplus interface to encrypt the password in transport (requires IPMI 2.0), and does a hard reboot of the server.

If the server only does IPMI 1.5, you will not be able to use lanplus and the password will not be encrypted.

You can also select an alternate boot device at next boot.
$ ipmitool chassis bootdev pxe

There are a whole bunch of great things you can do with IPMI support that are vendor-agnostic and I recommend checking out the man page for ipmitool.

I don't think IPMI can deal directly with a boot loader, but it does support a serial-over-LAN console and you may be able to script telnet to interact with it to choose what you want.

If your server does not have IPMI support, or if you are trying to manage a desktop/workstation, unfortunately you probably do not have a ready-made way to do what you are trying to do.

Good luck!

I think something like "KVM over IP" is the closest option for what you may want
- like this ?
- more
- aten kvm
- some more

There may have existed (or still do exist) add-on cards for servers without iLO (HP brand) but I don't seem to find it


good luck

Notice that "BIOS" is in the original title.

My top goal is still to get the BIOS console access. VNC can do that. VNC is not hard to implement because it is a simple protocol. Freely usable code already exists as a basis for this.

It looks like IPMI was not designed with security in mind, and this has been added on later. That creates a lot of problems. Intel was very short sighted with this. IPMI still has no means to access the bootloader menus.

The OpenGear approach does not scale. And it suffers from the re-sampling issues we encountered with KVM approaches like it. Also, I see no mention of VNC. I do remember contacting a company like this once before asking for VNC and they replied that there is no VNC support.

KVM approaches are what I am trying to avoid because of the high cost that goes up too rapidly with scaling. That and the equipment space needs. It SHOULD all be easily and cheaply doable via an extra ethernet connection into the server and all managed from one chip.

The ATEN models also do not mention what protocol is used for the video. They only mention IP so I have to assume they are gouging with some proprietary thing.

At least ADDER mentions VNC. But I see nothing of practical scalability there, or else these boxes ONLY work with their KVM infrastructure.

THE SOLUTION is to put the VNC access in the server itself, as part of the video chip with keyboard and mouse integrated. When I proposed that, people suggested IPMI. But it's obvious now that they didn't understand this.

And the above proposals are still trying to push towards the very thing I'm trying to get away from ... expensive and difficult KVM infrastructure.

They need to add VNC.

This costs too much in part because they are trying to re-sample the analog video back to digital. This is the wrong approach. It should be done directly in conjunction with the video chip itself, where the VNC server code has direct buffer access digitally. And the keyboard/mouse devices should be implemented in this same chip.

Then we have one chip that serves the function of the video chip, and keyboard/mouse chip(s). Put that on a PCI card for retrofitting older servers. Put that on the motherboard for new servers. Problem now solved at a low cost.

Additional costs exist because this box needs a power outlet and physical space TIMES the number of servers. Try fitting this in a cabinet with 40 1U servers and a couple ethernet switches ... or other cabinet combinations.

Try to visualize all the servers with just ethernet and power connections, and getting direct digital access to not just any server, but to all of them at the same time concurrently.

My original suggestion is (approximately) this:

Manufacturers of server mainboards should replace the chip(s) that handle keyboard, video, and mouse using legacy connectors (HD-15, PS/2, USB) with a single chip that handles these same functions logically over ethernet and IP with open protocols for the same kinds of access.

VNC over TCP over IP can be used for this. It is simple and open. Add SSL and/or SSH for security wrapping.

Don't suggest IPMI as I now know not to be fooled by this (maybe whoever originally suggested IPMI was fooled by its marketing that tried to place IPMI as the ultimate solution). This might be used in conjunction with IPMI by implementing both on the same chip. IPMI could then be used to establish the initial authentication for security. The initial IP addressing should include at least the IPv6 scope-local address derived from the MAC address, or otherwise written on the device where it can be read.

One objective for this is to eliminate the expensive and difficult to use KVM infrastructures. The existing ethernet infrastructure can be used instead. Either a separate 8P8C ethernet connector can be used, or one can be share by integrating ethernet switch or device functions inside this chip.

This can also be done on a PCI card to retrofit older servers.

^^^^ +1 to that.

I just don't see the way to make manufacturers implement it.

I suspect the reason they don't is the NIH syndrome. But possibly, if we get this idea clarified enough for more people to understand, and get them to communicate the idea to the manufacturers, there might be a chance. A chip manufacturer is going to need to design it.