[Andre Duguay]

We would like a webex as well

[Andre Duguay]

Here is the response from techsupport:

---

Hello Andre,

We would recommend putting your Production servers on the exception list from this scan. There are some potential problems that could occur as a result of running port vulnerability checks. Mainly it could cause a port to be locked or occupied when Cloverleaf is trying to use them when communicating with outside vendors. Also we have some past

cases from clients reporting PANICS in the engine as a result of memory or network resources running low while running such scans. We also have some cases from clients reporting monitord crashing as a result of such scan. Unfortunately we do not currently have any on documentation on port scans in Cloverleaf. However we have had some reports of clients

having trouble as a result of port scans.

[Andre Duguay]

I just realised that I should also mentioned that we were not just hit with a port scan but also with a VA (Vulnerability Assessment) test.

[Andre Duguay]

Hi Rob,

We are on 5.6 rev2.

I was kinda vague indeed in my statement “brought down with PDL errors” … sorry about that. Here is an example of one of our log that day where we had a multiserver connexion go down with the scan (I have stripped away all irrelevant log noise).

The scan was started at 13:37.

Thread “lisin1” goes down at 13:55.

We restart it at 14:01.

I will follow your suggestion and send this to techsupport.

Thanks

[Andre Duguay]

John,

According to Rob Abbott in a previous message in that same thread, there should not be a problem with 5.6 and above but we are on 5.6 and still several of our connections went down. So good luck with that upcoming test scan.

[Andre Duguay]

Hi,

(Cloverleaf 5.6 on AIX 5.3)

We just “suffered” the same kind of vulnerability test a few days ago. I can see in our logs that they were scanning numerous ports on the engine including port numbers such as ports 28, 31, 34, 46, 51, 57, 58, 69, etc which I think are internal command ports used by Cloverleaf. We were also scanned on ports where we have inbound threads listening in (7005, 7507, 30201, 30202, 30303, 30525, etc).

The scan on the command ports do not seem to have destabilised the processes but the scans on our inbound threads that were at state opening and the one that were up but configured as multi-server were brought down with pdl errors.

Is that normal? Is there a way within Cloverleaf to protect against something like that?

Thanks,

Andr

[Andre Duguay]

That’s good!

Thanks Charlie,

Andr

[Andre Duguay]

I Craig, you are likely to have problems. I had the same question for Quovadx tech support and here is their answer …

---

Solution:

Hi Andre,

but AIX 5.3 is not compatible with CL5.3.

The only UNIX platofrms compatible with CL5.3 is :

AIX 5.1 (32 and 64 bit)

AIX 5.2 (32 and 64 bit)

Solaris 2.8 & 2.9 (32 and 64 bit)

Red Hat Linux 3.0 AS Intel x86 (32 bit)

HP-UX 11.11 (11i) (32 and 64 bit)

Cloverleaf 5.4 and newer are compatible with AIX5.3.

---

[Andre Duguay]

Hi,

Sorry, I should have researched the Forum on Disk-based queueing before asking the question … I just found a very clear description by Rob Abbott on a the topic called “Disk based queuing 5.2 – set by default” initiated by Jim Kosloskey.

We will scheduled another test with this on. We will then have to determine the trade off between performance and committed writes.

😕 For the comments I have seen I do not seem to have the same concerns that the majority … is there something I don’t understand?

For me, it is important that I have on disk a exact picture of all messages at the state they are at at every moment so that when I have a problem with my primary server (crash with loss of memory), I can fail over to my backup and resume processing with what I see in the recovery database. If what is in the recovery database is an image from hours ago, I will resend messages that I have already sent … readmitting patients; re-ordering tests; etc which would lead to chaos. I know the performance is important but it should be second to the integrity of the delivery.

Thanks,

Andre Duguay

[Andre Duguay]

Do we have redundant path? We have from each server 2 fibre channel adapters but going to the same unique switch. This is not our final configuration. We will eventually have 2 switches.

Have I contacted Quovadx? Yes, they say that the writes are commited to disk  😕

❓ There is a parameter at the process level called “Disk-based Queueing” … we’re not using that. Would someone know know what that would change in this scenarion?

Thanks

Andre Duguay

[Author]

Replies