Environment
Novell Access Manager 3 Linux Access Gateway
Novell Access Manager 3 Linux Novell Identity Server
Novell Access Manager 3 Access Administration
Novell Access Manager 3 SUpport Pack 4 applied
Situation
Access Manager setup installed and working fine with a Linux Access Gateway (LAG) and Identity (IDP) Server cluster active. The healcheck for both the LAG and IDP cluster showed green. The Administrator then added a number of secondary/virtual/aliased IP addresses to the IDP servers and restarted the systems. As soon as the systems were restarted, the IDP healthcheck now reported an X through the circle and clicking the actual IDP server IP address returned the following message:
There exist a configured cluster member that is not active. Expected cluster
members 192.168.138.1 192.168.137.1 Active cluster members 192.168.138.1
192.168.137.17
The system had one primary and multiple secondary ipaddresses. The one that was picked up was the last defined secondary IP address.When we removed that address it picked up another secondary 192.168.137.18 but the system never picked up the primary address as being the cluster member.
There exist a configured cluster member that is not active. Expected cluster
members 192.168.138.1 192.168.137.1 Active cluster members 192.168.138.1
192.168.137.17
The system had one primary and multiple secondary ipaddresses. The one that was picked up was the last defined secondary IP address.When we removed that address it picked up another secondary 192.168.137.18 but the system never picked up the primary address as being the cluster member.
Resolution
Apply SP4 Interim Release 2 patch. The new NIDP.JAR file addresses the issue.
When building the configuration for JGroups, we must select a network interface that matches one of the configured cluster member ip addresses. So, we loop through all of the possible cluster ip addresses comparing each to all of the network interfaces available on the box. Once we find a match, that is the ip address to use. However, the compare we used was a "starts with" compare instead of an "equals" compare. So if the ip we wanted was 168.10.12.1, but we enumerated a network interface with ip of 168.10.12.16, since that ip "starts with" the other ip address, it would match and we would get the wrong ip address for JGroups.
When building the configuration for JGroups, we must select a network interface that matches one of the configured cluster member ip addresses. So, we loop through all of the possible cluster ip addresses comparing each to all of the network interfaces available on the box. Once we find a match, that is the ip address to use. However, the compare we used was a "starts with" compare instead of an "equals" compare. So if the ip we wanted was 168.10.12.1, but we enumerated a network interface with ip of 168.10.12.16, since that ip "starts with" the other ip address, it would match and we would get the wrong ip address for JGroups.