Hacker News Reader

Comment by dveeden2 | Hacker News Reader

There are too many names for the BMCs, even within a single vendor. BMC, ILO, LOM, DRAC, iDRAC, etc

And the worst are those that use java applets or webstart and require a ancient java version.

I am honestly surprised how bad many of these are, and in production, no less.

I recently set up a supermicro system and spent a whole day just trying to figure out what to install to get the stupid ancient Java crap to load so I could mount an ISO.

We have various Supermicro boards in production at work with BMCs from 2018 or so. The ATEN iKVM on them works just fine with a recent OpenJDK 11 and OpenWebStart. I’ve found that all the features work including mounting ISOs and doing remote upgrades. No need to whine about installing anything ancient or spreading ridiculous Java FUD.

With current browsers Java applets are not supported anymore. Some older HPE systems the didn't update the firmware to provide alternatives.

I've seen multiple vendors with problematic code that didn't work with newer Java versions.

This is by no means meant to bash Java. Some non-Java BMCs can be horrible as well (e.g. require many TCP ports in a firewall/tunnel unfriendly way or require SSH with old algorithms that are no longer enabled by default, or telnet..)

I‘ve really only had experience with Supermicro BMCs but I totally believe you that there are lots of crufty OOB environments in the wild which are hard to work with. While it’s true that applets don’t work anymore (probably a good thing), and therefore the experience isn‘t as integrated or seemless as it once was, it’s a practical matter to just log into the BMC and click on the console preview, using the JNLP file to launch the console via OpenWebStart as an independent application outside of the browser. One other thing is that the self signed certs from these older implementations are often expired and therefore throw an extra warning or two when you launch these interfaces, but you just click through them and carry on.

For fun: This actually runs the Java Applet KVM viewer on a SuperMicro X7 board: https://github.com/ixs/kvm-cli/blob/master/kvm_x7.py

1. Downloads the data from the IPMI interface

2. Modifies the files to run locally

3. Writes out a Java configuration with weak security settings so that TLS works with the deprecated ciphers.

4. Fires off a socat instance to redirect the localhost ports to the remote IPMI device.

5. Starts appletviewer locally.

Great fun writing that. Thank god we decomissioned the last X7 based storage appliances a while ago...

Happy for you.

Sysadmin for 15 years here though, Java was always a problem. The version wasn't always the worst bit, but it was always an exercise in frustration.

Mostly security controls to blame, but I have had so many issues across so many systems that I cannot stand by and let you claim this is FUD about Java.

the .NET applets are also a problem (because who has a compatible IE version?), but they worked more consistently than the Java ones back in the day.

The HTML5 ones are the only ones that seem to work consistently; but that could be biased as HTML5 is much newer, so BMCs implementing that might be updated with more regularity. (or be more modern hardware)

I keep VM with old java/ff precisley for some old shitty servers kvms

I keep an old Windows XP VM around with Java 6 just for this exact reason.

There are reasons for tools like https://github.com/ixs/kvm-cli. It seems like every operations team built their own version that logs into the web interfaces, downloads the java stuff and then runs it locally...

Just annoying.

This is one of the reasons I like to architect networks for netbooting (so no remote media needed) plus force every physical server to boot UEFI-only - because UEFI supports serial console properly, unlike BIOS, so I can just use IPMI Serial-over-LAN support.

Combination of those two generally removes the need for any of the advanced features that required custom clients or even a Web browser

For sure - we have some networks that when a host netboots it always goes to something like http://netboot.xyz with serial console by default.

My favorite is some vendors using COM1 and some using COM2 so you have no idea which it is ahead of time.

That's why I keep to UEFI - most of the time the configuration just works, and firmware passes down information about serial console to the OS, iirc.

My first job (2016) involved dealing lots of servers used by telecom providers in many different DCs in different cities.

One of my most useful tools was a thumb drive full of old internet explorer, firefox, and Java installers.

The 50m ethernet cable (nicknamed BFC - big fucking cable) also deserves an honorable mention.

Even worse was one of mine last year that needed Flash. Apparently we neglected to update it. I can handle ancient Java, but trying to get Flash setup was going to be futile, so I just went to the data center.

That was an old Cisco server, right? I think those models still require Flash even if they're fully updated, and people have to use VMs with Flash installed to access the BMC.

Yep. I think you may be right, it’s EOL and probably doesn’t have any more updates available. I have a VM for when I need old Java, but I was going to need an older VM to run Flash, and that just wasn’t how I wanted to spend my time. :D

Docker image with Firefox 52 ESR and Java plugin comes to the rescue.

Looking at you, Asrock...

Reply on news.ycombinator.com