Discussion:
Integrity system temperature
(too old to reply)
Rich Jordan
2017-01-31 00:45:56 UTC
Permalink
Raw Message
I think its been asked before but I couldn't find it in a search. On the Alphaservers (many of them) you could pull a system temperature from VMS. We've got an RX-2660 with iLO (but no advanced license) that is getting high temp alerts in the SE log, but a proliant (sans iLO connection, working on that) in the same room is not. Could be different thresholds but we'd like to verify.

For a variety of reasons, but mainly time, getting a full blown management agents/SNMP/yadda setup is not likely to happen so I'm hoping there is a quick and easy OS level way of seeing and recording the temp by polling, as on the Alphas.

Any options on the Integrity?

Thanks
Stephen Hoffman
2017-01-31 01:38:47 UTC
Permalink
Raw Message
Post by Rich Jordan
I think its been asked before but I couldn't find it in a search. On
the Alphaservers (many of them) you could pull a system temperature
from VMS. We've got an RX-2660 with iLO (but no advanced license) that
is getting high temp alerts in the SE log, but a proliant (sans iLO
connection, working on that) in the same room is not. Could be
different thresholds but we'd like to verify.
For a variety of reasons, but mainly time, getting a full blown
management agents/SNMP/yadda setup is not likely to happen so I'm
hoping there is a quick and easy OS level way of seeing and recording
the temp by polling, as on the Alphas.
Any options on the Integrity?
Nope. What you want doesn't exist on most of the Alpha products,
either; only a subset offer SYI$_TEMPERATURE_VECTOR, SYI$_POWER_VECTOR,
SYI$_FAN_VECTOR and SYI$_THERMAL_VECTOR. If the thermal data you need
exists in the server and is not available via the SNMP MIB (via SMH or
otherwise), the temperature is likely only accessible via the HPE
management agent tool chain de jour. The internal API for
environmental data within most systems was really gnarly too, when last
I looked at that.
--
Pure Personal Opinion | HoffmanLabs LLC
Rich Jordan
2017-01-31 16:48:45 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by Rich Jordan
I think its been asked before but I couldn't find it in a search. On
the Alphaservers (many of them) you could pull a system temperature
from VMS. We've got an RX-2660 with iLO (but no advanced license) that
is getting high temp alerts in the SE log, but a proliant (sans iLO
connection, working on that) in the same room is not. Could be
different thresholds but we'd like to verify.
For a variety of reasons, but mainly time, getting a full blown
management agents/SNMP/yadda setup is not likely to happen so I'm
hoping there is a quick and easy OS level way of seeing and recording
the temp by polling, as on the Alphas.
Any options on the Integrity?
Nope. What you want doesn't exist on most of the Alpha products,
either; only a subset offer SYI$_TEMPERATURE_VECTOR, SYI$_POWER_VECTOR,
SYI$_FAN_VECTOR and SYI$_THERMAL_VECTOR. If the thermal data you need
exists in the server and is not available via the SNMP MIB (via SMH or
otherwise), the temperature is likely only accessible via the HPE
management agent tool chain de jour. The internal API for
environmental data within most systems was really gnarly too, when last
I looked at that.
--
Pure Personal Opinion | HoffmanLabs LLC
Thanks Hoff. I knew it was a shot in the dark but what the hey. If they can spring the time I guess we'll check the management agents and SNMP fluff and running to see if its available there.
Michael Moroney
2017-01-31 17:47:15 UTC
Permalink
Raw Message
Post by Rich Jordan
Thanks Hoff. I knew it was a shot in the dark but what the hey.
If they can spring the time I guess we'll check the management agents
and SNMP fluff and running to see if its available there.
Depending on the management processor/iLO in that system and its
firmware, you may already have a web page/SSH/telnet session with the
info that you need. Have you looked? You mentioned something about a
license, is that info only available with a license on that system?
Craig A. Berry
2017-01-31 18:50:39 UTC
Permalink
Raw Message
Post by Michael Moroney
Post by Rich Jordan
Thanks Hoff. I knew it was a shot in the dark but what the hey.
If they can spring the time I guess we'll check the management agents
and SNMP fluff and running to see if its available there.
Depending on the management processor/iLO in that system and its
firmware, you may already have a web page/SSH/telnet session with the
info that you need. Have you looked? You mentioned something about a
license, is that info only available with a license on that system?
What he was asking for was an automated way to get the temperature. He's already mentioned he can see the SE log, which means he can get to the console via telnet and see the temperature by logging in and looking for it (I forget at the moment which menu it's under).

