UNSOLVED

squigley

updated

7 years ago

S

squigley

16 Posts

1

3658

October 8th, 2019 08:00

LifeCycle Controller updates

I have wasted a bunch of time recently attempting to update the firmware on some servers that have been running in production (without a reboot) for almost 3 years. The Lifecycle controller can find the Catalog, but then fails to download any of the update packages. I see there are several previous threads regarding this, and it seems to be caused by the downloads.dell.com switching to using HTTPS instead of HTTP, or via ftp.dell.com.

As the LCC firmware had not been updated, it didn't have HTTPS support. Nice chicken and egg problem.

My first attempt was to route the LCC via squid, where I could see the requests, and that's where I saw that it was resolving downloads.dell.com to a random IP each time, presumably a CDN, and then appending /downloads.dell.com/ on the path.. This of course doesn't work, and trying this manually gives you a "no host" error, which makes sense, since the CDN server has no idea what host you are trying to retrieve from when you are connecting to an IP address, instead of a host name.

Replacing the IP with downloads.dell.com gets slightly closer, but of course there is no path of http://downloads.dell.com/downloads.dell.com/some_file, so you get a 400 error, instead of a 404 (?)

I found someone else had written a URL rewrite script in perl, which would replace the IP with downloads.dell.com, and strip the path, and I hacked this in and added more IP addresses, but this only worked so far as to download the Catalog. I was then back to it putting the invalid double path in, and I couldn't work out how to get the regex to match and strip this.

In desperation, I wondered if I could just setup my own update server, with valid paths, so I installed apache on a host on the same subnet as the server, and instead of pointing the LCC to downloads.dell.com, I pointed it to the IP of the apache server, where it attempted to download Catalog.xml.gz. I wget that manually into the webroot of the apache server, and retried on the LCC, which worked.. The server now showed a list of available updates.

Attempting to download/install any failed of course, however the apache access log showed me what it was trying to download, eg downloads.dell.com/FOLDER05590166M/1/iDRAC-with-Lifecycle-Controller_Firmware_40T1C_WN64_2.63.60.61_A00.EXE I would then use "wget -x" to have wget download and the -x switch makes it recreate the directory structure, eg downloads.dell.com/FOLDER05590166M/1/, and then was able to go back to the LCC complaining that the download failed verification (or similar), which is a nice confusing error since the actual problem is that it got a 404.. I could then tell it to retry, and it would successfully download the file from my local webserver, ie [webserverip]/downloads.dell.com/FOLDER05590166M/1/iDRAC-with-Lifecycle-Controller_Firmware_40T1C_WN64_2.63.60.61_A00.EXE and then move on to the next one, where I would repeat the wget process to get the missing file.

After all this I had the 7 update files on my local web server, and the server has now installed them all.

Dell, what an atrocious mess you have made of something that used to work very well.