- Install Portal 22.214.171.124
- Enable your security to the same backend LDAP of which your previous server is authenticating. If it's a different LDAP, make sure that the LDAP branches (usersand groups) are the same as your previous LDAP.
- Install your target database server.
- Do the database transfer.
- Install the following fixes on your 5.1 environment : PK27753 PK28148 PK29999 PK30718 PK31425 PK32194 PK32211 PK32556 PK32626 PK34624 PK39530 PK42729 PK44723 PK47799 PK48653 PK53001 PK62044 PK63553 PK64160 PK40171
- If there's any RSS Portlet for 5.1, update it with the latest version.
- If portal 5.1 has deleted pages, ensure that you use the deleted cleanup service. Check the information center.
- If you have deleted users or groups, Deregister the users and group. Follow the procedures in Websphere Portal 5.1information center.
- stop and start your portal 5.1 to test.
- Considering that you have installed an HTTP Server, kindly change back the WpsHostPort to port 9081 instead of 80.
- Edit the file soap.clients.props and change the settings of com.ibm.SOAP.requestTimeout to a higher number than 180. (Suggests is to increase to 1800).
- Run WPmigrate with the portal-pre-upgrade task on Websphere Portal 5.1 from the CD_root/migration/portal_migration directory on the WebSphere Application Server Network Deployment Version 6.1 Supplements CD. This CD comes with WebSphere Portal and can be used on either Windows or UNIX. Run by executing below :
WPmigrate.bat portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword -DGroupExport="true"
backupDirectory - The directory where data from the earlier server will be stored for subsequent use with the portal-post-upgrade task. If this directory does not exist, the portal-pre-upgrade task creates it. For example, if you specify mybackup, the migration task stores the data under the mybackup directory.
currentPortalDirectory - The directory where the earlier portal server is installed.
currentPortalAdminId - The administrator ID for the earlier portal server. This value is not required if it is already specified in the wpconfig.properties file on the earlier portal server.
currentPortalAdminPwd - The administrator password for the earlier portal server.
DbPassword - The DBMS user password for the earlier portal server. Specify this property value in the command line only if the property is not already specified as follows :
In WebSphere Portal V5.1.0, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, or 18.104.22.168, the property value is specified in the wpconfig.properties file, next to the property name DbPassword.
In WebSphere Portal V22.214.171.124 or later, the property value is specified in the wpconfig_dbdomain.properties file, next to the property name release.DbPassword.
All other database properties must be specified in the properties file.
GroupExport - This is optional. On my part, since it's integrated with LDAP, I didn't need to export the group. No errors occurred. This exports groups from the earlier version when the value is set to true. This property is set by default to false.
- Once run, check the allout.xml file to see the results.
Sunday, June 14, 2009
Saturday, June 6, 2009
Apparently, most of the U.C. solutions in the market now are half-baked, and is geered towards telecommunications and I.M. only. Given that, I have yet to see a solution which integrates I.M. communication with an email communication, other than the S.S.O, which actually just gives us presence awareness and nothing else. Some vendors are even guilty of calling their produce U.C. when in-fact, it only offers chat and Telephony and given that, there's not even a single integration between the two functionality. Some are guilty of providing everything that a communication platform can offer yet there's no single integration between them.
Anyway, here's the video of what Google Wave can offer and tell me if this is not truly a unified communications model. I, for one, particularly wanted to see how this will integrate with audio and video.
Configuring a new folder as a common shared library to deploy your shared libraries instead of using PortalServer/Shared or PortalServer/config
Article from : Websphere Portal Wiki by yours truly.
If you are a developer on a company who has a strong development process in-place, you are normally asked to deploy the shared jar files on the PortalServer/shared or PortalServer/config directory. You may have wondered, if you can actually deploy your jar files and property files in a separate folder(s) instead of those above given directory. The answer is YES. Though, this is not documented anywhere I believe.
While on the course of the portal migration project, I encountered all custom portlets to have 3 shared libraries configured on each of them. The funny thing is that all of the shared libraries configured are the same for all of the portlets. This is actually a headache for me during migration as there are more than 100 portlets deployed and I don't expect myself to configure them one by one. So, what I did was to configure 3 new shared libraries BUT configure my Portal Server to see this Shared Libraries, rather than deploying my libraries under PortalServer/shared or PortalServer/Config. I didn't deploy the shared library on the PortalServer/shared or PortalServer/config folder as what IBM manuals normally says.
But instead, this JAR files are stored on a different directory, but whenever Portal loads, it knows that this jar files are to be loaded as shared library that is to be shared by all portlets. How ? Follow the below instructions. Note that this instruction is for WAS 6.1, but the same can be found on 5.1 and 6.0 though in a different way of doing it.
- Logon to the Websphere Application Server console.
- Go to Environment -> Shared Libraries
- Create your own Shared Library. Add the classpath pointing to your JAR files.
- Apply and save this configuration.
- Now, this is the fun part. Go to Servers -> Application Servers -> Websphere_Portal -> Java and Process Management -> ClassLoader.
- Class loader may vary but it should only contain one link. Click on that class loader.
- Click on the Shared Library References
- You will notice all the shared libraries that are used by Websphere Portal. Click on Add.
- Add your shared library.
- Save and restart Websphere Portal.
Friday, May 29, 2009
- You are still logged in to your online banking. Technically, your session is still alive.
- Checking the HTTP Referrer.
- Having a hidden validation key for every form submission
- Generate a random key and store the key into the session.
- Add this Random key as a hidden value field on the Response part of the application as part of the Form Submission.
- When Form is submitted, I validate this key.
- If Key is valid, pass it to the applicaiton.
- If key is invalid, fail the submission.
- Read the contents of the Form Data. Based on the field names, generate a checksum with an algorithm known only to you.
- Add this key to the form data.
- When form is submitted, check the field names and calculate the checksum.
- If Key is valid, pass it to the applicaiton.
- If key is invalid, fail the submission.
- User Request for Page
- Browser goes to the server and request for the page
- Application sends the page to the browser.
- However, Response Filter intercepts the response.
- Response Filter generates an authentication key. If you used a checksum based solution, this key is a calculated checksum.
- Response Filter saves the key to the J2EE Session, if you follow the session-based solution, otherwise this key is actually a checksum key.
- Response Filter appends the key to the HTML Form.
- Response Filter sends the request to the Browser.
- Browser renders page (with the key embedded).
- User interacts and submits the page
- Information is send to the application
- However, Request filter intercepts the request.
- Request Filter checks for the authentication key
- Request Filter Authenticates Key by comparing with the J2EE Session, if you're using a Session-based solution, otherwise Filter will validate the checksum..
- If key is invalid, Request Filter generates a response and shows error page. Request ends.
- If valid, Request Filter sends the information to the Application.
- If Key is in the hidden field, hidden field is removed. This is optional and can be done in-cases where Application checks for any extra fields and invalidates the request if any extra-field is found.
- Application processes the information.
- Run the following command : ./xmlaccess.sh –in ExportRelease.xml –user [username] -password [password]
-url http://[server] :9081/wps/config -out /tmp/release20090429/config.xml.
You can get the ExportRelease.xml HERE
- Backup the following files : PortalServer/installableApps, PortalServer/installedApps, AppServer/installedApps/[server]
/wps.ear ,PortalServer/shared, PortalServer/deployed.
- Once done, the Operations have passed to me the config.xml file. And I'm good to go to import the settings and files to the new 126.96.36.199 server.
- The Portal 5.1 must be setup as an empty portal. Portal Server 5.1 does not contain an "action-empty-portal" reference on WPConfig.sh (bat). So you have to install it as empty. However, there's a workaround on this as shown later.
- You need to install all the fixes on the following link (otherwise you will hit issues such as Import takes very slow, etc.). Download the files HERE. You need an IBM Login to download the files. Don't install as yet.
- For my case, since Portal 5.1 was not an empty portal when it was handed over to me, (as I forgot to let them know that I need an empty portal) I have to use Portal 6.0 scripts and modify them. These scripts are compatible. Let me explain.
action-empty-portal actually runs 3 XML Scripts via xmlaccess which are :
When you run wpsconfig.sh, it actually looks at the file called : wps_cfg.xml. This file maps the commands to the xml actions that needs to be run. For example, when you call action-empty-portal, the above scripts are run.
For my case, I copied these scripts from Portal 6.0 to my Portal 5.1 and modified CleanPortal (as shown HERE) in order for it to work with Portal 5.1. I don't need to use AddBasePortalResources.xml as I don't need to add the language resources. However, I need the SchedulerCleanupTask.xml (as shown HERE)
Now, I have to run these jobs individually. I ran it at this sequence :
- First, I ran this command : ./xmlaccess.sh -in
/config/work/CleanPortal.xml -user [username] -pwd [password] -out /tmp/xmlcleanportal.xml -url http://[server] :9081/wps/config
- And then, I ran this command : ./xmlaccess.sh -in
/config/work/SchedulerCleanupTask.xml -user [username] -pwd [password] -out /tmp/xmlcleanportal.xml -url http://[server] :9081/wps/config
- Before importing, I want to make sure that my credential-segment is added. So you need to run this command : WPSconfig.sh action-create-deployment-credentials
- After you run this commands, check that your portal is empty by restarting it and browsing it. You shoudl see an error something like VP Failed. This is normal for Portal 5.1.
- My portal 5.1 and the Production Portal 5.1 are of the same version so I copied everything fron the backedup installableApps and Deployed to the new Portal Server's installabeApps. After that, I copied the latest WAR files of our custom applications. If the Portal version is different, I would have just copied only the new WAR files from our custom applications
- Once done, Install the Fixes as specified in number 2.
- Copy your custom shared JAR files into the new PortalServer/shared folder.
- Copy your custom theme and skins to the new PortalServer
- Install any custom configurations and files that you may have. On my side, I configured my JDBC to the databases used by the applications. You can do whatever custom configuration and installation here (only on the WAS Side).
- Once done, I edited my config.xml (XML file backedup from the production server) to point to the correct WAR files. For information, check out THIS LINK.
- I imported my configuration by running the following : ./xmlaccess.sh -in /xmlaccessfiles/config.xml -out /tmp/import.xml -user [username]
-pwd [password]If you find that the import is running too slow (like one line per one minute), then you didn't install the fixes. Go back and check #2. -url http://[server] :9081/wps/config.
Tuesday, April 14, 2009
I'm helping a client setup a SSL for their Documentum Application. Whenever I Configure the SSL Key Store, I hit this error on the http_plugin.log file :
Failed in r_gsk_secure_soc_init: GSK_ERROR_BAD_CERT(gsk rc = 414) with
Monday, April 13, 2009
Friday, January 9, 2009
So I encountered this scenario where the SSL was replaced but the site is still serving the old SSL on a site hosted on IIS 8. You keep che...
Most J2EE Applications and for that matter, any applications uses Property File to provide the properties and attributes to it's app. Wh...