Without an extra-cost license, you cannot use the HPE iLO Remote Management Console or other things that talk the same protocol and can be scripted to pull data out of the console. You also cannot use SSH to talk to the console. You can use HTTPS to get to the web console except by now the SSL certificate will have expired and any decent browser will give you a great deal of grief about it. As far as I know, you cannot install an updated certificate on the console without -- you guessed it -- the extra-cost license.

SMH does not appear to provide temperature and is a security sieve anyway. Dunno, but there may be something in the WBEM stuff:

<https://h41379.www4.hpe.com/openvms/products/wbem/wbem_index.html>

Do I sound cranky? Yes, because trying to get simple things like temperature out of these supposedly high-end console gadgets is a lot harder than it should be.
Stephen Hoffman
2017-01-31 19:06:23 UTC
Permalink
Raw Message
Post by Michael Moroney
Depending on the management processor/iLO in that system and its
firmware, you may already have a web page/SSH/telnet session with the
info that you need. Have you looked? You mentioned something about a
license, is that info only available with a license on that system?
That'd usually be SMH on recent systems — SMH also provides various
SNMP MIBs — and there are issues with the SMH tool.
--
Pure Personal Opinion | HoffmanLabs LLC
f***@gmail.com
2017-02-01 07:00:37 UTC
Permalink
Raw Message
Post by Rich Jordan
I think its been asked before but I couldn't find it in a search. On the Alphaservers (many of them) you could pull a system temperature from VMS. We've got an RX-2660 with iLO (but no advanced license) that is getting high temp alerts in the SE log, but a proliant (sans iLO connection, working on that) in the same room is not. Could be different thresholds but we'd like to verify.
For a variety of reasons, but mainly time, getting a full blown management agents/SNMP/yadda setup is not likely to happen so I'm hoping there is a quick and easy OS level way of seeing and recording the temp by polling, as on the Alphas.
Any options on the Integrity?
Thanks
Maybe I am missing something, but depending on what you call "quick and easy" you can make a small tool based on SYS$SHARE:HPIPMI_API.EXE to read the temperature sensors of an Integrity server with OpenVMS I64.
Craig A. Berry
2017-02-02 01:17:15 UTC
Permalink
Raw Message
Post by f***@gmail.com
Post by Rich Jordan
I think its been asked before but I couldn't find it in a search. On
the Alphaservers (many of them) you could pull a system temperature from
VMS. We've got an RX-2660 with iLO (but no advanced license) that is
getting high temp alerts in the SE log, but a proliant (sans iLO
connection, working on that) in the same room is not. Could be different
thresholds but we'd like to verify.
For a variety of reasons, but mainly time, getting a full blown
management agents/SNMP/yadda setup is not likely to happen so I'm hoping
there is a quick and easy OS level way of seeing and recording the temp
by polling, as on the Alphas.
Any options on the Integrity?
Maybe I am missing something, but depending on what you call "quick
and easy" you can make a small tool based on SYS$SHARE:HPIPMI_API.EXE
to read the temperature sensors of an Integrity server with OpenVMS
I64.
That's very interesting, but without any documentation or examples
(which as far as I could find do not exist) there would be a great deal
of trial and error to figure out how to use those interfaces.
David Froble
2017-02-02 03:28:32 UTC
Permalink
Raw Message
Post by Craig A. Berry
Post by f***@gmail.com
Post by Rich Jordan
I think its been asked before but I couldn't find it in a search. On
the Alphaservers (many of them) you could pull a system temperature from
VMS. We've got an RX-2660 with iLO (but no advanced license) that is
getting high temp alerts in the SE log, but a proliant (sans iLO
connection, working on that) in the same room is not. Could be different
thresholds but we'd like to verify.
For a variety of reasons, but mainly time, getting a full blown
management agents/SNMP/yadda setup is not likely to happen so I'm hoping
there is a quick and easy OS level way of seeing and recording the temp
by polling, as on the Alphas.
Any options on the Integrity?
Maybe I am missing something, but depending on what you call "quick
and easy" you can make a small tool based on SYS$SHARE:HPIPMI_API.EXE
to read the temperature sensors of an Integrity server with OpenVMS
I64.
That's very interesting, but without any documentation or examples
(which as far as I could find do not exist) there would be a great deal
of trial and error to figure out how to use those interfaces.
And we haven't done such in the past?

