Plugin configuration file
The plug-in configuration file (plugin-cfg.xml) contains routing information for all applications mapped to the Web server. This file is read by a binary plug-in module loaded in the Web server. An example of a binary plug-in module is the mod_ibm_app_server_http.dll file for IBM HTTP Server on the Windows platform. This is how the location of plugin-cfg.xml is defined in httpd.conf file
LoadModule was_ap20_module "C:\Cert\HTTPServer\Plugins\bin\32bits\mod_was_ap20_http.dll"
WebSpherePluginConfig "C:\Cert\HTTPServer\Plugins\config\webserver1\plugin-cfg.xml"
The binary plug-in module does not change. However, the plug-in configuration file for the binary module needs to be regenerated and propagated to the Web server whenever a change is made to the configuration of applications mapped to the Web server. The binary module reads the XML file to adjust settings and to locate deployed applications for the Web server.
This is how the sample plugin-cfg.xml file on my machine looks like
Important Note When the plug-in configuration file is generated, it does not include admin_host in the list of virtual hosts.
Friday, February 19, 2010
Regenerating plugin configuration file
Regenerating plugin configuration file
The plug-in configuration file (i.e. plugin-cfg.xml), has information on how to route a request from browser to the correct application on the application server. So you will have to regenerate this file in case of there is any changes in websphere application server that affects how the request is routed from the web server to the application server.
The plugin-cfg.xml should be regenerated in following situations
•Installing or removing application
•Creating or changing virtual host
•Creating or changing cluster
•Creating a new server
•Modifying HTTP transport settings
You can manually regenerate plugin using either the GetPluginCfg command, or using the WAS Admin console, or you can also setup the plug-in properties of the web server to enable automatic generation of the file, whenever relevant changes are made
The plug-in configuration file (i.e. plugin-cfg.xml), has information on how to route a request from browser to the correct application on the application server. So you will have to regenerate this file in case of there is any changes in websphere application server that affects how the request is routed from the web server to the application server.
The plugin-cfg.xml should be regenerated in following situations
•Installing or removing application
•Creating or changing virtual host
•Creating or changing cluster
•Creating a new server
•Modifying HTTP transport settings
You can manually regenerate plugin using either the GetPluginCfg command, or using the WAS Admin console, or you can also setup the plug-in properties of the web server to enable automatic generation of the file, whenever relevant changes are made
Manually regenerating plugin-cfg.xml
Manually regenerating plugin-cfg.xml
You can regenerate the plugin-cfg.xml file manually in two ways
Using WAS Admin Console
Login into the WAS Admin console, select the web server for which you want to regenerate plugin and click on Generate Plug-in button. The new plugin-cfg.xml file will be created in the config directory of the web server like this
Using GenPluginCfg command
You can also regenerate plugin using the GenPluginCfg command line tool by going to dmgr_profile_home/bin directory and executing GenPluginCfg command like this
##################################################################
You can regenerate the plugin-cfg.xml file manually in two ways
Using WAS Admin Console
Login into the WAS Admin console, select the web server for which you want to regenerate plugin and click on Generate Plug-in button. The new plugin-cfg.xml file will be created in the config directory of the web server like this
Using GenPluginCfg command
You can also regenerate plugin using the GenPluginCfg command line tool by going to dmgr_profile_home/bin directory and executing GenPluginCfg command like this
##################################################################
Automatic regeneation of plugin-cfg.xml
Automatic regeneation of plugin-cfg.xml
The Web server plug-in configuration service by default regenerates the
plugin-cfg.xml file automatically. You can check the setting from WAS Admin console
When selected, the Web server plug-in configuration service automatically generates the plug-in configuration file whenever the Web server environment changes. For example, the plug-in configuration file is regenerated whenever one of the following activities occurs:
•A new application is deployed on an associated application server.
•The Web server definition is saved.
•An application is removed from an associated application server.
•A new virtual host is defined.
Whenever a virtual host definition is updated, the plug-in configuration file
is automatically regenerated for all of the Web servers.
In my local environment i tried installing a new web application and after installation was completed i checked the plugin-cfg.xml file and it had a entry for newly installed application. Also i could see this in my DMGR's SystemOut.log file
[9/14/09 21:29:23:290 PDT] 00000052 DeploymentMan A ADMS0208I: The configuration synchronization complete for cell.
[9/14/09 21:29:29:540 PDT] 00000048 FileRepositor A ADMR0016I: User defaultWIMFileBasedRealm/server:dmgrCell01_dmgrCellManager01_dmgr modified document cells/dmgrCell01/nodes/dmgrNode01/servers/webserver2/plugin-cfg.xml.
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O PLGC0005I: Plug-in configuration file = C:\Cert\WebSphere\AppServer\profiles\Dmgr01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver2\plugin-cfg.xml
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver2.
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver2.
[9/14/09 21:29:29:556 PDT] 00000048 SystemOut O PLGC0051I: Plug-in configuration file generation started for the Web server dmgrCell01.dmgrNode01.webserver1.
[9/14/09 21:29:30:150 PDT] 00000048 FileRepositor A ADMR0016I: User defaultWIMFileBasedRealm/server:dmgrCell01_dmgrCellManager01_dmgr modified document cells/dmgrCell01/nodes/dmgrNode01/servers/webserver1/plugin-cfg.xml.
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O PLGC0005I: Plug-in configuration file = C:\Cert\WebSphere\AppServer\profiles\Dmgr01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver1\plugin-cfg.xml
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver1.
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver1.
[9/14/09 21:29:56:775 PDT] 00000055 SystemOut O
[9/14/09 21:29:56:775 PDT] 00000055 SystemOut O PLGC0062I: The plug-in configuration file is propagated from C:\Cert\WebSphere\AppServer\profiles\AppSrv01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver2\plugin-cfg.xml to C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-cfg.xml on the Web server computer.
[9/14/09 21:29:56:775 PDT] 0000001f SystemOut O
[9/14/09 21:29:56:775 PDT] 0000001f SystemOut O PLGC0048I: The propagation of the plug-in configuration file is complete for the Web server dmgrCell01.dmgrNode01.webserver2.
[9/14/09 21:29:56:853 PDT] 00000055 SystemOut O
[9/14/09 21:29:56:853 PDT] 00000055 SystemOut O PLGC0062I: The plug-in configuration file is propagated from C:\Cert\WebSphere\AppServer\profiles\AppSrv01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver1\plugin-cfg.xml to C:\Cert\HTTPServer\Plugins/config/webserver1/plugin-cfg.xml on the Web server computer.
[9/14/09 21:29:56:869 PDT] 0000001f SystemOut O
[9/14/09 21:29:56:869 PDT] 0000001f SystemOut O PLGC0048I: The propagation of the plug-in configuration file is complete for the Web server dmgrCell01.dmgrNode01.
####################################################################
The Web server plug-in configuration service by default regenerates the
plugin-cfg.xml file automatically. You can check the setting from WAS Admin console
When selected, the Web server plug-in configuration service automatically generates the plug-in configuration file whenever the Web server environment changes. For example, the plug-in configuration file is regenerated whenever one of the following activities occurs:
•A new application is deployed on an associated application server.
•The Web server definition is saved.
•An application is removed from an associated application server.
•A new virtual host is defined.
Whenever a virtual host definition is updated, the plug-in configuration file
is automatically regenerated for all of the Web servers.
In my local environment i tried installing a new web application and after installation was completed i checked the plugin-cfg.xml file and it had a entry for newly installed application. Also i could see this in my DMGR's SystemOut.log file
[9/14/09 21:29:23:290 PDT] 00000052 DeploymentMan A ADMS0208I: The configuration synchronization complete for cell.
[9/14/09 21:29:29:540 PDT] 00000048 FileRepositor A ADMR0016I: User defaultWIMFileBasedRealm/server:dmgrCell01_dmgrCellManager01_dmgr modified document cells/dmgrCell01/nodes/dmgrNode01/servers/webserver2/plugin-cfg.xml.
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O PLGC0005I: Plug-in configuration file = C:\Cert\WebSphere\AppServer\profiles\Dmgr01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver2\plugin-cfg.xml
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver2.
[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver2.
[9/14/09 21:29:29:556 PDT] 00000048 SystemOut O PLGC0051I: Plug-in configuration file generation started for the Web server dmgrCell01.dmgrNode01.webserver1.
[9/14/09 21:29:30:150 PDT] 00000048 FileRepositor A ADMR0016I: User defaultWIMFileBasedRealm/server:dmgrCell01_dmgrCellManager01_dmgr modified document cells/dmgrCell01/nodes/dmgrNode01/servers/webserver1/plugin-cfg.xml.
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O PLGC0005I: Plug-in configuration file = C:\Cert\WebSphere\AppServer\profiles\Dmgr01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver1\plugin-cfg.xml
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver1.
[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver1.
[9/14/09 21:29:56:775 PDT] 00000055 SystemOut O
[9/14/09 21:29:56:775 PDT] 00000055 SystemOut O PLGC0062I: The plug-in configuration file is propagated from C:\Cert\WebSphere\AppServer\profiles\AppSrv01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver2\plugin-cfg.xml to C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-cfg.xml on the Web server computer.
[9/14/09 21:29:56:775 PDT] 0000001f SystemOut O
[9/14/09 21:29:56:775 PDT] 0000001f SystemOut O PLGC0048I: The propagation of the plug-in configuration file is complete for the Web server dmgrCell01.dmgrNode01.webserver2.
[9/14/09 21:29:56:853 PDT] 00000055 SystemOut O
[9/14/09 21:29:56:853 PDT] 00000055 SystemOut O PLGC0062I: The plug-in configuration file is propagated from C:\Cert\WebSphere\AppServer\profiles\AppSrv01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver1\plugin-cfg.xml to C:\Cert\HTTPServer\Plugins/config/webserver1/plugin-cfg.xml on the Web server computer.
[9/14/09 21:29:56:869 PDT] 0000001f SystemOut O
[9/14/09 21:29:56:869 PDT] 0000001f SystemOut O PLGC0048I: The propagation of the plug-in configuration file is complete for the Web server dmgrCell01.dmgrNode01.
####################################################################
Manually propagating the plug-in configuration file
Manually propagating the plug-in configuration file
After a plug-in configuration file is regenerated, it needs to be propagated to the Web server. The configuration service can automatically propagate the plugin-cfg.xml file to a Web server machine if it is configured on a managed node, and to an IBM HTTP Server if it is configured on an unmanaged node. For other scenarios, you must manually copy the file to the Web server machines. You can manually propagate the file by copying it from the application server machine to the Web server machine, or you can do it from the administrative console.
I tried propagating the plugin-cfg.xml file manually using the WAS Admin console by selecting the server and clicking on Propageate Plug-in button
Important: The Web server binary plug-in module checks for a new configuration file every 60 seconds. You can wait for the plug-in to find the changes, or you can restart the Web sever to invoke the changes immediately
After a plug-in configuration file is regenerated, it needs to be propagated to the Web server. The configuration service can automatically propagate the plugin-cfg.xml file to a Web server machine if it is configured on a managed node, and to an IBM HTTP Server if it is configured on an unmanaged node. For other scenarios, you must manually copy the file to the Web server machines. You can manually propagate the file by copying it from the application server machine to the Web server machine, or you can do it from the administrative console.
I tried propagating the plugin-cfg.xml file manually using the WAS Admin console by selecting the server and clicking on Propageate Plug-in button
Important: The Web server binary plug-in module checks for a new configuration file every 60 seconds. You can wait for the plug-in to find the changes, or you can restart the Web sever to invoke the changes immediately
Automatically propagating the plugin-cfg.xml
Automatically propagating the plugin-cfg.xml
The Web server plug-in configuration service by default propagates the plugin-cfg.xml file automatically
In my local environment both automatic regeneration and propagation of plugin is truned on so when i install application it automatically regenerates the plugin-cfg.xml and then copies it to the C:\Cert\HTTPServer\Plugins/config/webserver1 directory
##############################################################################
The Web server plug-in configuration service by default propagates the plugin-cfg.xml file automatically
In my local environment both automatic regeneration and propagation of plugin is truned on so when i install application it automatically regenerates the plugin-cfg.xml and then copies it to the C:\Cert\HTTPServer\Plugins/config/webserver1 directory
##############################################################################
Load balancing options
Load balancing options
You can specify the load balancing option that the plug-in uses when sending requests to the various application servers associated with that Web server
This field corresponds to the LoadBalanceWeight element in the plugin-cfg.xml file. We have two options to choose from for the load balancing
•Round robin (default): When using this algorithm, the plug-in selects, at random, a cluster member from which to start. The first successful browser request will be routed to this cluster member and then its weight is decremented by one. New browser requests are then sent round robin to the other application servers and, subsequently, the weight for each application server is decremented by one. The spreading of the load is equal between application servers until one application server reaches a weight of zero. From then on, only application servers without a weight higher than zero will receive routed requests. The only exception to this pattern is when a cluster member is added or restarted.
•RandomRequests are passed to cluster members randomly. Weights are not taken into account as in the round robin algorithm. The only time the application servers are not chosen randomly is when there are requests with associated sessions. When the random setting is used, cluster member election does not take into account where the last request was handled. This means that a new request could be handled by the same cluster member as the last request.
######################################################################
You can specify the load balancing option that the plug-in uses when sending requests to the various application servers associated with that Web server
This field corresponds to the LoadBalanceWeight element in the plugin-cfg.xml file. We have two options to choose from for the load balancing
•Round robin (default): When using this algorithm, the plug-in selects, at random, a cluster member from which to start. The first successful browser request will be routed to this cluster member and then its weight is decremented by one. New browser requests are then sent round robin to the other application servers and, subsequently, the weight for each application server is decremented by one. The spreading of the load is equal between application servers until one application server reaches a weight of zero. From then on, only application servers without a weight higher than zero will receive routed requests. The only exception to this pattern is when a cluster member is added or restarted.
•RandomRequests are passed to cluster members randomly. Weights are not taken into account as in the round robin algorithm. The only time the application servers are not chosen randomly is when there are requests with associated sessions. When the random setting is used, cluster member election does not take into account where the last request was handled. This means that a new request could be handled by the same cluster member as the last request.
######################################################################
Implementing Federated repository
Implementing Federated repository
I used information in Expand your user registry options with a federated repository in WebSphere Application Server V6.1 article for configuring federated repository
http://www.ibm.com/developerworks/websphere/techjournal/0701_ilechko/0701_ilechko.html
########################################################################
What is federated repository
Before now, the support in IBM WebSphere Application Server for environments where user information was stored in multiple independent user registries was somewhat limited. Prior to Version 6.1, the only registry options available were:
•Local operating system registry.
•A single, standalone Lightweight Directory Access Protocol (LDAP) registry.
•A single implementation of the Custom User Registry interface.
It is possible to implement a Custom User Registry that enables access to multiple other registries, but this can involve a significant development effort that ultimately would only support read-only operations.
WebSphere Application Server V6.1 provides a new option: a federated user repository. This feature makes it much simpler to use multiple repositories, since this capability is achieved through configuration -- rather than development -- with the use of the new Virtual Member Manager (VMM).
In essence, this feature provides the ability to map entries from multiple individual user repositories into a single virtual repository. The federated repository consists of a single named realm, which is a set of independent user repositories. Each repository may be an entire external repository or, in the case of LDAP, a subtree within that repository. The root of each repository is mapped to something called a base entry within the federated repository, which is basically a starting point within the hierarchical namespace of the virtual realm.
What we are discussing here is the idea of one logical registry containing users from multiple underlying repositories. To the WebSphere Application Server runtime, there is still only one registry, and thus, all applications in the cell still share this one single registry
A federated repository enables you to use multiple repositories with WebSphere Application Server V6.1. These repositories, which can be file-based repositories, LDAP repositories, or a sub-tree of an LDAP repository, are defined and theoretically combined under single realm. All of the user repositories that are configured under the federated repository functionality are transparent to WebSphere Application Server.
Tips for multiple user repositories: The user ID and the DN for an LDAP repository must be unique in multiple user repositories that are configured under the same federated repository configuration. In addition, the federated repositories functionality in WebSphere Application Server supports the logical joining of entries across multiple user repositories when the application server searches and retrieves entries from the repositories
##################################################################################
I used information in Expand your user registry options with a federated repository in WebSphere Application Server V6.1 article for configuring federated repository
http://www.ibm.com/developerworks/websphere/techjournal/0701_ilechko/0701_ilechko.html
########################################################################
What is federated repository
Before now, the support in IBM WebSphere Application Server for environments where user information was stored in multiple independent user registries was somewhat limited. Prior to Version 6.1, the only registry options available were:
•Local operating system registry.
•A single, standalone Lightweight Directory Access Protocol (LDAP) registry.
•A single implementation of the Custom User Registry interface.
It is possible to implement a Custom User Registry that enables access to multiple other registries, but this can involve a significant development effort that ultimately would only support read-only operations.
WebSphere Application Server V6.1 provides a new option: a federated user repository. This feature makes it much simpler to use multiple repositories, since this capability is achieved through configuration -- rather than development -- with the use of the new Virtual Member Manager (VMM).
In essence, this feature provides the ability to map entries from multiple individual user repositories into a single virtual repository. The federated repository consists of a single named realm, which is a set of independent user repositories. Each repository may be an entire external repository or, in the case of LDAP, a subtree within that repository. The root of each repository is mapped to something called a base entry within the federated repository, which is basically a starting point within the hierarchical namespace of the virtual realm.
What we are discussing here is the idea of one logical registry containing users from multiple underlying repositories. To the WebSphere Application Server runtime, there is still only one registry, and thus, all applications in the cell still share this one single registry
A federated repository enables you to use multiple repositories with WebSphere Application Server V6.1. These repositories, which can be file-based repositories, LDAP repositories, or a sub-tree of an LDAP repository, are defined and theoretically combined under single realm. All of the user repositories that are configured under the federated repository functionality are transparent to WebSphere Application Server.
Tips for multiple user repositories: The user ID and the DN for an LDAP repository must be unique in multiple user repositories that are configured under the same federated repository configuration. In addition, the federated repositories functionality in WebSphere Application Server supports the logical joining of entries across multiple user repositories when the application server searches and retrieves entries from the repositories
##################################################################################
Main components of WebSphere security
Main components of WebSphere security
WAS 6.1 Security has three main components
•Authentication protocol: The authentication protocol is used for Remote Method Invocation (RMI) over the Internet InterORB Protocol (IIOP) requests when security is enabled. WebSphere Application Server is configured to use Common Secure Interoperability Version 2 (CSIV2) by default. Secure Authentication Service has been deprecated and will be removed from future WebSphere releases. The CSIV2 is defined by the Object Management Group (OMG) as a standard authentication protocol for vendors to interoperate securely.
•Authentication mechanism: The WebSphere Application Server uses Lightweight Third Party Authentication (LTPA) as the default authentication mechanism.LTPA supports forwardable credentials and, for security reasons, a configurable expiration time is set on the credentials. The use of LTPA allows you to enable single sign-on (SSO) for your security domain
•User account repository: The WAS 6.1 server supports 4 different types of user repository
#################################################################################
WAS 6.1 Security has three main components
•Authentication protocol: The authentication protocol is used for Remote Method Invocation (RMI) over the Internet InterORB Protocol (IIOP) requests when security is enabled. WebSphere Application Server is configured to use Common Secure Interoperability Version 2 (CSIV2) by default. Secure Authentication Service has been deprecated and will be removed from future WebSphere releases. The CSIV2 is defined by the Object Management Group (OMG) as a standard authentication protocol for vendors to interoperate securely.
•Authentication mechanism: The WebSphere Application Server uses Lightweight Third Party Authentication (LTPA) as the default authentication mechanism.LTPA supports forwardable credentials and, for security reasons, a configurable expiration time is set on the credentials. The use of LTPA allows you to enable single sign-on (SSO) for your security domain
•User account repository: The WAS 6.1 server supports 4 different types of user repository
#################################################################################
Role Mapping in installed application
Role Mapping in installed application
If you did not map application roles to users during installation you can map security roles to users and groups in installed application by following these rules
•Go the WAS Admin COnsole, select the enterprise application in which you want to map roles, If your application defines roles, then you will see "Security role to user/group mapping" link in the Detail properties section, click on that link
•When you click on that link you will get a "Security role to user/group mapping" page like this, which will list out all the roles in your application and let you map those roles
##############################################################################
If you did not map application roles to users during installation you can map security roles to users and groups in installed application by following these rules
•Go the WAS Admin COnsole, select the enterprise application in which you want to map roles, If your application defines roles, then you will see "Security role to user/group mapping" link in the Detail properties section, click on that link
•When you click on that link you will get a "Security role to user/group mapping" page like this, which will list out all the roles in your application and let you map those roles
##############################################################################
Procedure to enable SSL between web server and WebSphere Application Server
Procedure to enable SSL between web server and WebSphere Application Server
I wanted to try enabling SSL between my WebServer and WebSphere Application Server so i followed this process to do that
•Create 2 self signed certificates one is C:\Cert\HTTPServer\conf\keys\WAS6PluginCertificates.kdb and other is C:\Cert\WebSphere\AppServer\profiles\Dmgr01\config\cells\dmgrCell01\WAS6WebContainerCertificates.jks
Creating self signed certificate
IBM provides a ikeyman tool that you can use to create self signed certificate and manage keys by following these steps
1.Go to the WAS_HOME/bin directory and execute ikeyman tool, it will open a GUI based tool like this
2.Now click on Key Database File - New. It will open a dialog box, in that change Key Database type to CMS and enter file and path name. In my case i am creating WAS6PluginCertificates.kdb file in C:\Cert\HTTPServer\conf\keys\ directory and click OK
3.It will ask you for the password for the Key database file, enter a password, then check Stash the password to a file checkbox.
4.It will create a .kdb file and import bunch of keys for you by default and show a message like this
5.Once the .kdb file is created next step is to create a Self Signed certificate so click on Create - New Self Signed Certificate like this
6.Enter the details for self signed certificate such as, key label, Organizations,...
7.Thats it your self signed certificate is created, you can check them by going to the directory where we saved it. You will see 4 different files for that certificate are created out of that .sth is the stash password file
#####################################################################################
•Exchange public keys of self signed certificates
This section provides details and step-by-step instructions for exchanging public certificates between two key stores or trust (certificate) stores. You must perform the certificate exchange when you want to set up trust between two parties based on certificates. Usually you use this process with self-signed certificates because real certificates issued by well-known Certificate Authorities are already included in the key and trust stores.
•Start ikeyman and open the file that you just C:\Cert\HTTPServer\conf\keys\WAS6PluginCertificates.kdb, whose public certificate you want to export
•Now select the personal certificate that you created, in my case it is WASPluginCertificate and click on Extract Certificate button
•ikeyman tool will display a dialog where you can set location where the public certificat should be exported. Export it to c:\temp\publiccertificate\WAS6PluginCertificates.arm
•Now open the C:\Cert\WebSphere\AppServer\profiles\Dmgr01\config\cells\dmgrCell01\WAS6WebContainerCertificates.jks file in iKeyman tool
•Switch to the Signer certificate view by selecting signer certificate in the key database content section
•Now click on add, and it will show you the Add CA's certificate from file dialog, select the c:\temp\publiccertificate\WAS6PluginCertificates.arm file that you exported and click OK
•It will ask you to enter a lable for the public certificate enter WAS6PluginCertificatesCertificate.
•Now you should be able to see the certificate that you just imported in the list
I wanted to try enabling SSL between my WebServer and WebSphere Application Server so i followed this process to do that
•Create 2 self signed certificates one is C:\Cert\HTTPServer\conf\keys\WAS6PluginCertificates.kdb and other is C:\Cert\WebSphere\AppServer\profiles\Dmgr01\config\cells\dmgrCell01\WAS6WebContainerCertificates.jks
Creating self signed certificate
IBM provides a ikeyman tool that you can use to create self signed certificate and manage keys by following these steps
1.Go to the WAS_HOME/bin directory and execute ikeyman tool, it will open a GUI based tool like this
2.Now click on Key Database File - New. It will open a dialog box, in that change Key Database type to CMS and enter file and path name. In my case i am creating WAS6PluginCertificates.kdb file in C:\Cert\HTTPServer\conf\keys\ directory and click OK
4.It will create a .kdb file and import bunch of keys for you by default and show a message like this
5.Once the .kdb file is created next step is to create a Self Signed certificate so click on Create - New Self Signed Certificate like this
6.Enter the details for self signed certificate such as, key label, Organizations,...
7.Thats it your self signed certificate is created, you can check them by going to the directory where we saved it. You will see 4 different files for that certificate are created out of that .sth is the stash password file
#####################################################################################
•Exchange public keys of self signed certificates
This section provides details and step-by-step instructions for exchanging public certificates between two key stores or trust (certificate) stores. You must perform the certificate exchange when you want to set up trust between two parties based on certificates. Usually you use this process with self-signed certificates because real certificates issued by well-known Certificate Authorities are already included in the key and trust stores.
•Start ikeyman and open the file that you just C:\Cert\HTTPServer\conf\keys\WAS6PluginCertificates.kdb, whose public certificate you want to export
•Now select the personal certificate that you created, in my case it is WASPluginCertificate and click on Extract Certificate button
•ikeyman tool will display a dialog where you can set location where the public certificat should be exported. Export it to c:\temp\publiccertificate\WAS6PluginCertificates.arm
•Now open the C:\Cert\WebSphere\AppServer\profiles\Dmgr01\config\cells\dmgrCell01\WAS6WebContainerCertificates.jks file in iKeyman tool
•Switch to the Signer certificate view by selecting signer certificate in the key database content section
•Now click on add, and it will show you the Add CA's certificate from file dialog, select the c:\temp\publiccertificate\WAS6PluginCertificates.arm file that you exported and click OK
•It will ask you to enter a lable for the public certificate enter WAS6PluginCertificatesCertificate.
•Now you should be able to see the certificate that you just imported in the list
Managed vs unmanaged processes
Managed vs unmanaged processes
A node is a logical grouping of managed servers. A node usually corresponds to a logical or physical computer system with a distinct IP host address. Nodes cannot span multiple computers.
Nodes in the network deployment topology can be managed or unmanaged. A managed node has a node agent process that manages its configuration and servers. Unmanaged nodes do not have a node agent.
A managed node has a node agent that manages all servers on a node, whether the servers are WebSphere Application Servers, Java Message Service (JMS) servers (on Version 5 nodes only), Web servers, or generic servers. The node agent represents the node in the management cell and keeps the configuration up to date.
1.Managed node: A managed node has a node agent that manages all servers on a node, whether the servers are WebSphere Application Servers, Java Message Service (JMS) servers (on Version 5 nodes only), Web servers, or generic servers. The node agent represents the node in the management cell and keeps the configuration up to date. All WAS processes are called managed servers or managed processes, meaning that all are parto f a single administration domain (cell) and results can be centerally managed and monitored. In WAS following processes are managed process
◦Deployment Manager
◦Node Agent
◦Application Server
◦JMS Server
2.Unmanaged nodes: An unmanaged node does not have a node agent to manage its servers. Unmanaged nodes in the Network Deployment environment can have server definitions such as Web servers, but not Application Server definitions. Unmanaged nodes in the Network Deployment environment cannot have a node agent added to it, and therefore cannot become a managed node. In the stand-alone Application Server environment, nodes do not have node agents and are also considered unmanaged nodes. The deployment manager cannot manage a stand-alone Application Server because it is not known to the cell. A stand-alone Application Server can be federated. When it is federated, a node agent is automatically created, and the node becomes a managed node in the cell.
A supported Web server can be on a managed node or an unmanaged node. You can define only one Web server to a stand-alone WebSphere Application Server node. This Web server is defined on an unmanaged node. You can define Web servers to the deployment manager. These Web servers can be defined on managed or unmanaged nodes.
A node is a logical grouping of managed servers. A node usually corresponds to a logical or physical computer system with a distinct IP host address. Nodes cannot span multiple computers.
Nodes in the network deployment topology can be managed or unmanaged. A managed node has a node agent process that manages its configuration and servers. Unmanaged nodes do not have a node agent.
A managed node has a node agent that manages all servers on a node, whether the servers are WebSphere Application Servers, Java Message Service (JMS) servers (on Version 5 nodes only), Web servers, or generic servers. The node agent represents the node in the management cell and keeps the configuration up to date.
1.Managed node: A managed node has a node agent that manages all servers on a node, whether the servers are WebSphere Application Servers, Java Message Service (JMS) servers (on Version 5 nodes only), Web servers, or generic servers. The node agent represents the node in the management cell and keeps the configuration up to date. All WAS processes are called managed servers or managed processes, meaning that all are parto f a single administration domain (cell) and results can be centerally managed and monitored. In WAS following processes are managed process
◦Deployment Manager
◦Node Agent
◦Application Server
◦JMS Server
2.Unmanaged nodes: An unmanaged node does not have a node agent to manage its servers. Unmanaged nodes in the Network Deployment environment can have server definitions such as Web servers, but not Application Server definitions. Unmanaged nodes in the Network Deployment environment cannot have a node agent added to it, and therefore cannot become a managed node. In the stand-alone Application Server environment, nodes do not have node agents and are also considered unmanaged nodes. The deployment manager cannot manage a stand-alone Application Server because it is not known to the cell. A stand-alone Application Server can be federated. When it is federated, a node agent is automatically created, and the node becomes a managed node in the cell.
A supported Web server can be on a managed node or an unmanaged node. You can define only one Web server to a stand-alone WebSphere Application Server node. This Web server is defined on an unmanaged node. You can define Web servers to the deployment manager. These Web servers can be defined on managed or unmanaged nodes.
Subscribe to:
Posts (Atom)