Moving the Pilot and Cloning the IPTV Server

Most of the real work today was between about 12:00 and 23:15. The pilot request I finished writing last night went out at 00:38. After that the day was about re-planning the pilot and finding out what the IPTV server actually is.

Core switch questions

At lunchtime I asked whether the hotel's two core switches could run as a pair, with MLAG or similar. They can't, because they are different models and neither supports it. A single ordinary trunk joins them, both run MSTP, and one is the root bridge. Putting both into one MST region would gain nothing without a second link. I was learning, so I changed nothing.

Moving the pilot

The hotel's IT provider couldn't action the pilot request that day. I'm away until the 16th and land at about 10:30 that morning, so the pilot is now Friday the 16th and nothing can start before noon.

To give the provider something to do while I'm away, I wrote a prep email. It covers the core switch VLAN setup on the port that stays disabled until the pilot, tagging on the trunk, the network on the controller, the other building's steps and a port-mapping request. I went through it several times and sent it at 16:49 as a new thread instead of on the old ticket, with the hotel manager copied. A few of my decisions along the way:

I added a section on the hotel's firewall. Its work is the slowest part of the job, and doing it ahead doesn't affect the pilot, since the boxes still go out through the temporary router. After the pilot, the firewall replaces that router as the internet source. I built the plan around two VLANs, one for the boxes and one for the server's own internet leg. Both are isolated and stay off until the main trunk is tagged during a later cutover window, with me on a call.
I cancelled the staff admin access VLAN and the VPN remote access. I'll keep using the temporary router, or fit a remote KVM.
Tagging the main trunk goes last, because it switches the firewall interfaces on live, and it can only come after the isolation rules exist.
I added shared bandwidth limits for both VLANs, config backups before any change, and a save after every switch change.

I still have to decide what to do when two things both want to be the multicast querier on the pilot VLAN, the controller and the island switch. That depends on the day. After sending I filed the as-sent copy, marked the draft superseded, and corrected the runsheet and three older plan files in place.

Who actually makes the IPTV server

In the late afternoon I started asking what the server runs. Existing captures already showed Ubuntu 18.04, a Java and Tomcat admin app, and a separate gateway app for the streaming side. I wanted to know the real manufacturer behind the reseller's brand.

I found it, and I'm confident. The package name of the set-top box launcher, a reseller selling the identical stack and a datasheet matching the port layout all point to the same OEM. The chassis I looked at on site matched the datasheet photo. I then downloaded two files from the admin pages myself, and the live-player app contains the OEM's author string and is signed with the same certificate as the launcher. The "188 GB remaining" and the firmware footer on the admin page narrowed it to the cheaper SSD-only model.

One finding changed my plan. The manufacturer's own upgrade guide says this appliance shouldn't be connected to the internet. That conflicts with my plan to give it internet through the firewall after the pilot, and I need to decide before the 16th.

Cloning the disk

I never had a working shell login for the server, so I decided to take a full disk clone and read that instead. The first attempt failed because the USB stick had been flashed read-only. I switched to imaging onto an external SSD with Clonezilla and took the defaults, and at 21:38 it was done. The server came back up and the admin page responded.

Later I moved the roughly 3.8 GB image to the NAS and read it offline without mounting or booting it. It is a generic desktop PC with an i3 and 8 GB of RAM, running Ubuntu 18.04.3. A closed-source program does the stream conversion, with the Java admin app and a Node app beside it, and nginx handles TLS. That corrected an assumption I'd carried: the box is the DHCP server and the multicast source, and it is not a router for the set-top boxes.

Still open