Most of what I know about the DLM data was gained in this manner. Well, got to
admit, the fine manual was a lot of help. But the layout of RMS locks was all
exploratory.
hb
2017-02-02 09:24:10 UTC
Permalink
Raw Message
Post by Craig A. Berry
Post by f***@gmail.com
Maybe I am missing something, but depending on what you call "quick
and easy" you can make a small tool based on SYS$SHARE:HPIPMI_API.EXE
to read the temperature sensors of an Integrity server with OpenVMS
I64.
That's very interesting, but without any documentation or examples
(which as far as I could find do not exist) there would be a great deal
of trial and error to figure out how to use those interfaces.
I'm sure HP[E] can help with the documentation, as the prefix indicates
that it is their version of IPMI.

As a a start, if you have CockpitMgr:

$ imgexp sys$sysdevice:[cpt.ia64]hpipmi_api.exe
Image Exports (I64), version 1.3
IPMIAPILAYERINIT, type is procedure, value is 0x60680
IPMIAPILAYERUNINIT, type is procedure, value is 0x60698
GET_IPMI_SENSORS, type is procedure, value is 0x606b0
GET_IPMI_FAN_SENSORS_LE, type is procedure, value is 0x606c8
GET_IPMI_FAN_SENSORS_CB, type is procedure, value is 0x606e0
GET_IPMI_POWER_SENSORS_LE, type is procedure, value is 0x606f8
GET_IPMI_POWER_SENSORS_CB, type is procedure, value is 0x60710
GET_IPMI_TEMPERATURE_SENSORS, type is procedure, value is 0x60728
$
$ define/user hpipmi_api sys$sysdevice:[cpt.ia64]hpipmi_api
$ xpd sys$sysdevice:[cpt.ia64]cpt$ipmi.exe
eXternal Procedure and Data list (I64), version 1.7
HPIPMI_API -> SYS$SYSDEVICE:[CPT.IA64]HPIPMI_API:
index 2 maps to GET_IPMI_SENSORS, type is procedure
index 3 maps to GET_IPMI_FAN_SENSORS_LE, type is procedure
index 5 maps to GET_IPMI_POWER_SENSORS_LE, type is procedure
index 7 maps to GET_IPMI_TEMPERATURE_SENSORS, type is procedure
index 0 maps to IPMIAPILAYERINIT, type is procedure
DECC$SHR:
...
$

So you should be able to find out more about the API. At least more than
what is in the documentation on VMS :-)

