Hi Dan, On Mon, 2010-09-27 at 02:09 -0700, Dan Lukes wrote: > Hi. > > The Fujitsu's iRMC has implemented proprietary function for > reading/writing internal configuration variables. > > Some of them hold the informations related to host operating system - > for example OS version, hostname, system location and so on. > > Then they are shown on (for example) CLI and WWW interface of iRMC. It's > important especially when you have several boxes - without such > identification and with several sessions opened to different computers > it's hard to distinguish which window is which. > > On supported operating OSes those variables are set by ServerView > drivers. On unsupported OSes they are not set. > > The IPMI interface for reading/writing configspace is proprietary > interface not documented by FSC. I consulted some aspect of problem with > Holger Liebig, but it changes nothing on previous sentence - I get no > documentation of the interface from H.L nor FSC. > > Despite of it I have working implementation in the form of patch against > version 0.8.9 of ipmi-oem. It's tested on PRIMERGY RX100 S5 firmware > 3.77A but it should work on similar system as well - and (more > important) - in the case it doesn't work, it should not harm.
So I take it you reverse engineered it in some fashion? > The resulting implementation work this way: > 1 (write): > ipmi-oem Fujitsu set-system-info SystemName "$( hostname )" > > 2 (read): > ipmi-oem Fujitsu get-system-info SystemName > SystemName="master7.m<censored>z" > > > List of configspace variables I can read/write now: > > Key: CabinetLocation <string> /* SNMP SysLocation */ > Key: SystemName <string> > Key: SystemDescription <string> > Key: SystemContact <string> /* SNMP SysContact */ > Key: ServerCabinetModel <string> > Key: ServerChassisModel <string> > Key: ServerSerialNumber <string> > Key: SystemIP0 <IPv4 (A.B.C.D)> > Key: SystemIP1 <IPv4 (A.B.C.D)> > Key: SystemIP2 <IPv4 (A.B.C.D)> > Key: SystemIP3 <IPv4 (A.B.C.D)> > Key: ServerOperatingSystem <string> > Key: AssetTAG <string> > > My implementation is generic, it's easy to add support for other > variables (I know many other than those listed above), but we need to be > careful as blind playing with configspace may cause BMC malfunction. > > Well - after this long prologue, the question is simple. > > I don't know the project policy related to implementation of > undocumented function. Are you interested to implement such think in > public release of freeipmi ? Generally speaking, I am willing to accept undocumented IPMI support. However, I do wish to be on good terms with all the vendors. I certainly don't want to tick off some vendor by putting something into FreeIPMI they want to keep proprietary for some reason. I know Holger regularly reads this mailing list. If he or anyone from Fujitsu offers a blessing of sorts, then we can iterate through it and eventually get this into FreeIPMI. Regardless of what we do, I think it'd be nice to get it published so others that are interested in it would be able to download it and patch their version of FreeIPMI themselves. Al > You can freely ignore this message if not interested. > > Dan > > -- Albert Chu [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-devel
