Home.... | log in.... | Pub my question! | Sign-up....

Java-index >> Web & Directory Servers >> Directory Servers

Access Manager and Directory Proxy Server for DS Issues

Hi.

This is a tricky one, so I thought you'd like to be intruigued too!

Is there a way to ensure persistent connections in the DPS, as it is with other load balancers? If one takes a look at the Deployment example for Access Manager (with failover, shared DS, the works - document 819-6258), it uses a third party load balancer.

The need for persistence is explained well, as follows:

When a request requires information to be written to Directory Server 1, that information is also replicated in Directory Server 2. But the replication takes time to complete. During that time, if a related request is directed by the load balancer to Directory Server 2, the request may fail. For example, when simple persistence is not configured properly, creating a realm from the Access Manager administration console could fail in the following way. A request for the parent entry creation is routed to Directory Server 1, and a second request to create the subentry is routed to Directory Server 2. But if the parent entry request is not yet fully replicated to Directory Server 2, the subentry request fails. The result is a partially created realm which may not contain all its subentries such as realm administration roles. Simple persistence eliminates this type of error. When persistence is properly configured, both the parent entry request and the subentry request are routed to Directory Server 1. The requests are processed in consecutive order. The parent entry is fully created before the subentry request begins processing.

Thus, unless there is a way to have these persistent connections going, can DPS still be used to splt load between the LDAPs?

Also, are such "persistent connections" the same as persistent searches?

Thanks a lot for the help! Have been struggling with this problem for a while now.

[1859 byte] By [ankushkapoor] at [2007-11-26 9:26:48]

«« Sun Ray X Server will not start....
»» query criteria invalid parameter binding problem

# 1

Kind of related, still struggling with the above. The below post is also available in the Access Manager forum, where it would be more appropriate. Am posting it in here just in case someone else too have faced similar problems with AM / DPS or some other product / DPS.

We setup an environment in Windows, and it worked. Here is a detailed account of what was done:

1. Host 1: Start installer, install automatically, chose Directory server, Directory Administration server, Directory Proxy server, Web server, Access Manager.

All installed, and worked fine. (AMConfig.properties, serverconfig.xml, and the info in LDAP service, all pointed to HOST1:389)

2. Host 2: Start installer, install automatically, chose Directory server, Directory Administration server, Directory Proxy server, Web server, Access Manager.

All installed, and worked fine. (AMConfig.properties, serverconfig.xml, and the info in LDAP service, all pointed to HOST2:389)

3. Host 1: Started replication. Set to Master

4. Host 2: Started replication. Set to Master

5. Host 1: Setup replication agreement to Host 2

6. Host 2: Setup replication agreement to Host 1

7. Initiated the remote replica from Host 1 -> Host 2

Note that since default installation uses abc.....xyz as the encryption key, setting this to same was not an issue.

9. Started webserver for Host 1 and logged into AM as amadmin.

10. Added Host 2 FQDN in DNS Aliases / Realms

11. Added http://HOST2_FQDN:80 in the Platform server (instance) list.

12. Started Host 2 webserver. Logged in AM on Host 2, things worked fine.

At this stage, note the following:

a) Host 1:

AMConfig.properties file has

com.iplanet.am.directory.host=host1_FQDN

and

com.iplanet.am.directory.port=389

serverconfig.xml has:

<Server name="Server1" host="host1_FQDN" port="389" type="SIMPLE" />

b) Host 2:

AMConfig.properties file has

com.iplanet.am.directory.host=host2_FQDN

and

com.iplanet.am.directory.port=389

serverconfig.xml has:

<Server name="Server1" host="host2_FQDN" port="389" type="SIMPLE" />

c) If one logs into AM, and checks LDAP servers for LDAP / Policy Configuration / Membership etc services, they all contain Host2_FQDN:389 (which makes sense, since replica 2 was initialized from 1)

Returning back to the configuations:

13. On Host 1, login into the Admin server console of the Directory server. Navigate to the DPS, and confgure the following:

a) Network Group

b) LDAP servers

c) Load Balancing

d) Change Group

e) Action on-bind

f) Allow all actions (permit modification / deletion etc.).

g) any other configuations required - Am willing to give detailed steps if someone needs them to help me / themselves! :)

So now, we have DPS configured and running on Host1:489, and distributing load to DS1 and DS2 on a 50:50 basis.