But be warned, the include files in sys$share match the hpipmi_api.exe
in sys$share, not the one in [CPT.IA64]: they do not know about the _LE
and _CB variants of the functions.
Craig A. Berry
2017-02-02 14:02:47 UTC
Permalink
Raw Message
Post by hb
Post by Craig A. Berry
Post by f***@gmail.com
Maybe I am missing something, but depending on what you call "quick
and easy" you can make a small tool based on SYS$SHARE:HPIPMI_API.EXE
to read the temperature sensors of an Integrity server with OpenVMS
I64.
That's very interesting, but without any documentation or examples
(which as far as I could find do not exist) there would be a great deal
of trial and error to figure out how to use those interfaces.
I'm sure HP[E] can help with the documentation, as the prefix indicates
that it is their version of IPMI.
$ imgexp sys$sysdevice:[cpt.ia64]hpipmi_api.exe
Image Exports (I64), version 1.3
IPMIAPILAYERINIT, type is procedure, value is 0x60680
IPMIAPILAYERUNINIT, type is procedure, value is 0x60698
GET_IPMI_SENSORS, type is procedure, value is 0x606b0
GET_IPMI_FAN_SENSORS_LE, type is procedure, value is 0x606c8
GET_IPMI_FAN_SENSORS_CB, type is procedure, value is 0x606e0
GET_IPMI_POWER_SENSORS_LE, type is procedure, value is 0x606f8
GET_IPMI_POWER_SENSORS_CB, type is procedure, value is 0x60710
GET_IPMI_TEMPERATURE_SENSORS, type is procedure, value is 0x60728
$
$ define/user hpipmi_api sys$sysdevice:[cpt.ia64]hpipmi_api
$ xpd sys$sysdevice:[cpt.ia64]cpt$ipmi.exe
eXternal Procedure and Data list (I64), version 1.7
index 2 maps to GET_IPMI_SENSORS, type is procedure
index 3 maps to GET_IPMI_FAN_SENSORS_LE, type is procedure
index 5 maps to GET_IPMI_POWER_SENSORS_LE, type is procedure
index 7 maps to GET_IPMI_TEMPERATURE_SENSORS, type is procedure
index 0 maps to IPMIAPILAYERINIT, type is procedure
...
$
So you should be able to find out more about the API. At least more than
what is in the documentation on VMS :-)
But be warned, the include files in sys$share match the hpipmi_api.exe
in sys$share, not the one in [CPT.IA64]: they do not know about the _LE
and _CB variants of the functions.
There is no SYS$SYSDEVICE:[CPT] directory on my rx2660 running v8.4 with
update 11. I suppose this sort of thing could vary by hardware model.
The sys$share:hpipmi_api.h has some clues, but, for example, here's the
prototype for the routine that presumably retrieves temperatures:

int get_ipmi_temperature_sensors (unsigned int *pBuffSize,struct
ipmi_temperature_sensor *IpmiTemperatureSensorBuffer);

The struct that is the second argument is defined in the include file,
but which members are inputs and which are outputs? I might guess that
the sensor_id is the input, but how do I get it to pass in? What is this
buffer size that is the first argument?

As I said, many hours of guesswork to get the answer to a simple question.
Stephen Hoffman
2017-02-02 14:46:54 UTC
Permalink
Raw Message
Post by Craig A. Berry
As I said, many hours of guesswork to get the answer to a simple question.
There are Perl and Python libraries that purportedly scrounge IPMI
sensor data from the iLO.

https://metacpan.org/pod/Net::ILO
http://seveas.github.io/python-hpilo/

There are analogs to these two that work with SuperMicro and other IPMI
Interfaces, which would provide a path for supporting this on common
x86-64 servers.

Accessing the iLO via IPMI entirely bypasses that HPIPMI_API.EXE API
and that might be an easier approach than reversing the
(apparently-abandoned and insecure) SMH package. Accessing the iLO
directly also avoids adding SMH as a dependency, though it does add
Python or Perl. And might add a need for the iLO advanced license,
though I've not checked that. It'd also be nice if Perl and Python
were integrated into the base distro for these sort of tasks, too. But
I digress.
--
Pure Personal Opinion | HoffmanLabs LLC
Craig A. Berry
2017-02-03 03:12:06 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by Craig A. Berry
As I said, many hours of guesswork to get the answer to a simple question.
There are Perl and Python libraries that purportedly scrounge IPMI
sensor data from the iLO.
https://metacpan.org/pod/Net::ILO
http://seveas.github.io/python-hpilo/
There are analogs to these two that work with SuperMicro and other IPMI
Interfaces, which would provide a path for supporting this on common
x86-64 servers.
Accessing the iLO via IPMI entirely bypasses that HPIPMI_API.EXE API and
that might be an easier approach than reversing the
(apparently-abandoned and insecure) SMH package. Accessing the iLO
directly also avoids adding SMH as a dependency, though it does add
Python or Perl. And might add a need for the iLO advanced license,
though I've not checked that.
Yes, I've explored that option. I can run Net::ILO on a local Mac (after
installing OpenSSL from source since Apple no longer includes it). With
a bit more fussing about with various Perl dependencies I could probably
run it on VMS. But it fails to connect to the Integrity console with
this error:

Unable to establish SSL connection with <console_ip>:443 [SSL connect
attempt failed error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed]

