Integrating Apache 2.x with IBM Web sphere 5.1 x and above
1. Download the Web server plugins for Websphere 5.x from
http://www-1.ibm.com/support/docview.wss?uid=swg24007227 for (5.1x)
http://www-1.ibm.com/support/docview.wss?uid=swg24007265 for (5.0x)
2. Get the file mod_was_ap20_http.dll from the plugin and copy it in
Apache modules directory i.e <APACHE_HOME>/modules directory.
3. Get the plugin-cfg.xml (from Websphere) file
This can be got by
1. Running the command GenPluginCfg in the
<WAS_ROOT>\bin directory (GenPluginCfg.bat)
(where WAS_ROOT is the Websphere Application Server installation directory)
The Plugin-cfg.xml file will be created in the location
<WAS_ROOT>\config\cells\plugin-cfg.xml
2. Running Websphere admin console and exporting the plugin.
Login to the admin console (at port 9090 i.e 127.0.0.1:9090) (This doesn’t require a user ID or a password)
Goto Environment -> Update Web Server Plugin
Click OK to update the plugin configuration file.
The Plugin-cfg.xml file will be created in the location below
<WAS_ROOT>\config\cells\plugin-cfg.xml
4. Copy the plugin-cfg.xml file in Apache modules directory
i.e <APACHE_HOME>/modules directory.
5. Add these lines in the httpd.conf file in the <APACHE_HOME>/conf directory.
LoadModule was_ap20_module modules/mod_was_ap20_http.dll
WebSpherePluginConfig modules/plugin-cfg.xml
6. You can change the location of the log file generated by the plugin by editing the plugin-cfg.xml file. For example, if the Plugin
error log is to be generated in the apache logs directory, the plugin-cfg.xml file can be edited as follows.
<Log LogLevel="Error" Name= "<APACHE_HOME>\logs\http_plugin.log"/>
A simplified form of the plugin-cfg.xml file is shown below.
<Config>
<Log LogLevel="Error" Name="<APACHE_HOME>\logs\http_plugin.log"/>
<VirtualHostGroup Name="default_host">
<VirtualHost Name="*:80"/>
</VirtualHostGroup>
<ServerCluster Name="MyCluster">
<Server Name="server1">
<Transport Hostname="Server-host" Port="9080" Protocol="http"/>
</Server>
</ServerCluster>
<UriGroup Name="MyURIs">
<Uri Name="/snoop/*"/>
<Uri Name="/*"/>
</UriGroup>
<Route ServerCluster="MyCluster" UriGroup="MyURIs" VirtualHostGroup="default_host"/>
</Config>
7.Now restart Websphere and Apache server and type
http://127.0.0.1/snoop and you can see the Websphere's snoop servlet in the browser.
##########################################################################
Tuesday, February 23, 2010
Granting Access to the WebSphere Application Server 6.1 Administration Console
Granting Access to the WebSphere Application Server 6.1 Administration Console
how to get Access to the WebSphere Application Server 6.1 Administration Console. To Grant Access to the WebSphere Application Server 6.1 Administration Console
1. From the WebSphere Administrator console, expand the Users and Groups node.
2. Click “Administrative Group Roles”. A new page opens.
3. Click the Add button. A new page opens.
a. In the field “Group name” field, enter wasadminrole, which was defined earlier.
b. In the “Role(s)” field, select “Administrator”.
c. Click OK and return to the “Administrative Group Roles” page.
4. Click “Save directly to the master configuration”.
how to get Access to the WebSphere Application Server 6.1 Administration Console. To Grant Access to the WebSphere Application Server 6.1 Administration Console
1. From the WebSphere Administrator console, expand the Users and Groups node.
2. Click “Administrative Group Roles”. A new page opens.
3. Click the Add button. A new page opens.
a. In the field “Group name” field, enter wasadminrole, which was defined earlier.
b. In the “Role(s)” field, select “Administrator”.
c. Click OK and return to the “Administrative Group Roles” page.
4. Click “Save directly to the master configuration”.
What are the differences between Base(Express) and ND
What are the differences between Base(Express) and ND(XD)?
Base edition and Express editions are almost similar except packaging structure. XD has advanced capabilities to ND to serve and dealing the complexity of huge applications. The differences between Base and ND edition are…
* Performance wise no difference between Base and Network deployment
Base edition
1) For small scale applications
2) Cell configuration, Dmgr and Node agent not available
3) It is not supporting the horizontal clustering though we can’t avoid single point of failure
Network Deployment edition
1) For more complex and critical large applications
2) Cell configuration, Dmgr and Node agent available
3) Supports vertical, horizontal and mixed clustering so the application will deploy on cluster. It can support Work load management (WLM), single point of failure (SPF) and it support EJB clustering also.
Base edition and Express editions are almost similar except packaging structure. XD has advanced capabilities to ND to serve and dealing the complexity of huge applications. The differences between Base and ND edition are…
* Performance wise no difference between Base and Network deployment
Base edition
1) For small scale applications
2) Cell configuration, Dmgr and Node agent not available
3) It is not supporting the horizontal clustering though we can’t avoid single point of failure
Network Deployment edition
1) For more complex and critical large applications
2) Cell configuration, Dmgr and Node agent available
3) Supports vertical, horizontal and mixed clustering so the application will deploy on cluster. It can support Work load management (WLM), single point of failure (SPF) and it support EJB clustering also.
If the installation fails, what are the probable reasons? Where do I check?
If the installation fails, what are the probable reasons? Where do I check?
* Confirm the installation failed by finding “INSTCONFFAILED” and EXITCODE=1 messages in /logs/install/install.log file.
* If you were enable trace you can find same messages and more info from /logs/install/trace.txt.
* Check the command prompt from which the installation panel was launched for error messages.
* Look up any error or warning messages in the message reference table by selecting the ″Reference″ view in the information center navigation and expanding the ″Messages″ heading.
* Check the profiles logs to find out error messages and proceed according to them
* Missing prerequisites
* Incorrect response file configuration during a silent install
* Errors due to limitations in non-root installations
* Confirm the installation failed by finding “INSTCONFFAILED” and EXITCODE=1 messages in /logs/install/install.log file.
* If you were enable trace you can find same messages and more info from /logs/install/trace.txt.
* Check the command prompt from which the installation panel was launched for error messages.
* Look up any error or warning messages in the message reference table by selecting the ″Reference″ view in the information center navigation and expanding the ″Messages″ heading.
* Check the profiles logs to find out error messages and proceed according to them
* Missing prerequisites
* Incorrect response file configuration during a silent install
* Errors due to limitations in non-root installations
Configuring a reverse proxy server (2.0)
This document describes how to configure a reverse proxy server for Lotus Connections.
Overview
A reverse proxy server intercepts client requests to Lotus Connections servers and, when possible, returns cached data rather than contacting the true destination server. A reverse proxy reduces the amount of traffic that a back-end server must perform to satisfy duplicate requests for data, while at the same time improving the response time for those requests.
You can set up a reverse proxy by using WebSphere Application Server Edge components (formerly Edge Server). Edge components can control client access to Web servers and improve access to Web-based content over the Internet or a corporate intranet.
Infrastructure
The topology in this deployment uses a cluster of Lotus Connections servers connected to a remote HTTP server, a remote database server, and a remote LDAP server. These are deployed in a private network behind a firewall. Client request are intercepted and handled by the transparent proxy server. Users are not aware that a proxy exists in the configuration.This deployment was tested on a Microsoft Windows Server 2003 platform. The following figure illustrates the topology used in this deployment:
Overview
A reverse proxy server intercepts client requests to Lotus Connections servers and, when possible, returns cached data rather than contacting the true destination server. A reverse proxy reduces the amount of traffic that a back-end server must perform to satisfy duplicate requests for data, while at the same time improving the response time for those requests.
You can set up a reverse proxy by using WebSphere Application Server Edge components (formerly Edge Server). Edge components can control client access to Web servers and improve access to Web-based content over the Internet or a corporate intranet.
Infrastructure
The topology in this deployment uses a cluster of Lotus Connections servers connected to a remote HTTP server, a remote database server, and a remote LDAP server. These are deployed in a private network behind a firewall. Client request are intercepted and handled by the transparent proxy server. Users are not aware that a proxy exists in the configuration.This deployment was tested on a Microsoft Windows Server 2003 platform. The following figure illustrates the topology used in this deployment:
Each feature on one WebSphere Application Server profile
Overview
This deployment had the following performance target:
* 15 TPS (Transactions Per Second) with 300 concurrent users.
Infrastructure
The following figure illustrates the topology used in this deployment:
* Activities on Server 1 on WAS Profile 1
* Blogs on Server 1 on WAS Profile 2
* Communities on Server 1 on WAS Profile 3
* Dogear on Server 1 on WAS Profile 4
* Profiles on Server 1 on WAS Profile 5
http://www-10.lotus.com/ldd/lcwiki.nsf/dx/each-feature-on-one-websphere-application-server-profile
This deployment had the following performance target:
* 15 TPS (Transactions Per Second) with 300 concurrent users.
Infrastructure
The following figure illustrates the topology used in this deployment:
This deployment installs each feature on a separate WAS profile. For example:
* Activities on Server 1 on WAS Profile 1
* Blogs on Server 1 on WAS Profile 2
* Communities on Server 1 on WAS Profile 3
* Dogear on Server 1 on WAS Profile 4
* Profiles on Server 1 on WAS Profile 5
http://www-10.lotus.com/ldd/lcwiki.nsf/dx/each-feature-on-one-websphere-application-server-profile
Errors in WebSphere Application Server 6.1.0.9 when enabling SSL
I was working on a SSL configuration in one of my WAS servers and after I changed the default SSL setting I couldn't start the server (server1) anymore.
These are the errors I was getting (SystemOut.log for server1):
-----------------------------------
0000000a WSKeyStore E CWPKI0033E: The keystore located at "...../emsNode01Cell/nodes/emsNode01/trust.p12" failed to load due to the following error: Unable to verify MAC..
0000000a ORBRas E com.ibm.ws.orbimpl.transport.WSTransport createServerSocket P=173499:O=0:CT ORBX0390E: Cannot create listener thread. Exception=[ org.omg.CORBA.INTERNAL: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_SERVER_SOCKET, Exception=com.ibm.websphere.ssl.SSLException: java.io.IOException: Unable to verify MAC. vmcid: 0x49421000 minor code: 77 completed: No ].
----------------------
I went online and the only thing I found was asking me to go to the WAS Console and change the SSL configuration back to default. But, How I can do it if my server doesn't start ?
Well, the answer is easy (after you know how to do it):
Open your Security.xml file and fix it. My error was related to a wrong password in the trust.p12 file.... the password I didn't change. When I created a new SSL configuration with new Trust and Key stores, the password for trust.p12 got changed.
Open the Security.xml and check for any inconsistence
The password for trust.p12 had been changed to the password being used my SametimeTrustStore. Finally, default key and trust stores created by WebSphere have the same password ({xor}CDo9Hgw=), so I changed it back to the original and everything started working again.
This problem has been fixed in 6.1.0.13.
##########################################################################
These are the errors I was getting (SystemOut.log for server1):
-----------------------------------
0000000a WSKeyStore E CWPKI0033E: The keystore located at "...../emsNode01Cell/nodes/emsNode01/trust.p12" failed to load due to the following error: Unable to verify MAC..
0000000a ORBRas E com.ibm.ws.orbimpl.transport.WSTransport createServerSocket P=173499:O=0:CT ORBX0390E: Cannot create listener thread. Exception=[ org.omg.CORBA.INTERNAL: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_SERVER_SOCKET, Exception=com.ibm.websphere.ssl.SSLException: java.io.IOException: Unable to verify MAC. vmcid: 0x49421000 minor code: 77 completed: No ].
----------------------
I went online and the only thing I found was asking me to go to the WAS Console and change the SSL configuration back to default. But, How I can do it if my server doesn't start ?
Well, the answer is easy (after you know how to do it):
Open your Security.xml file and fix it. My error was related to a wrong password in the trust.p12 file.... the password I didn't change. When I created a new SSL configuration with new Trust and Key stores, the password for trust.p12 got changed.
Open the Security.xml and check for any inconsistence
This problem has been fixed in 6.1.0.13.
##########################################################################
Subscribe to:
Posts (Atom)