14. Now, log into AM on Host 1, and instead of Host1_fqdn:389 (for DS) in the following places, specify Host1_fqdn:489 (for the DPS)--

LDAP Authentication

MSISDN server

Membership Service

Policy configuation.

Verified that this propagated to the Policy Configuration service and the LDAP authentication service that are already registered with the default organization.

15. Log out of AM. Following the documentation, modify directory.host and directory.port in AMConfig.properties to point to Host 1_FQDN and 489 respectively. Make this change in AMConfig.properties of both Host 1 as well as 2.

16. Edit serverconfig.xml on both hosts, and instead of they pointing to their local directory servers, point both to host1_FQDN:489

17. When you start the webserver, it will refuse to start. Will spew errors such as:

[https-host1_FQDN]: Sun ONE Web Server 6.1SP5 B06/23/2005 17:36

[https-host1_FQDN]: info: CORE3016: daemon is running as super-user

[https-host1_FQDN]: info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_04] from [Sun Microsystems Inc.]

[https-host1_FQDN]: info: WEB0100: Loading web module in virtual server [https-host1_FQDN] at [/amserver]

[https-host1_FQDN]: warning: WEB6100: locale-charset-info is deprecated, please use parameter-encoding

[https-host1_FQDN]: info: WEB0100: Loading web module in virtual server [https-host1_FQDN] at [/ampassword]

[https-host1_FQDN]: warning: WEB6100: locale-charset-info is deprecated, please use parameter-encoding

[https-host1_FQDN]: info: WEB0100: Loading web module in virtual server [https-host1_FQDN] at [/amcommon]

[https-host1_FQDN]: info: WEB0100: Loading web module in virtual server [https-host1_FQDN] at [/amconsole]

[https-host1_FQDN]: warning: WEB6100: locale-charset-info is deprecated, please use parameter-encoding

[https-host1_FQDN]: info: WEB0100: Loading web module in virtual server [https-host1_FQDN] at [/search]

[https-host1_FQDN]: warning: CORE3283: stderr: netscape.ldap.LDAPException: error result (32); matchedDN = dc=sun,dc=com; No such object (DN changed)

[https-host1_FQDN]: warning: CORE3283: stderr: Got LDAPServiceException code=-1

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.services.ldap.DSConfigMgr.getConnection(DSConfigMgr.java:357)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.services.ldap.DSConfigMgr.getNewFailoverConnection(DSConfigMgr.java :314)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.services.ldap.DSConfigMgr.getNewConnection(DSConfigMgr.java:253)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.services.ldap.DSConfigMgr.getNewProxyConnection(DSConfigMgr.java:18 4)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.services.ldap.DSConfigMgr.getNewProxyConnection(DSConfigMgr.java:19 4)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ums.DataLayer.initLdapPool(DataLayer.java:1248)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ums.DataLayer.(DataLayer.java:190)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ums.DataLayer.getInstance(DataLayer.java:215)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ums.DataLayer.getInstance(DataLayer.java:246)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.sun.identity.sm.ldap.SMSLdapObject.initialize(SMSLdapObject.java:156)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.sun.identity.sm.ldap.SMSLdapObject.(SMSLdapObject.java:124)

[https-host1_FQDN]: warning: CORE3283: stderr: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

[https-host1_FQDN]: warning: CORE3283: stderr: at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor Impl.java:39)

[https-host1_FQDN]: warning: CORE3283: stderr: at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor AccessorImpl.java:27)

[https-host1_FQDN]: warning: CORE3283: stderr: at java.lang.reflect.Constructor.newInstance(Constructor.java:494)

[https-host1_FQDN]: warning: CORE3283: stderr: at java.lang.Class.newInstance0(Class.java:350)

[https-host1_FQDN]: warning: CORE3283: stderr: at java.lang.Class.newInstance(Class.java:303)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.sun.identity.sm.SMSEntry.(SMSEntry.java:216)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.sun.identity.sm.ServiceSchemaManager.(ServiceSchemaManager.java:67)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.am.util.AMClientDetector.getServiceSchemaManager(AMClientDetector.j ava:219)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.am.util.AMClientDetector.(AMClientDetector.java:94)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.sun.mobile.filter.AMLController.init(AMLController.java:85)

[https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterCon fig.java:262)

[https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilter Config.java:322)

[https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java: 120)

[https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3271)