The only thing I know that might help with this would be to use a
certificate from a trusted CA rather than the self-signed one generated
by the console. But in order to install a trusted certificate, you have
to have the advanced feature license. At least I have not encountered
any other way to enable the relevant administration features.

On a related note (though nothing to do with IPMI), I can't ssh to the
console without getting:

Unable to negotiate with <console_ip> port 22: no matching key exchange
method found. Their offer: diffie-hellman-group1-sha1

In other words, the iLO2 console is in even worse shape than VMS in
terms of getting its security-related giblets updated.
Post by Stephen Hoffman
It'd also be nice if Perl and Python
were integrated into the base distro for these sort of tasks, too. But
I digress.
One can hope.
hb
2017-02-03 13:04:39 UTC
Permalink
Raw Message
Post by Craig A. Berry
On a related note (though nothing to do with IPMI), I can't ssh to the
Unable to negotiate with <console_ip> port 22: no matching key exchange
method found. Their offer: diffie-hellman-group1-sha1
Did you try "ssh -oKexAlgorithms=+diffie-hellman-group1-sha1" ...?
And if the server/console responds with "no matching host key type" or
other errors you may need to add more key types and/or key algorithms.
It's just that your client by default doesn't use old/unsecure
algorithms etc. which are the only ones used by the server/console.
Scott Dorsey
2017-02-03 14:22:04 UTC
Permalink
Raw Message
Post by Craig A. Berry
Unable to negotiate with <console_ip> port 22: no matching key exchange
method found. Their offer: diffie-hellman-group1-sha1
In other words, the iLO2 console is in even worse shape than VMS in
terms of getting its security-related giblets updated.
This is sadly normal. We put ILOs on their own internal network that does
not touch anything else other than a monitoring system. The ILO interfaces
cannot ever be trusted.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Kerry Main
2017-02-04 02:20:55 UTC
Permalink
Raw Message
-----Original Message-----
Scott Dorsey via Info-vax
Sent: February 3, 2017 9:22 AM
Subject: Re: [Info-vax] Integrity system temperature
Post by Craig A. Berry
Unable to negotiate with <console_ip> port 22: no matching key
exchange
Post by Craig A. Berry
method found. Their offer: diffie-hellman-group1-sha1
In other words, the iLO2 console is in even worse shape than VMS in
terms of getting its security-related giblets updated.
This is sadly normal. We put ILOs on their own internal network
that
does not touch anything else other than a monitoring system. The
ILO
interfaces cannot ever be trusted.
--scott
While this key issue is likely another good reason, it is actually a
good security practice to create a dedicated MGMT VLAN on each server
with highly restricted access.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Stephen Hoffman
2017-02-03 15:58:56 UTC
Permalink
Raw Message
Post by Craig A. Berry
Post by Stephen Hoffman
There are Perl and Python libraries that purportedly scrounge IPMI
sensor data from the iLO.
https://metacpan.org/pod/Net::ILO
http://seveas.github.io/python-hpilo/
There are analogs to these two that work with SuperMicro and other IPMI
Interfaces, which would provide a path for supporting this on common
x86-64 servers.
Accessing the iLO via IPMI entirely bypasses that HPIPMI_API.EXE API
and that might be an easier approach than reversing the
(apparently-abandoned and insecure) SMH package. Accessing the iLO
directly also avoids adding SMH as a dependency, though it does add
Python or Perl. And might add a need for the iLO advanced license,
though I've not checked that.
Yes, I've explored that option. I can run Net::ILO on a local Mac
(after installing OpenSSL from source since Apple no longer includes
it).
Apple prefers folks either migrate and use secure transport — which has
an API that is both simpler and that they're aiming to keep
upward-compatible — or for apps to migrate to libressl or otherwise and
embed that, or to migrate and embed OpenSSL as the OpenSSL APIs have
been a moving target. But there is a very old version of OpenSSL for
macOS — the "current" version of the series that was predominant when
Apple started pushing folks over to secure transport — around in macOS
10.12 Sierra.

$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.12
BuildVersion: 16A323
$ openssl version
OpenSSL 0.9.8zh 14 Jan 2016
$

