17.1.b & Suricata fails on ESXi

[phoenix]

I've left this running overnight and there's no sign of any high CPU use with IDS/IPS enabled and your patch also installed.

What I did do was disable the reporting and SNMP enabled but no SNMP modules activated. I then activated the SNMP Modules one by one and the one that caused the high CPU is enabling the Host Resources module, as soon as I did that the CPU usage went up to 100% and obviously dropped as soon as it was disabled. If it makes any difference the SNMP service is only bound to the LAN interface.

As an additional not, there seems to be a problem doing a reboot, it restarts but seems to have problems checking devices (I think that's where it hung) and I have to reset the VM and it then comes up OK. What information would you need about this problem?

[franco]

Let's start with a console screenshot when its supposedly stuck?


Thanks,
Franco

[phoenix]

Hi Franco

I'll do the reboot shortly and take a screenshot. The screenshot will probably be too large to post here, should I send it via PM?

Meanwhile, I'm also seeing some scsi write errors (in the attached screenshot), are they anything to be concerned about?

[phoenix]

Here's the last image I took of the server hanging, this was after (about) eight minutes of it producing those type of messages - I have earlier shots if you need to see them:

https://i.imgsafe.org/f80f85d772.png

[phoenix]

Here's the last image I took of the server hanging, this was after (about) eight minutes of it producing those type of messages - I have earlier shots if you need to see them:

https://i.imgsafe.org/f80f85d772.png

Hi Franco

I think we can forget this 'reboot problem' - I've installed the rc1 version today (clean install and settings import) and this problem has gone away, it reboots fine from the GUI menu.

I'm also assuming that you added to rc1 the test kernel that I tried  as the CPU load when Suricate is enabled is still low and IPS/IDS works fine for me.

[franco]

Hi Bill,

The CAM error can happen because VMware emulation isn't 100% bug free, but I don't think this is a data corruption, just a "hardware" error that can be recovered from.

Nice to hear about RC1 though it's weird that it would hang right before the kernel yields the system to init (bright white vs. grey). This shouldn't have happened and there is no reason the problem disappeared, because no code that would be responsible for the transition changed. Let's see if this holds up....


Cheers,
Franco