Problema con el cambio de WASADMIN y PORTALADMIN en Portal 7.0.0.2

Hoy me encontré con este problema mientras intentaba cambiar los usuarios de administración del WAS y del Portal (7002):

[wplc-validate-user-exists]   Instance attributes (Set 1 of 1):

[wplc-validate-user-exists]     ignoreDuplicateIDs= *** NOT_SPECIFIED ***

[wplc-validate-user-exists]     attribute=[ *** NONE_SPECIFIED *** ]

[wplc-validate-user-exists]     customproperty=[ *** NONE_SPECIFIED *** ]

[wplc-validate-user-exists]     cn="CN=wasadmin,OU=usuarios,OU=portal,DC=pe,DC=ibm,DC=com"

[wplc-validate-user-exists]     trimSpaces= *** NOT_SPECIFIED ***

[wplc-validate-user-exists] com.ibm.websphere.management.cmdframework.InvalidParameterNameException: ADMF0004E: Invalid parameter name CN for command searchUsers.

[wplc-validate-user-exists]     at com.ibm.websphere.management.cmdframework.provider.AbstractAdminCommand.getParameterMetadata(AbstractAdminCommand.java:1096)

[wplc-validate-user-exists]     at com.ibm.websphere.management.cmdframework.provider.AbstractAdminCommand.isParamReadonly(AbstractAdminCommand.java:1162)

[wplc-validate-user-exists]     at com.ibm.websphere.management.cmdframework.provider

Gracias al post de Dave Hay pude encontrar la solución (bueno, un workaround), agregarle "-Dskip.ldap.validation=true" al final de la sentencia.

Sentencia para el cambio de usuario administrador del WAS:

./ConfigEngine.sh wp-change-was-admin-user -DWasPassword=wpadmin -DnewAdminId=CN=wasadmin,OU=usuarios,OU=portal,DC=pe,DC=ibm,DC=com -DnewAdminPw=wasadmin -Dskip.ldap.validation=true

Sentencia para el cambio de usuario administrador del Portal:

./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=wasadmin -DnewAdminId=CN=wpsadmin,OU=usuarios,OU=portal,DC=pe,DC=ibm,DC=com -DnewAdminPw=wpsadmin -DnewAdminGroupId=CN=wpadmins,OU=grupos,OU=portal,DC=pe,DC=ibm,DC=com -Dskip.ldap.validation=true

Instalando el nuevo tema modular 7.0.0.2

El más reciente fixpack (7.0.0.2) trae consigo un nuevo tema, en el que se introduce un nuevo concepto de modularización.

IBM® WebSphere Portal 7.0.0.2 includes a new theme. The new theme is a modularized theme that you can enable and disable features as needed. The ability to enable and disable the theme provides better performance. You can disable components that are not needed. This ability also eases development of a theme.

A continuación, les diré que hacer para instalarlo.