OpenSSL is headed for another round of incompatible API upgrades (as
was recently discussed here), so maybe the folks at VSI will figure out
some changes for OpenVMS? To either wrap and abstract OpenSSL (and
preferably some related APIs), or to provide OpenSSL for those that
need it and migrate to libreSSL or such. But I digress.
Post by Craig A. Berry
With a bit more fussing about with various Perl dependencies I could
probably run it on VMS. But it fails to connect to the Integrity
Unable to establish SSL connection with <console_ip>:443 [SSL connect
attempt failed error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed]
The only thing I know that might help with this would be to use a
certificate from a trusted CA rather than the self-signed one generated
by the console. But in order to install a trusted certificate, you have
to have the advanced feature license. At least I have not encountered
any other way to enable the relevant administration features.
Stop trying to out-think this? Brute force it? Haul over the
locally-generated public certificate from the iLO and explicitly trust
it?

http://h41379.www4.hpe.com/doc/83final/ba554_90007/ch04s02.html

The OpenSSL s_client tool can fetch the public certificate in use via
the iLO, as can other tools. (There's likely also a way to view it
via the iLO itself via some suitably cryptic and arcane command, though
I'm not in a position to rummage the iLO docs or power up a test system
and go look right now.)
Post by Craig A. Berry
On a related note (though nothing to do with IPMI), I can't ssh to the
Unable to negotiate with <console_ip> port 22: no matching key exchange
method found. Their offer: diffie-hellman-group1-sha1
Usual approach is to downgrade the connection security to allow
known-insecure connections, and to haul over the public cert and
explicitly trust it. That is, to add the public cert to the local
trust store. Into the SSL or SSL1 trusted certificate store. (This
whole area is a complete and utter mess, but then — given I'm told
OpenVMS is secure, well-documented and very easy to use — my
interpretation and experience here must clearly be wrong. Pshaw!)

Here's the command typical for connecting to an iLO via ssh (not SSL),
downgrading the connection, sans trusting the cert:

$ ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
-o MACs=hmac-md5,hmac-sha1 ***@ilo.example.org

The above ssh command doesn't reference the SSL certificates, but it's
an ssh connection and not an SSL connection and doesn't need to do that.
Post by Craig A. Berry
In other words, the iLO2 console is in even worse shape than VMS in
terms of getting its security-related giblets updated.
That's also typical of my experience in recent years, unfortunately.
It's how I ended up knowing the aforementioned ssh command.

There's been another round of iLO patches a week or so ago for
ProLiant, and which haven't appeared for Integrity:

https://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c05236950

From what I've heard informally, there's not enough memory present and
free to implement a fix this in the older iLO processors. Apparently
also left unstated was that these Integrity boxes are older servers,
and wholesale server replacements are increasingly expected more
frequently than OpenVMS folks have traditionally been accustomed to
performing.

SMH is similarly down-revision on OpenVMS; in similar straits.
--
Pure Personal Opinion | HoffmanLabs LLC
hb
2017-02-03 23:01:34 UTC
Permalink
Raw Message
$ ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
For convenience you can add the KexAlgorithms etc. to the host in your
.ssh/config, I prefer to add the old algorithm with a "+", which adds it
to the default algorithms - just in case someone updates the server :-)

For what it is worth, the V5.7-ECO5G of HP TCP/IP Services provides more
ciphers and algorithms. That doesn't help when connecting to Eisner,
which uses a different stack. There I need -oHostKeyAlgorithms=+ssh-dss
to get a connection.
Craig A. Berry
2017-02-04 14:36:30 UTC
Permalink
Raw Message
Post by hb
$ ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
Thanks! I was too lazy to work out those details.
Post by hb
For convenience you can add the KexAlgorithms etc. to the host in your
.ssh/config, I prefer to add the old algorithm with a "+", which adds it
to the default algorithms - just in case someone updates the server :-)
That's a good tip, thanks. I used to know that but don't do it often
enough to remember from one time to the next.
Post by hb
For what it is worth, the V5.7-ECO5G of HP TCP/IP Services provides more
ciphers and algorithms. That doesn't help when connecting to Eisner,
which uses a different stack. There I need -oHostKeyAlgorithms=+ssh-dss
to get a connection.
I have V5.7-ECO5. V5.7-ECO5G is nowhere to be found in the HPE patch
site, but it's pretty typical of late that people can find some things
there that I can't and I can find some things that other people can't.
hb
2017-02-04 21:19:48 UTC
Permalink
Raw Message
Post by Craig A. Berry
I have V5.7-ECO5. V5.7-ECO5G is nowhere to be found in the HPE patch
site, but it's pretty typical of late that people can find some things
there that I can't and I can find some things that other people can't.
It seem this is just a backup saveset:
TCPIP-SSH-IA64_V57-ECO5G_2015-11-27.BCK
very likely available as a zip file:
ssh_575g_i64.zip.

