Redfish on COM-HPC Server Base/AADP/AVA?

So I’m trying to leverage Redfish via the AADP and AVA kits I got - according to the Ampere documentation, there is a Redfish endpoint…though shouldn’t that be more of an Adlink COM-HPC Server Base level implementation?

Adlink doesn’t really distribute documentation over the board’s BMC.

Hitting the normal endpoint location /redfish/v1 gives a lot of garbled text - and comparing to other Redfish endpoints on other systems it seems like the content and headers aren’t being set properly:

So what I’ve done so far is:

  1. Enabled the sysadmin user in the Mega-RAC Web console under Maintenance > System Administrator
  2. Set a password for that sysadmin user
  3. Enabled SSH access
  4. Logged in as sysadmin via SSH
  5. Modified the Lighttpd config file in /conf/lighttpd.conf so the bottom stanzas look like this:
$HTTP["url"] =~ "^/redfish" {                                                                  
setenv.add-response-header += ( "Content-Encoding" => "gzip","X-Frame-Options" => "SAMEORIGIN")
setenv.add-response-header += ( "Content-Type" => "application/json" ) 
setenv.add-response-header += ( "Connection" => "keep-alive" )         
setenv.add-response-header += ( "Keep-Alive" => "timeout=60, max=199" )
setenv.add-response-header += ( "Access-Control-Allow-Origin" => "*" ) 
setenv.add-response-header += ( "Vary" => "Accept-Encoding" )                             
setenv.add-response-header += ( "Cache-Control" => "no-cache" )        
setenv.add-response-header += ( "Pragma" => "no-cache" )               
setenv.add-response-header += ( "X-Content-Type-Options" => "nosniff" )    
setenv.add-response-header += ( "X-XSS-Protection" => "1; mode=block" )
}

Which then gives me clean HTML output…but it’s still not the Redfish JSON output that’s expected, it’s the default index.html page located at /usr/local/www/index.html - which itself is a gzip’ed binary blob of a file, but with those response headers shows the normalized HTML:

Taking a closer look at the lighttpd.conf file, it seems like the Redfish extension isn’t even loaded? The path is being handled by some stanzas for setting (the wrong) headers, but there’s no actual fastcgi module or anything loaded…looking on the file system it seems like it’s not even there?

Anyone got any clues, or did I just run into a missing DMTF Redfish implementation issue?

If so…anyone know where I can submit a BMC system bug?

The best place to report a BMC system bug is probably on the IPI Forum, at https://www.ipi.wiki/community/forum in one of the Ampere groups.

I don’t have anything to add as far as the issue you’re hitting.
I love to see folks using RedFish, doing Linux admin work this was my secret sauce in managing a fleet of dysfunctional servers in our datacenter. It helped me dramatically reduce Prod outage and increased MTTF while reducing MTTR.

Thanks for the heads up Rebecca! Link for anyone interested in following along: https://www.ipi.wiki/community/forum/topic/91109/missing-redfish-on-bmc
Cross-posting goes brrrrrr, haha

@pzc Yes, for sure! I’d like to automate against these systems and Redfish is key…once this is figured out I can even share the systems with my colleagues which is the real goal, evangelize the platforms and whatnot. Hoping to not have to reverse engineer the MegaRAC BMC API to do a fakefish sorta thing :crossed_fingers:

fakefish had me cracking me up, you can trademark that. :laughing:

Hopefully you don’t have to go the diy route, RedFish really should take on that effort of being compatible with Ampere gear.

Keep us posted!

Haha, fakefish is a real thing already: GitHub - openshift-metal3/fakefish: An experimental Redfish proxy that calls shell scripts for executing hardware actions

sushy-tools is also pretty handy for virtual environments: GitHub - openstack/sushy-tools: A set of tools to support the development and test of the Sushy library. Mirror of code maintained at opendev.org.

Ampere has a Redfish implementation and it’s really well documented, it’s just that the interface on these dev kits is through the Adlink Server Board - Ampere is set, Adlink not so much.

So it looks like fakefish is the route I’ll need to go down…I got a response via Adlink’s Ask an Expert ticketing system:

Hi Ken,

Sorry for taking a while to get back to you. After checking with our software engineering group, you are correct that RedFish is not implemented at this point. We may allocate resources to do it at a later time, but no specific schedule is given or guaranteed.

Thank you for your patience and understanding!

Best Regards,

Gordon Chen

:upside_down_face:

shoot sorry to hear you’re on your own with it. Thanks for those links I’ll have to check those out.

Well, started to go down the Fakefish route. In my fork I got power functions scripted up and tested, but there doesn’t seem to be any method I can find to attach an ISO from a URL…maybe this bit of progress can inspire someone else, I’ll try to return to do some hacky media redirection stuff in a few weeks if I can find the time…really sad there’s not a good way to remotely mount installation media.

That’s normally a sign that the webserver is sending compressed (gzip, etc.) data without properly setting the required headers. I’d try to use curl --compressed to send this request and see if it works any better.

With the COM-HPC Server Base using the regular AST2500 and especially with it being a dev kit I see at least some chance of getting enough documentation to get OpenBMC ported to the platform.
Might be a worthwhile effort (but I don’t currently have the COM-HPC Server Base locally accessible to me).

Yeah, for some reason the index.html file itself on the BMC is gzip encoded, in addition to the headers not being provided. Once properly processed you find the normal MegaRAC log in page, nothing about Redfish in it.

Gordon Chen from Adlink closed the ticket WONTFIX - very little hope for Redfish on the Dev Kits any time soon, if at all…which is pretty sad considering the $10k I paid for these two systems.

I’m starting to work on porting OpenBMC to the ADLINK systems. So far the kernel boots but the root filesystem fails to mount, I think because the SPI chip I have isn’t supported.

If I can get this working, the BMC will be much more functional.

2 Likes

That’s awesome! Let me know if I can help in any way or do some testing for ya…so long as I don’t end up bricking something lol.

Thanks. I’ve recently got the SSIF interface working between the host and BMC, so you can use ipmitool from the host. I still have work to do to get sensor data and get the SOL working.

Unfortunately at the moment the OpenBMC build requires a 64MB (512MBit) SPI chip while the ADLINK systems come with a 32MB (256MBit), so anyone wanting to try it would need to replace at least one of the SPI chips in the EEPROM sockets. At some point I might see if I can reduce the build down to 32MB.