How We Replaced the IPMI Console with HTML5 for Managing Our Servers

Remote access to physical servers is essential for IT professionals. If you own a server or rent one, you've likely accessed it through SSH or RDP. However, traditional methods of managing such systems can be vulnerable due to the need for an operating system and specialized software on the server.

In cases where no operating system is installed, or issues arise during setup such as boot errors or network/firewall misconfigurations, access to remote server resources could be lost, resulting in a surge of support tickets from hosting clients. In such situations, dedicated controllers for remote server management without an operating system in place become an effective solution.

The Traditional Approach

One solution is to use IPMI – an industry standard for monitoring and managing platforms. IPMI enables hardware management regardless of the presence or functionality of the OS. However, managing the console and equipment settings requires corresponding software. In our case, this involved running a Java KVM plugin.

Let's illustrate this process using Supermicro servers as an example. Our clients had to activate their connection, wait for the gray IP address forwarding, create a temporary account, and receive a link with an IP address for authorization in the web interface to access the remote server console. Only after completing all these steps could they access the integrated IPMI module on the server to manage its settings and functions.

Clients needed to install Java software on their devices, often leading to increased support workload as some users experienced difficulties launching the downloaded console.

Additional challenges arose with version compatibility or launching the console on Apple devices. These shortcomings motivated us to develop a more convenient and user-friendly mechanism for managing equipment.

We decided that everything should "run" on the hosting side within a secure virtual environment, eliminating the need for additional software installation and configuration on client devices.

INVAPI and Its HTML5 Console

Our console operates within INVAPI—our internal hardware management panel used at HOSTKEY throughout all stages, from server ordering to performing system reinstallation. Therefore, integrating the console into our management panel felt logical.

To eliminate the need for users to locally install additional software, the initial technical specifications (TS) for the HTML5 console specified direct access from the user's personal account.

Users can simply click Open HTML5 Console in the designated section of the management panel to access it.

Docker was employed to practically implement this idea, with NoJava-IPMI-KVM-Server and ipmi-kvm-docker forming the core foundation. The console supports Supermicro motherboards up to the tenth generation (the eleventh generation already features the HTML5 Supermicro iKVM/IPMI viewer).

INVAPI boasts a sufficiently convenient API, allowing for a corresponding eq/nonvc call within the console.

curl -s "https://invapi.hostkey.com/eq.php" -X POST \
--data "action=novnc" \
--data "token={HOSTKEY TOKEN}" \
--data "id={SERVER_ID}" \
--data "pin={PIN_CODE}"

Response example:

{
"result":"OK",
"scope":"https://rcnl1.hostkey.com:32800/vnc.html?host=IP ХОСТА&port=32800&autoconnect=true&password=YVhMxxhiuTpe3mH6y3ry",
"context":{"action":"novnc","id":"25250","location":"NL"},
"debug":"debug",
"key":"71ccb18b1fa499458526acc15fb6a40b"
}

INVAPI logic is built on API calls, and we previously implemented VNC access in a similar way through Apache Guacamole. So, let's describe the process again.

When you click a button, you request this action through the API, initiating a more complex process that can be schematized as follows:

An INVAPI request sends a command to the API to open a console for a specific server through the message broker cluster (RabbitMQ). To call the console, simply send the server's IP address and its location (our servers are located in the Netherlands, USA, Finland, Turkey, Iceland and Germany) to the message broker.

RabbitMQ forwards the server data and the console opening task to a helper service-receiver created by our specialists. The receiver retrieves the data, transforms all necessary information, separates tasks (Cisco, IPMI, etc.), and directs them to agents.

Agents (fence agents) correspond to the types of equipment used in our infrastructure. They access the server with Docker-novnc, which has access to the closed IPMI network. The agent sends a GET request to the Docker-novnc server containing the server's IP address and ID, session token, and a link for closing the session.

The structure of the request is:

https://rcnl1.hostkey.com:PORT/api/v1/server/{IP_SERVER}/skey/{REQUEST_KEY}/{SERVER_ID}/closeurl/{CLOSE_URL}

The Docker-novnc container contains the following components:

• Xvfb — X11 in a virtual frame buffer
• x11vnc — VNC server that connects to the specified X11 server
• noNVC — HTML5 VNC viewer
• Fluxbox — window manager
• Firefox — browser for viewing IPMI consoles
• Java-plugin — Java is required for accessing most IPMI KVM consoles

NoJava-IPMI-KVM-Server is a Python-based server that allows access to the IPMI-KVM console launch tool based on Java without local installation (nojava-ipmi-kvm) through a browser.

It runs in a Docker container in the background, launches a suitable version of Java Webstart (with OpenJDK or Oracle), and connects to the container using noVNC.

Using Docker automatically isolates Java Webstart, so you don't need to install outdated versions of Java on workstations. Thanks to our server, you also don't need to install the docker-container nojava-ipmi-kvm itself.

The console launches within a minute after the request and opens in a separate browser window. The downside here is that if you close the console, you can open it again immediately, so we added a link for automatic session termination.

This is done for user convenience and equipment security: if there is no activity for a certain period of time (two hours by default), the console will be closed automatically.

An important point: if the server is restarted or a regular VNC console is called from the panel, you will need to restart access to the html5 console.

What are the results?

Implementing this new solution significantly simplified the process of managing Supermicro equipment for end users. It also reduced the workload on our support team, enabling us to streamline the management of hardware from other manufacturers as well.

As our equipment park grew (currently over 5000 servers and 12,000 virtual machines across all locations), we also faced challenges in developing and supporting a single universal solution similar to NoJava-IPMI-KVM-Server. Therefore, the docker-novnc service actually has different container builds optimized for specific server types: html5_asmb9 — servers with ASUS motherboards (with their quirks), java_dell_r720 — Dell servers, java_viewer_supermicro — Supermicro servers, java_viewer_tplatform — T-Platforms servers — V5000 Blade Chassis.

Why such complexity? For example, the blade chassis from T-Platform is quite old and requires Java 7 and Internet Explorer browser to open a console.

Each motherboard has a tag with the Java version and platform type, so in the request, we only need to send the machine's IP address and Java type.

As a result, we can run a large number of docker-novnc containers that horizontally scale and can be orchestrated in Kubernetes.

All this allows us to get a unified interface for accessing servers through the browser, unify the interface and API, simplify access via IPMI, and also abandon Apache Guacamole.

The problem of hotkeys is also solved — the interface remains standard and understandable everywhere, support is provided by our team, we can flexibly configure access.