I'm just a user on the system, I have no idea how this "kit" made it to
this system. However, this "kit" was also mentioned here:
https://community.hpe.com/t5/Security/SSH-key-generation-multiple-usernames/m-p/6933674#M1888

Anyway, the backup saveset contains a README.TXT:
...
Image Identifier : V5.7-ECO5G

Link Date : 26-NOV-2015

TCPIP Version : 5.7 ECO 5

Files (IA64) : TCPIP$SSH_SCP2.EXE_V57-ECO5G_IA64;1
TCPIP$SSH_SFTP-SERVER2.EXE_V57-ECO5G_IA64;1
...
Files (ALPHA) : TCPIP$SSH_SCP2.EXE_V57-ECO5G_ALPHA;1
TCPIP$SSH_SFTP-SERVER2.EXE_V57-ECO5G_ALPHA;1
...
Installation Instructions:
==========================
(1) On target system, stop SSH client and server using shutdown scripts:
$ @SYS$STARTUP:TCPIP$SSH_CLIENT_SHUTDOWN.COM
$ @SYS$STARTUP:TCPIP$SSH_SHUTDOWN.COM

(2) Copy the images (ALPHA or IA64) to respective locations:
$ COPY *.EXE_V57-ECO5G_ALPHA;1 SYS$COMMON:[SYSEXE]*.EXE;0

(3) Start SSH client and server:
$ @SYS$STARTUP:TCPIP$SSH_CLIENT_STARTUP.COM
$ @SYS$STARTUP:TCPIP$SSH_STARTUP.COM
Chris Scheers
2017-02-07 02:46:44 UTC
Permalink
Raw Message
Post by Craig A. Berry
Post by Stephen Hoffman
Post by Craig A. Berry
As I said, many hours of guesswork to get the answer to a simple question.
There are Perl and Python libraries that purportedly scrounge IPMI
sensor data from the iLO.
https://metacpan.org/pod/Net::ILO
http://seveas.github.io/python-hpilo/
There are analogs to these two that work with SuperMicro and other IPMI
Interfaces, which would provide a path for supporting this on common
x86-64 servers.
Accessing the iLO via IPMI entirely bypasses that HPIPMI_API.EXE API and
that might be an easier approach than reversing the
(apparently-abandoned and insecure) SMH package. Accessing the iLO
directly also avoids adding SMH as a dependency, though it does add
Python or Perl. And might add a need for the iLO advanced license,
though I've not checked that.
Yes, I've explored that option. I can run Net::ILO on a local Mac (after
installing OpenSSL from source since Apple no longer includes it). With
a bit more fussing about with various Perl dependencies I could probably
run it on VMS. But it fails to connect to the Integrity console with
Unable to establish SSL connection with <console_ip>:443 [SSL connect
attempt failed error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed]
The only thing I know that might help with this would be to use a
certificate from a trusted CA rather than the self-signed one generated
by the console. But in order to install a trusted certificate, you have
to have the advanced feature license. At least I have not encountered
any other way to enable the relevant administration features.
On a related note (though nothing to do with IPMI), I can't ssh to the
Unable to negotiate with <console_ip> port 22: no matching key exchange
method found. Their offer: diffie-hellman-group1-sha1
In other words, the iLO2 console is in even worse shape than VMS in
terms of getting its security-related giblets updated.
Post by Stephen Hoffman
It'd also be nice if Perl and Python
were integrated into the base distro for these sort of tasks, too. But
I digress.
One can hope.
I just updated the iLo2 in my DL380G5 to 2.29 (I think it was 2.23
previously).

I needed the update to resolve problems in accessing the Java remote
console from Windows 10, but I think there were also certificate related
updates. (Perhaps those were the Win10 fixes?)

