2

After a reboot recently, I have a pair of servers that are now unable to monitor their disk status. Nagios reports:

HP RAID Array
UNKNOWN Error: No controllers detected. -/-/- (LD : []) 

I get the same error running the check manually on the host. When I do, the kernel log shows the following whenever I run that check manually:

Apr  8 17:00:00 www.example.org kernel: [12345.000000] grsec: 
From 10.11.12.13: denied use of iopl() by /opt/hp/hpacucli
/hpacucli.bin[hpacucli.bin:666] uid/euid:0/0 gid/egid:0/0, parent 
/bin/bash[bash:777] uid/euid:0/0 gid/egid:0/]

hpacucli is the tool used to interact with the hardware raid controller and collect things like disk status. It's not surprising it uses iopl(). The grsec docs suggests this is governed by kernel.grsecurity.disable_priv_io but sysctl says that key is unknown, and I can't seem to set it either.

Is there a way to alter this to allow hpacucli access to iopl() without say rebuilding to a non-grsec kernel?

ewwhite
  • 197,159
  • 92
  • 443
  • 809
jldugger
  • 14,342
  • 20
  • 77
  • 129

2 Answers2

1

You shouldn't be using hpacucli these days.
The correct modern tool is hpssacli.

Also, there are more efficient ways to check the hardware RAID controller status. What OS/distribution/version are you running? Do you have the other management agents installed?

ewwhite
  • 197,159
  • 92
  • 443
  • 809
  • We run a mix of gentoo and CentOS on pretty much any vendor you've heard of, and a few you haven't. So we don't use the vendor management agents, just cfengine or chef. – jldugger Apr 10 '15 at 08:06
0

Ironically, the reason this works on our other HPraid hosts is that they're running newer versions of hpacucli, which apparently don't use iopl(). Upgrading hpacucli on these older hosts resolved the problem.

The mystery of how to selectively allow iopl() remains. Perhaps for another day.

jldugger
  • 14,342
  • 20
  • 77
  • 129