I’ve been running MAAS for some time now on an Intel NUC, specifically the DC53427HYE model from a few years ago. There are very few NUC models that offer vPRO support which is why I chose this one to begin with. It had been running well for quite a while with Ubuntu 14.04 and MAAS up to version 1.9 from the MAAS stable PPA. And then tragedy struck…
It all started when I decided I was going to try to upgrade my server to Xenial, the coming Ubuntu 16.04 LTS Alpha. I realize the perils of running Alpha level stuff, but this box is as much a development box as it is a production server at home, so I chose the risk, and paid the price. My upgrade, using do-release-upgrade, left me with a half-configured, semi-functional machine and no easy way to recover. Thus, I decided it was time to just reinstall from scratch.
Truth be told, this was coming anyway. I’m working on a set of training slides involving my team’s custom MAAS setup for Ubuntu Server Certification so I wanted to get some good screen shots from various stages of building the server and using it. Thus, I chose to really put AMT to the test on my NUC and see if it could deliver. Keep in mind, this is a pretty quick run-through, and if it fails, I’ll likely result to something more manual, like the iPhone screen shot method.
First, I needed to reset AMT/MEBx as I had long forgotten the password I originally set. This is fairly easy on this board (and most NUCs). You unplug the NUC, crack the case, find the BIOS/MEBx reset pins near the RAM sockets, and jumper pins 1 and 2 for 5 seconds. Put it all back together, and when the NUC boots, hit CTRL+P to get the MEBx login and you’re back to the original password of “admin”. You’ll need to change the password on first entry, as before. You may also need to check the BIOS settings as well to make sure nothing has changed. Mine did register a CMOS battery failure alert that I cleared from the System Event Log. Beyond that, at this point AMT is available remotely once you have set the network settings in the MEBx console and enabled Remote Management.
AMT Web Interface
Note, if you have trouble finding the reset pins I mentioned earlier or are not sure which pins are 1 and 2 (there are three pins) refer to the technical manual for your NUC board. For this particular board, you’re looking for this guide.
Now that MEBx is reconfigured, I wanted to set up remote KVM via the AMT engine. This proved to be a little more obscure. There are ways to easily enable this in Windows. You simply download a Management Console binary, install that along with RealVNC and then do some config and off you go. Doing this on Linux proved to be a bit more difficult. To do this, you’ll need to start with wsmancli. Thankfully, the painful parts (deciphering WSMAN) were already done, and I learned the process by following from this post at serverfault.com.
First, you need to install wsmancli which is available from the Ubuntu repos.
bladernr@sulaco:~$ sudo apt-get install wsmancli
Next, it helps to set up a few shell variables for important things:
bladernr@sulaco:~$ AMT_IP=192.168.0.20 bladernr@sulaco:~$ AMT_PASSWORD=1Nsecure! bladernr@sulaco:~$ VNC_PASSWORD="1N\$ecure"
Note that for the VNC Password, it must be EXACTLY 8 characters, consisting of at least one of each of these: Lower Case, Upper Case, Number, Special Character. Additionally, I had to escape the ‘$’ since that, itself, is a shell variable. We’ll see if that way leads to madness. Remember that you need to escape the ‘$’ here, but when you reference it outside the shell, the exape character ‘\’ shouldn’t be necessary. Also, it’s probably a better idea to not use ‘$’ as part of the password anyway. Just sayin’.
Now, we need to configure things using wsmancli:
bladernr@sulaco:~$ # Enable KVM
bladernr@sulaco:~$ wsman put http://intel.com/wbem/wscim/1/ips-schema/1/IPS_KVMRedirectionSettingData -h $AMT_IP -P 16992 -u admin -p ${AMT_PASSWORD} -k RFBPassword=${VNC_PASSWORD}
bladernr@sulaco:~$ # Enable KVM redirection to port 5900
bladernr@sulaco:~$ wsman put http://intel.com/wbem/wscim/1/ips-schema/1/IPS_KVMRedirectionSettingData -h $AMT_IP -P 16992 -u admin -p ${AMT_PASSWORD} -k Is5900PortEnabled=true
bladernr@sulaco:~$ # Disable opt-in policy
bladernr@sulaco:~$ wsman put http://intel.com/wbem/wscim/1/ips-schema/1/IPS_KVMRedirectionSettingData -h $AMT_IP -P 16992 -u admin -p ${AMT_PASSWORD} -k OptInPolicy=false
Now, on that third line, I ran into trouble. I’m not sure why that one kept failing with this error:
Connection failed. response code = 0 Couldn't resolve host name
When the others worked fine. So since this is just disabling the default requirement for Opt-In on KVM connections, I went back into MEBx itself. You can find the setting under User Consent. Set Opt-In from KVM to None, so that no opt-in is required for remote connections.
bladernr@sulaco:~$ # Disable session timeout
bladernr@sulaco:~$ wsman put http://intel.com/wbem/wscim/1/ips-schema/1/IPS_KVMRedirectionSettingData -h $AMT_IP -P 16992 -u admin -p ${AMT_PASSWORD} -k SessionTimeout=0
bladernr@sulaco:~$ # Enable KVM
bladernr@sulaco:~$ wsman invoke -a RequestStateChange http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_KVMRedirectionSAP -h ${AMT_IP} -P 16992 -u admin -p ${AMT_PASSWORD} -k RequestedState=2
These last two first set the session timeout to 0, so that you are never disconnected, and then finally turn KVM on.
I use Remmina for VNC, RDP and similar connections, so I configured a new connection in Remmina and gave it a go. It failed. Looking at the debug log, the connection was quickly terminated. So first I changed the VNC password.
bladernr@sulaco:~$ wsman put http://intel.com/wbem/wscim/1/ips-schema/1/IPS_KVMRedirectionSettingData -h $AMT_IP -P 16992 -u admin -p ${AMT_PASSWORD} -k RFBPassword=Vnc-p@55
The new password was accepted (that was my third attempt at a memorable password that meets all of Intel’s ridiculous requirements. All things considered, however, I don’t believe the issue was the password. See the end for the root cause of my issues connecting initially. Once I had set a new password, I re-configured Remmina and tried again. And again, failure:
[VNC]VNC server supports protocol version 4.0 (viewer 3.8) [VNC]We have 2 security types to read [VNC]0) Received security type 2 [VNC]Selecting security type 2 (0/2 in the list) [VNC]1) Received security type 128 [VNC]Selected Security Scheme 2 [VNC]VNC authentication succeeded [VNC]Desktop name "Intel(r) AMT KVM" [VNC]Connected to VNC server, using protocol version 3.8 [VNC]VNC server default format: [VNC] 16 bits per pixel. [VNC] Least significant byte first in each pixel. [VNC] TRUE colour: max red 31 green 63 blue 31, shift red 11 green 5 blue 0 [VNC]read (104: Connection reset by peer)
But it looks like the password is accepted, so we’re good there. We’re just missing one piece.
It turns out it was one more bit of annoyance from Intel. I finally was able to dig up the KVM settings info from Intel after some Googling. Right there on that page is the following:
If the Intel AMT platform is currently displaying the MEBx, it is not possible to open a KVM session.
I still had MEBx open on the NUC so I could manually change settings if I needed to. I still don’t know why I was unable to set the Opt-In policy remotely. That should have worked, but in the end, the result was what I wanted. I now have KVM control via AMT on my NUC.