It appears that there is a way to take the Linux version of this update
apart (CP027871.scexe) and do the update from the iLo2 webpage. I
didn't do the update this way, but there are reports that it works.

Would this work for the Integrity iLo2 also?
--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ***@applied-synergy.com
Fax: 817-237-3074
f***@gmail.com
2017-02-06 12:21:58 UTC
Permalink
Raw Message
Post by Craig A. Berry
Post by hb
Post by Craig A. Berry
Post by f***@gmail.com
Maybe I am missing something, but depending on what you call "quick
and easy" you can make a small tool based on SYS$SHARE:HPIPMI_API.EXE
to read the temperature sensors of an Integrity server with OpenVMS
I64.
That's very interesting, but without any documentation or examples
(which as far as I could find do not exist) there would be a great deal
of trial and error to figure out how to use those interfaces.
I'm sure HP[E] can help with the documentation, as the prefix indicates
that it is their version of IPMI.
$ imgexp sys$sysdevice:[cpt.ia64]hpipmi_api.exe
Image Exports (I64), version 1.3
IPMIAPILAYERINIT, type is procedure, value is 0x60680
IPMIAPILAYERUNINIT, type is procedure, value is 0x60698
GET_IPMI_SENSORS, type is procedure, value is 0x606b0
GET_IPMI_FAN_SENSORS_LE, type is procedure, value is 0x606c8
GET_IPMI_FAN_SENSORS_CB, type is procedure, value is 0x606e0
GET_IPMI_POWER_SENSORS_LE, type is procedure, value is 0x606f8
GET_IPMI_POWER_SENSORS_CB, type is procedure, value is 0x60710
GET_IPMI_TEMPERATURE_SENSORS, type is procedure, value is 0x60728
$
$ define/user hpipmi_api sys$sysdevice:[cpt.ia64]hpipmi_api
$ xpd sys$sysdevice:[cpt.ia64]cpt$ipmi.exe
eXternal Procedure and Data list (I64), version 1.7
index 2 maps to GET_IPMI_SENSORS, type is procedure
index 3 maps to GET_IPMI_FAN_SENSORS_LE, type is procedure
index 5 maps to GET_IPMI_POWER_SENSORS_LE, type is procedure
index 7 maps to GET_IPMI_TEMPERATURE_SENSORS, type is procedure
index 0 maps to IPMIAPILAYERINIT, type is procedure
...
$
So you should be able to find out more about the API. At least more than
what is in the documentation on VMS :-)
But be warned, the include files in sys$share match the hpipmi_api.exe
in sys$share, not the one in [CPT.IA64]: they do not know about the _LE
and _CB variants of the functions.
There is no SYS$SYSDEVICE:[CPT] directory on my rx2660 running v8.4 with
update 11. I suppose this sort of thing could vary by hardware model.
The sys$share:hpipmi_api.h has some clues, but, for example, here's the
int get_ipmi_temperature_sensors (unsigned int *pBuffSize,struct
ipmi_temperature_sensor *IpmiTemperatureSensorBuffer);
The struct that is the second argument is defined in the include file,
but which members are inputs and which are outputs? I might guess that
the sensor_id is the input, but how do I get it to pass in? What is this
buffer size that is the first argument?
As I said, many hours of guesswork to get the answer to a simple question.
In order to make it work you need hpipmi_api.exe V2.1. IIRC most (even recent) VMS distributions (VSI and HPE) have V1.0.
hb
2017-02-06 13:03:05 UTC
Permalink
Raw Message
Post by f***@gmail.com
In order to make it work you need hpipmi_api.exe V2.1. IIRC most (even recent) VMS distributions (VSI and HPE) have V1.0.
Which seems to be the one provided by Cockpit Manager:
$ anal/image/select sys$sysdevice:[cpt.ia64]hpipmi_api.exe
SYS$SYSDEVICE:[CPT.IA64]HPIPMI_API.EXE;3
Image
OpenVMS IA64
Shareable
"HPIPMI_API"
"V2.1"
"Linker I02-17"
""
9-DEC-2009 13:03:48.63
$

But, as far as I understand, the API documentation, or the lack of, is
the higher hurdle.
Loading...