1. Primero debemos actualizar nuestro portal 7 con el fixpack 2 (recuerden que para su actualización también requieren actualizar el WAS (en mi caso lo tengo actualizado con el fixpack 21).
2. Por defecto, el nuevo tema no viene instalado, así que debemos desplegarlo mediante la siguiente sentencia: 

./ConfigEngine.sh deploy-7002-theme -DPortalAdminPwd=password -DWasPassword=password

Tras el despliegue, que tarda unos minutos, podremos ver que aparece listado el nuevo tema, con sus respectivos skins.





3. Creé una nueva página y le apliqué el nuevo tema, así es como luce:

Administering IBM WebSphere Portal 7.0: A comprehensive workshop

Administering IBM WebSphere Portal 7.0: A comprehensive workshop: This plopped into my inbox this morning - kudos to Thomas Hurek and Falk Posch for creating this useful document: -

The goal of this white paper is to explain the various administration and configuration tools offered by IBM WebSphere Portal 7.0. Learn about which tool to use for which task and about the new capabilities of WebSphere Portal 7.0, and understand differences from previous versions of WebSphere Portal. We take you through exercises for each tool so you can learn hands-on how to use them.

ToC

• Introduction

• What is WebSphere Portal?

• WebSphere Portal installation

• WebSphere Portal file system structure

• Command line tools

• Administration user interface: Admin portlets

• WebSphere Application Server Admin user interface

• Conclusion

• Resources

• About the authors

IBM Content Template Catalog V3.0 (CTC) and WebSphere Portal 7.0.02

IBM Content Template Catalog V3.0 (CTC) and WebSphere Portal 7.0.02: This IBM Technote plopped into my In-Box earlier today, and I immediately shared it via Sametime with a number of my colleagues, most of whom are working with the IBM Content Template Catalog (CTC) right now.

IBM Content Template Catalog V3.0 (CTC) is broken after upgrade to WP/WCM V7.0.0.1 CF009 (or later) or 7.0.0.2 fix pack

Abstract

The IBM Content Template Catalog V3.0 (CTC3) can be installed on IBM Web Content Manager (WCM) V7.0.0.1 or 7.0.0.2. Installing the Combined Cumulative Fix 009 or 010, or upgrading to fix pack level 7.0.0.2 renders CTC3 unusable.

Content

A fix will be made available in the near future and this page will be updated when more information is available.

The IBM Content Template Catalog V3.0 (CTC3) is documented here: -

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/IBM_Content_Templates_Catalog_V3.0

One of the files necessary for its successful operation is overwritten when installing either Combined CF009, CF010, or fix pack 7.0.0.2. The .jar file, "wp.wcm.templating.jar", is installed into the WCM shared apps directory during a CTC3 install.

To correct the issue, copy the original .jar file from CTC3 back into the shared apps directory (replacing the file present) and restart the server.

The .jar file is located in "/wp.ctc/components/wp.ctc/enablment/" in the CTC PAA. The non-CTC3 file will be 31KB after installing the CF or fix pack but the CTC3 version is 80KB.

After the restart, the templating functions should be working again.

IBM Content Template Catalog V3.0 doc
Download CTC3
CTC3 Forum Thread

IBM WebSphere Portal Mobile Experience V7.0 - Your Portal Needs a Mobile Theme NOW

Kudos to Jon Lidaka for getting this published: -

Mobile is exploding and no longer considered an add-on. It is quickly becoming a primary channel for customers and employees to be productive.  The Portal Mobile Experience provides you code to quickly extend WebSphere Portal sites to mobile devices that support Webkit (Apple, Android, Blackberry phones).  This new theme shows how to control the look and feel, page navigation and content navigation on a smartphone and provides examples of rich mobile web interaction patterns such as swipe, carousel, accordion, and swap using CSS3 and HTML5.

Available here on Greenhouse. Get downloading NOW

Two rather useful tools for IBM WebSphere Portal and IBM Web Content Manager

Both are available in the Greenhouse; definitely worth a download ….

IBM Portal Log Analyzer

The IBM Portal Log Analyzer is a tool designed to help users of IBM's WebSphere Portal product troubleshoot issues with ConfigEngine and JVM startup failures.

Loading a ConfigTrace.log into the Log Analyzer tool allows you to:

• View an interactive list of ConfigEngine scripts that have been executed in your environment

• Quickly identify failed ConfigEngine scripts

• Find the right errors to troubleshoot

• View the properties used at the time of a specific ConfigEngine script

IBM Support Tools portlet for Lotus WCM 

The IBM Support Tools portlet for Lotus WCM provides an assortment of tools that are useful in troubleshooting content related issues.

This portlet includes tools to view the JCR repository for WCM content, run an xpath query and view results, and directly execute various support jsps. These tools are commonly provided by support on a case to case basis to gather information specific to customer environment and content. With this portlet installed on the WCM system, it will help expedite the troubleshooting process.
greenhouse

The portlet is available for v6.0.1.X , v6.1.X and v7.0 of WebSphere Portal and can only be used on Portals that have WCM installed on the them.

Creación de un portal virtual a través del Configuration Task (aka ConfigEngine)

Para crear un portal virtual haciendo uso del ConfigEngine, necesitamos editar el archivo /ConfigEngine/config/helpers/virtual_portal.properties y debemos completar los siguientes parámetros (resaltados):

# VirtualPortalTitle: Title of the Virtual Portal

VirtualPortalTitle=PortalPrueba1

# VirtualPortalRealm: Realm of the Virtual Portal

VirtualPortalRealm=defaultWIMFileBasedRealm

# VirtualPortalHost: Hostname of the Virtual Portal

VirtualPortalHostName=

# VirtualPortalContext: Context of the Virtual Portal

VirtualPortalContext=prueba1

# VirtualPortalNlsFile: File which contains language specific information for the Virtual Portal

VirtualPortalNlsFile=

# VirtualPortalObjectId: ObjectId of the Virtual Portal

# The ObjectId is needed to modify, delete Virtual Portals and

# can be obtained by running task list-all-virtual-portals

# Note: Do not delete the default Virtual Portal (ObjectId ends with _0)

VirtualPortalObjectId=

Para este ejemplo voy a crear un portal con el contexto "prueba1". 

Una vez que hemos ingresado los datos correspondientes ejecutamos la siguiente sentencia:

./ConfigEngine.sh -DparentProperties=/ConfigEngine/config/helpers/virtual_portal.properties create-virtual-portal

++++ Actualización ++++
En algunas situaciones podría aparecerles el siguiente mensaje de error:


  [wsadmin] WASX7209I: Connected to process "WebSphere_Portal" on node node01 using SOAP connector;  The type of process is: UnManagedProcess
  [wsadmin] WASX7303I: The following options are passed to the scripting environment and are available as arguments that are stored in the argv variable: "[/opt/IBM/WebSphere/wp_profile/ConfigEngine]"
  [wsadmin] false
  [wsadmin] VirtualPortalTitle:    PortalPrueba1
  [wsadmin] VirtualPortalRealm:    defaultWIMFileBasedRealm
  [wsadmin] VirtualPortalContext:  prueba1
  [wsadmin] VirtualPortalHostName:
  [wsadmin] VirtualPortalNlsFile:
  [wsadmin] logged in as "uid=wpsadminaux,o=defaultWIMFileBasedRealm"
  [wsadmin] [06/17/11 17:09:21.148 PET] EJPXD0001I
  [wsadmin] [06/17/11 17:09:21.169 PET] EJPCA3001I: "VirtualPortalRealm in wkplc.properties with defaultWIMFileBasedRealm" already there. No action taken
  [wsadmin] [06/17/11 17:09:24.581 PET] EJPXD0002E
  [wsadmin] [06/17/11 17:09:24.583 PET] EJPCA3002E: ERROR: "VirtualPortal with context prueba1" already there
  [wsadmin] It appears that a Virtual Portal already exist with context prueba1.
  [wsadmin] java.rmi.RemoteException: com.ibm.wps.command.CreateVPFailedBecauseDuplicateKeyException: EJPEB0806E: Creating a virutal portal failed because a unique key constraint in the data backend was violated. Likely a virutal portal with the same context was deleted but still exists in the database. It is recommended to run the cleanup task for deleting resources by running the XML script Task.xml using the XML configuration interface.


Cuando suceda esto, debemos correr la siguiente sentencia desde la ruta "/bin":

./xmlaccess.sh -in ../doc/xml-samples/Task.xml -out result-Task.xml -url http://:10039/wps/config -user -password

Eliminando un Portal Virtual con el Configuration Task (aka ConfigEngine)

Para eliminar un portal virtual, lo primero que debemos hacer es obtener el listado de portales virtuales existentes. Para realizar esto ejecutamos la siguiente sentencia:

./ConfigEngine.sh list-all-virtual-portals

Al ejecutarla, se mostrará un listado como aparece en la siguiente figura.

Finalmente, con el valor que figura en el atributo "Object ID" del portal que deseamos eliminar ejecutamos la siguiente sentencia:

./ConfigEngine.sh delete-virtual-portal -DVirtualPortalObjectId=Z18_DNG2OKG10GV880I1P7FOOQ3GU6


No está de más señalar que "Z18_DNG2OKG10GV880I1P7FOOQ3GU6" es el Object ID antes mencionado. 

WP6 to WP7: Migración de Temas

En estos días vengo trabajando en un proyecto de migración de la versión 6.0 a la versión 7.0 de IBM WebSphere Portal.

Cuando llegué a la parte de migración de temas seguí las instrucciones que figuran en el siguiente enlace:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Migrating_themes_wp7

Sin embargo, para que esto funciones tuve primero que aplicar las instrucciones de este enlace:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Adding_the_Page_Builder_theme_exp7

¿Por qué? Porque por defecto el WP7 trae consigo el PageBuilder v2 y para que podamos migrar los temas de la versión anterior es necesario emplear el PageBuilder v1.

WebSphere Portal - Customizar mensaje "This portlet is unavailable"

Curioseando encontré que el jar "wp.ui.jar" contiene una serie de archivos de propiedades

que contienen casi todos los mensajes que encuentras en el portal.

Para encontrarlo debemos ir a la siguiente ruta:

/ui/wp.ui/shared/app/wp.ui.jar

WP615 - Configurar páginas de error (Customize error pages)

Esta fue la tarea de esta semana: ¿cómo personalizamos las páginas para errores 404?

Para tener una configuración decente debemos tomar en cuenta que ésta se debe realizar en tres ámbitos diferentes: la primera es a nivel de webserver, la segunda a nivel del contexto "wps" y la tercera a nivel del contexto "portal", cómo se muestra en la figura.

Para el webserver debemos contar con una carpeta en dicho servidor con las páginas e imágenes que se emplearán para mostrar el mensaje de error. Luego en el archivo httpd.conf, ubicamos la sección que configura estos mensajes de error y establecerlo de manera similar al ejemplo que pongo a continuación:

Luego, configuramos el portal, para ello seguimos las siguientes instrucciones
- Bajar el portal en cada nodo.
- Subir en cada nodo el servidor "server1"
./startServer.sh server1
- Ubicarse en el Deployment Manager y allí crear una carpeta temporal
mkdir /was/wps_expanded
- Acceder al directorio dmgr_profile_root/bin
- Exportar el ear wps
./wsadmin.sh -user wpsadmin -password -c '$AdminApp export wps /was/wps.ear'
- Expandir el ear
./EARExpander.sh -ear /was/wps.ear -operationDir /was/wps_expanded -operation expand
- Crear una carpeta llamada "error" dentro de la carpeta "wps.war"
mkdir /was/wps_expanded/wps.ear/wps.war/error/
- Copiar los archivos de páginas de error en dicha carpeta.

NOTA: Las urls de los enlaces en la página deben seguir el siguiente formato:
"/wps/portal/rimac/inicio"
y las imágenes "imagenes/logo_rimac_seg.gif"

- Asignar permisos 777 a la carpeta "error"
chmod 777 R /was/wps_expanded/wps.war/error/
- Agregar dentro del web.xml entre los tags y , este archivo se encuentra en la ruta /was/wps_expanded/wps.war/WEB-INF

NOTA: Las urls de los enlaces en la página deben seguir el siguiente formato:
"portal/rimac/inicio"
y las imágenes "error/imagenes/logo_rimac_seg.gif"

- Agregar dentro del web.xml antes de los demás filtros.

Se aplica los "filters" a los siguientes contextos:
/portal/*
/myportal/*
/contenthandler/*

- Eliminar el archivo ear previamente exportado a fin de que podamos generarlo nuevamente.
- Empaquetar el ear
./EARExpander.sh -ear /was/wps.ear -operationDir /was/wps_expanded -operation collapse
- Importar el ear
./wsadmin.sh -user wpsadmin -password  -c '$AdminApp install  /was/wps.ear {-update -appname wps}'
- Bajar "server1"
- Reiniciar cada nodo de "WebSphere_Portal"
- Copiar el jar "portal-apiconz-filter.jar" del filtro en la ruta PortalServer/shared/app en ambos nodos.

Para este jar seguí las instrucciones que encontré en: Web Content Management: Custom error pages. Esta guía también la pude aplicar al portal

WP615 - Error tras la instalación JVMJ9VM011W

Tras la instalación del WP615 en CentOS  quise ejecutar el siguiente comando:

[root@localhost bin]# ./serverStatus.sh WebSphere_Portal

... y recibí el siguiente error:

JVMJ9VM011W Unable to load j9jit23: /was/IBM/WebSphere/AppServer/java/jre/bin/libj9jit23.so: cannot restore segment prot after reloc: Permission denied 
JVMJ9VM011W Unable to load jclscar_23: /was/IBM/WebSphere/AppServer/java/jre/bin/libjclscar_23.so: cannot restore segment prot after reloc: Permission denied 

Could not create the Java virtual machine.

Para arreglarlo ejecuté el siguiente comando con el usuario root del servidor:

[root@localhost bin]# setenforce 0 

EJPSG0015E: Data Backend Problem

Hace poco realicé la instalación de un TDS 6.2 y lo integré a mi portal. Quise probar la creación de usuarios desde el portal, sin embargo he recibido el siguiente mensaje:

EJPSG0015E: Data Backend Problem com.ibm.websphere.wim.exception.WIMSystemException: CWWIM4520E The 'javax.naming.NoPermissionException: [LDAP: error code 50 - Insufficient Access Rights]; remaining name 'uid=apiconz,cn=temporal,o=rimac'; resolved object com.sun.jndi.ldap.LdapCtx@66326632' naming exception occurred during processing.

com.ibm.wps.util.DataBackendException: EJPSG0015E: Data Backend Problem com.ibm.websphere.wim.exception.WIMSystemException: CWWIM4520E The 'javax.naming.NoPermissionException: [LDAP: error code 50 - Insufficient Access Rights]; remaining name 'uid=apiconz,cn=temporal,o=rimac'; resolved object com.sun.jndi.ldap.LdapCtx@66326632' naming exception occurred during processing.

EJPSG0015E: Data Backend Problem com.ibm.websphere.wim.exception.WIMSystemException: CWWIM4520E The 'javax.naming.NoPermissionException: [LDAP: error code 50 - Insufficient Access Rights]; remaining name 'uid=apiconz,cn=temporal,o=rimac'; resolved object com.sun.jndi.ldap.LdapCtx@66326632' naming exception occurred during processing.

CWWIM4520E The 'javax.naming.NoPermissionException: [LDAP: error code 50 - Insufficient Access Rights]; remaining name 'uid=apiconz,cn=temporal,o=rimac'; resolved object com.sun.jndi.ldap.LdapCtx@66326632' naming exception occurred during processing. Revisando un poco la configuración encontré que faltaban dos configuraciones: Por un lado debía indicarle al portal en qué rama del TDS debía guardar los usuarios que se iban creando, para esto modifiqué el archivo wimconfig.xml La configuración de este archivo apuntaba a la ruta del repositorio por defecto del portal (hasta este punto ya lo había eliminado):     o=defaultWIMFileBasedRealm" name="PersonAccount">       uid          o=defaultWIMFileBasedRealm" name="Group">       cn      Asi que lo que hice fue cambiar la ruta para que apunte a ramas existentes en mi TDS:     ou=personas,o=apiconz" name="PersonAccount">       uid          ou=grupos,o=apiconz" name="Group">       cn      Adicionalmente a esta configuración, requería darle al usuario con el que enlazamos al portal con el tds permisos para que pudiera escribir sobre dichas ramas. Para esto, entramos a Directory Management > Manage Entries seleccionamos la rama sobre la que queremos que el usuario pueda escribir y seleccionamos la opción Edit ACL... del menú desplegable que se encuentra en la parte superior de la grilla. En la pantalla que nos aparece a continuación seleccionamos la opción Filtered ACLs e ingresamos los campos que se nos presentan en el formulario. Luego vamos a la opción Owners y agregamos a nuestro usuario de enlace como propietario de la rama correspondiente.

SECJ0373E: Cannot create credential for the user due to failed validation of the LTPA token.

Problem / Problema:
We have 2 environments... a cluster of WPS and an standalone WCM. After of change the configuration of realm to federated ldap repository, we tried to rename the wcm realm name to the name of portal realm, but the WCM not started correctly; we can to navigate on Admin Console but when we're trying to open the wcm portal, the server just show a error indicating that some portal services can't be started.

Tenemos dos ambientes... un cluster de WebSphere Portal y un Web Content Manager. Después de cambiar la configuración del realm para federated, tratamos de renombrar el realm del WCM con el nombre del realm del portal (para que funcione el Single Sign On), pero el WCM no inicia correctamente; podemos navegar en la Consola de Administración del WAS pero cuando tratamos de ingresar al portal, solo nos muestra un error indicando que algunos servicios del portal no pudieron ser iniciados.

Trace:

SECJ0373E: Cannot create credential for the user due to failed validation of the LTPA token. The exception is com.ibm.websphere.security.CustomRegistryException: The realm in the token: apiconzldap.apiconz.info:389 does not match the current realm: PortalWcmRealmFederated

at com.ibm.ws.security.ltpa.LTPAServerObject.getRelativeName(LTPAServerObject.java:1473)

at com.ibm.ws.security.ltpa.LTPAServerObject.getSecurityName(LTPAServerObject.java:1421)

at com.ibm.ws.security.ltpa.LTPAServerObject.validate(LTPAServerObject.java:1259)

at com.ibm.ws.security.server.lm.ltpaLoginModule.login(ltpaLoginModule.java:599)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:618)

at javax.security.auth.login.LoginContext.invoke(LoginContext.java:795)

at javax.security.auth.login.LoginContext.access$000(LoginContext.java:209)

at javax.security.auth.login.LoginContext$4.run(LoginContext.java:709)

at java.security.AccessController.doPrivileged(AccessController.java:246)

at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:706)

at javax.security.auth.login.LoginContext.login(LoginContext.java:603)

at com.ibm.ws.security.auth.JaasLoginHelper.jaas_login(JaasLoginHelper.java:289)

at com.ibm.ws.security.auth.ContextManagerImpl.login(ContextManagerImpl.java:2874)

at com.ibm.ws.security.auth.ContextManagerImpl.login(ContextManagerImpl.java:2737)

at com.ibm.ws.security.web.WebAuthenticator.validate(WebAuthenticator.java:1640)

at com.ibm.ws.security.web.WebAuthenticator.validateCookie(WebAuthenticator.java:599)

at com.ibm.ws.security.web.WebAuthenticator.handleSSO(WebAuthenticator.java:520)

at com.ibm.ws.security.web.WebAuthenticator.handleCustomLogin(WebAuthenticator.java:743)

at com.ibm.ws.security.web.WebAuthenticator.authenticate(WebAuthenticator.java:1497)

at com.ibm.ws.security.web.WebAuthenticator.authenticate(WebAuthenticator.java:1373)

at com.ibm.ws.security.web.WebCollaborator.authorize(WebCollaborator.java:670)

at com.ibm.ws.security.web.EJSWebCollaborator.preInvoke(EJSWebCollaborator.java:318)

at com.ibm.ws.webcontainer.webapp.WebAppSecurityCollaborator.preInvoke(WebAppSecurityCollaborator.java:141)

at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:486)

at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:90)

at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:751)

at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1478)

at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:125)

at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458)

at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387)

at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:267)

at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)

at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)

at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)

at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)

at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205)

at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1497)

Diagnostic / Diagnostico:

We found that the old realm name is still in one of the Portal database tables. If we update the realm in the table the exception when the portal starts should be resolved.

Encontramos que el nombre antiguo del realm está aun en una de las tablas de la base de datos del Portal. Si actualizamos el real en la tabla la excepción cuando el porta se inicia debería ser resuelta.

Solution / Solución
1) Login into WCM database.

2) Backup data on RELEASE.VP_DESC table.

db2 connect to RELEASE
db2 "select * from RELEASE.VP_DESC" > RELEASE.VP_DESC.TXT

3) Make change of realm name on security option from WAS 

apiconzldap.apiconz.info:389 -> PortalWcmRealmFederated

4) Stop the portal.

./stopServer.sh WebSphere_Portal -username wpsbind -password password

5) Make update to table.

db2 "update RELEASE.VP_DESC set REALM='apiconzldap.apiconz.info:389' where RELEASE.VP_DESC.REALM='PortalWcmRealmFederated'";  

6) Start the portal.

1) Ingresar a base de datos del WCM.

2) Respaldar datos de la tabla RELEASE.VP_DESC

db2 connect to RELEASE
db2 "select * from RELEASE.VP_DESC" > RELEASE.VP_DESC.TXT

3) Realizar cambio de nombre de Realm en las opciones de Seguridad del WAS.

apiconzldap.apiconz.info:389 -> PortalWcmRealmFederated

4) Bajar el portal.

./stopServer.sh WebSphere_Portal -username wpsbind -password password

5) Realizar actualización de datos en la bd.

db2 "update RELEASE.VP_DESC set REALM='apiconzldap.apiconz.info:389' where RELEASE.VP_DESC.REALM='PortalWcmRealmFederated'";

6) Subir el portal

WebSphere Portal 6.1.5 : Actualizando a 6.1.5.1

Productos instalados:
IBM WebSphere Portal Server 6.1.5
IBM WebSphere Application Server 6.1.0.27

1) Me bajé el fixpack para el WAS FP0000029 para subir mi WAS a la versión 6.1.0.29 (requerido por el Portal), también, el UpdateInstaller 7.0.
2) Tras instalar el UpdateInstaller y dado que estaba trabajando en consola escribí lo siguiente en la linea de comandos:

$ ./update.sh -options "responsefiles/install-1.txt" -silent

3) Una vez actualizado el WAS, pasé a actualizar el portal mediante el PortalUpdater con el siguiente comando:

$ ./updatePortal.sh -install -installDir "dir_portal_root" -fixpack -fixpackDir "dir_fixpack" -fixpackID WP_PTF_6104

4) Una vez que la instalación culmina podemos verificar la versión mediante WPVersion.sh, podremos ver que nuestro portal cuenta ya con el FeaturePack 6.1.5.1

WPS y WCM - Exportar e Importar LTPA-Keys para Single Sign On (SSO)

En ocasiones es necesario implementar un ambiente SSO sobre diferentes celdas (Ej. Implementar SSO entre un cluster de WebSphere Portal Server y un nodo independiente de WebSphere Content Manager). Para efectuar esto es necesario contar con llaves LPTA iguales en ambos servidores.

Para efectuar esta operación es necesario que los hagamos a traves de la consola administrativa (para el cluster a través del Deployment Manager).

1. Para exportar las llaves LTPA desde una celda (cell) debemos ir a Security > Secure administration, applications, and infrastructure > Authentication mechanisms and expiration.

2. Llenar el formulario que se muestra a continuación:

y pulsamos en "Export keys". Las llaves LTPA se exportarán al directorio especificado. Debemos tomar en consideración que para importarlas luego necesitaremos conocer la contraseña con la que lo exportamos.

3. Copiamos el archivo exportado a la otra celda (tomar en cuenta que cada celda contiene ya un archivo "ltpa.jceks", NO DEBEMOS SOBREESCRIBIRLO.

4. Antes de proceder a importar el archivo. Debemos tomar nota del tamaño del archivo ltpa.jceks. El archivo está localizado en  /"websphere_root"/"dmgr"/config/cells/"cellname"/ltpa.jceks

5. Para importar el archivo con las llaves debemos ir a Security > Secure administration, applications, and infrastructure > Authentication mechanisms and expiration.

6. Llenamos el mismo formulario que muestro en la figura anterior y pulsamos "Import keys"

7. El tamaño del archivo ltpa.jceks deberá incrementarse.

8. Reiniciamos los servidores / nodos y listo!

WebSphere Portlet Factory - Carga y lectura de archivos en el browser

El amigo Andres ha publicado una presentación sobre "Cómo cargar PDF en un portlet haciendo uso del WebSphere Portlet Factory".

Tuneando WebSphere Portal 6.1 para desarrollo

Mientras instalaba el WebSphere Portal Server 6.1 en mi PC, encontré una tarea que se puede ejecutar inmediatamente después de la instalación y que permite mejorar el rendimiento del portal. Esta tarea no se debe ejecutar en un ambiente de producción, sino exclusivamente para desarrollo.

• Installation Options - Development Task
  

Websphere Blog

El amigo Aldo Fiorentini ha vuelto a las andadas con su blog. En esta ocasión, con motivo de su retorno nos deja 4 interesantes posts:

• AIX - Cúantos procesadores tengo ?
  
• Generación y Propag. Automatica de Plugin
  
• Hallando el sizing de la sesión en websphere
  
• Tras la verdad: getLinkedException