Operating System - HP-UX
1777014 Members
1488 Online
109062 Solutions
New Discussion юеВ

Re: ServiceGuard subnet security configuration

 
kavanagh_1
Frequent Advisor

ServiceGuard subnet security configuration

Hi,

I am not sure if it is possible to set up the following SG cluster configuration. Can anyone help!

2 node cluster

Node 1 has a Prod package (on one subnet) which can fail over to node 2.

Node 2 has a Dev package (on a different subnet and different NIC) which only runs on node 2.

There is also a dedicated HB lan between the nodes.

In the event of the Prod package failing over from node 1 to node 2 the Prod package would shutdown the Dev package. This not a problem. I have set it up before.

The problem is that there is an additional security requirement in that the Dev users must not be able to get onto the Prod subnet.

On node 2 the two NICs for the Prod and Dev subnets have static IP addresses. Dev Users on the Dev network can telnet to the Prod IP on node 2 and then telnet to the node 1 Prod package floating IP address.

Ideally node 2 would not have a Prod NIC ip address assigned and when the package failed over then just apply the floating IP but I don't think this can be done as the subnet between the nodes would not be monitored by the Prod package.

Any ideas to get over this ?

Many thanks




4 REPLIES 4
V.Tamilvanan
Honored Contributor

Re: ServiceGuard subnet security configuration

Hi,
Why don't you use the facility of /var/adm/inetd.sec and integrate into the PROD package.

Brian M Rawlings
Honored Contributor

Re: ServiceGuard subnet security configuration

That is a tough one, I don't think it can be done as you are describing. MCSG requirements have changed over the years, but last I heard all nodes need to be able to access any subnets involved with the failover process.

This is actually enforced, since when you do the (?) cmapplyconf (or maybe the cmcheckconf), network connectivity is tested, and the process will error out and fail to distribute the cluster files to all nodes, if the networking in the cluster file can't be seen and tested OK by all nodes. I'm short on details, as it's been a couple of years since it bit me, but I recall something like this that gave me a couple of bad days on a Serviceguard implementation once.

But there's always another way to get there, right? Make sure all the subnetting is enabled on all nodes, distribute the files, and then shut down the prod subnet on the DEV box until failover. You should be able to include that in a startup script for the PROD package on DEV, I imagine. You'll probably get some errors in the logs, complaining that some networking is not functional... maybe it would work, maybe not.

One interesting possibility to prevent DEV users from logging into the dev box and accessing the PROD network while in failover mode, would be to have two copies of /etc/passwd. One copy would have all users, the other would only have the PROD users. You could script up a replacement of the file when the failover script runs. Then only PROD users could access the prod system and prod network.

Just a thought. As I said, I'm not sure you can do what you're hoping. But Unix is flexible, even if MCSG isn't.

Hope it gives you some ideas.

--bmr
We must indeed all hang together, or, most assuredly, we shall all hang separately. (Benjamin Franklin)
Sanjay_6
Honored Contributor

Re: ServiceGuard subnet security configuration

Hi,

On the alternate / failover node you must have a lan card with an ip address on the same subnet that belongs to the floating ip address of the package. This is because the floating ip address of the package has to bind itself to a particular lan card and it bind to the lan port whose ip address is in the same subnet as the package ip.

So i guess there is no easy way for you to seperate the dev user to login to the production subnet.

Hope this helps.

Regds
kavanagh_1
Frequent Advisor

Re: ServiceGuard subnet security configuration

Many thanks for your help. I am now looking into using ip filters to block traffic between the subnets within the server.