[https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.StandardContext.start(StandardContext.java:3747)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ias.web.WebModule.start(WebModule.java:251)

[https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)

[https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.StandardHost.start(StandardHost.java:652)

[https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)

[https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:355)

[https-host1_FQDN]: warning: CORE3283: stderr: at org.apache.catalina.startup.Embedded.start(Embedded.java:995)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ias.web.WebContainer.start(WebContainer.java:431)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ias.web.WebContainer.startInstance(WebContainer.java:500)

[https-host1_FQDN]: warning: CORE3283: stderr: at com.iplanet.ias.server.J2EERunner.confPostInit(J2EERunner.java:161)

[https-host1_FQDN]: failure: WebModule[/amserver]: WEB2783: Servlet /amserver threw load() exception

[https-host1_FQDN]: javax.servlet.ServletException: WEB2778: Servlet.init() for servlet LoginLogoutMapping threw exception

[https-host1_FQDN]: at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:949)

[https-host1_FQDN]: at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:813)

[https-host1_FQDN]: at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:347 8)

[https-host1_FQDN]: at org.apache.catalina.core.StandardContext.start(StandardContext.java:3760)

[https-host1_FQDN]: at com.iplanet.ias.web.WebModule.start(WebModule.java:251)

[https-host1_FQDN]: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)

[https-host1_FQDN]: at org.apache.catalina.core.StandardHost.start(StandardHost.java:652)

[https-host1_FQDN]: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)

[https-host1_FQDN]: at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:355)

[https-host1_FQDN]: at org.apache.catalina.startup.Embedded.start(Embedded.java:995)

[https-host1_FQDN]: at com.iplanet.ias.web.WebContainer.start(WebContainer.java:431)

[https-host1_FQDN]: at com.iplanet.ias.web.WebContainer.startInstance(WebContainer.java:500)

[https-host1_FQDN]: at com.iplanet.ias.server.J2EERunner.confPostInit(J2EERunner.java:161)

[https-host1_FQDN]: -- Root Cause --

[https-host1_FQDN]: java.lang.NullPointerException

[https-host1_FQDN]: at com.sun.identity.authentication.UI.LoginLogoutMapping.init(LoginLogoutMapping.j ava:71)

[https-host1_FQDN]: at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:921)

[https-host1_FQDN]: at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:813)

[https-host1_FQDN]: at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:347 8)

[https-host1_FQDN]: at org.apache.catalina.core.StandardContext.start(StandardContext.java:3760)

[https-host1_FQDN]: at com.iplanet.ias.web.WebModule.start(WebModule.java:251)

[https-host1_FQDN]: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)

[https-host1_FQDN]: at org.apache.catalina.core.StandardHost.start(StandardHost.java:652)

[https-host1_FQDN]: at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133)

[https-host1_FQDN]: at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:355)

[https-host1_FQDN]: at org.apache.catalina.startup.Embedded.start(Embedded.java:995)

[https-host1_FQDN]: at com.iplanet.ias.web.WebContainer.start(WebContainer.java:431)

[https-host1_FQDN]: at com.iplanet.ias.web.WebContainer.startInstance(WebContainer.java:500)

[https-host1_FQDN]: at com.iplanet.ias.server.J2EERunner.confPostInit(J2EERunner.java:161)

[https-host1_FQDN]:

[https-host1_FQDN]: info: HTTP3072: [LS ls1] http://host1_FQDN:58080 ready to accept requests

[https-host1_FQDN]: startup: server started successfully

Success!

The server https-host1_FQDN has started up.

The server infact, didn't start up (nothing even listening on 58080).

However, if AMConfig.properties is left as it originally was, and only serverconfig.xml files were changed as mentioned above, web servers started fine, and things worked all okay. (Alright, except for some glitches when viewed in /amconsole. If /amserver/console is accessed, all is good. Can this mean that all is still not well? I am not sure).

So far so good. Now comes the sad part. When the same is done on Solaris 9, things dont work. You continue to get the above error, OR the following error, and the web server will refuse to start:

Differences in Solaris and Windows are as follows:

1. Windows hosts have 1 IP and hostname. Solaris hosts have 3 IPs and hostnames (for DS, DPS, and webserver).

No other difference from an architectural perspective.

Any help / insight on why the above is not working (and why the hell does the documentation seem so sketchy / insecure / incorrect).

Thanks a bunch!

ankushkapoor at 2007-7-7 0:05:51 >

top of Java-index,Web & Directory Servers,Directory Servers...

Web & Directory Servers New Topic

Web & Directory Servers Hot Topic