Configurar WAS para detenerlo con stopServer.sh sin pasar parámetros de autenticación

Que un WAS hay que detenerlo por stopServer.sh y necesitamos tener el usuario y password administrativo guardado por ahí en un archivo en hash de modo seguro. Pues bien, son solo 3 pasos:

1. Editar soap.client.props
2. Introducir los valores respectivos de  com.ibm.SOAP.securityEnabled=true, com.ibm.SOAP.loginUserid=<user_ID>, com.ibm.SOAP.loginPassword=<password>
3. Ejecutar PropFilePasswordEncoder.sh ./properties/soap.client.props com.ibm.SOAP.loginPassword

Listo, ahora con un un simple ./stopServer.sh <servidor> simplemente se apagará el WAS sin pedir usuario administrativo.


Configuring the stopserver.sh script to connect without passing parameters

Enabling user ID and password input from soap.client.props for SOAP connector types

Resolviendo pedos de espacio en /var

Resolver pedos de espacio en el filesystem /var es un problema frecuente,  encontré un recurso con información breve y bastante útil que si bien está enfocado a un sistema AIX, puede aplicarse a otros sistemas tipo unix.

Resolving overflows in the /var file system

WAS nodeagents que no inician

En otra historia más de problemas con WAS, está el nodeagent que no quiere arrancar, y simplemente no arroja nada raro en los logs. Lo único que encontré fué lo siguiente:

Resolving the problem

To resolve this problem:

1) Stop all remaining Application Server processes if any
2) Change the file permission's on the entire WebSphere install back to the non-root user
3) Run <WAS_HOME>/profiles/<profile>/bin/osgiCfgInit.sh
4) Start the server

Habilitar SSL entre IHS y WAS

• Hay que ir al WAS a SSL certificate and key management > Manage endpoint security configurations > nodeName > Key stores and certificates > NodeDefaultKeyStore > Personal certificates
• Seleccionar el certificado y extraerlo en algún path del server
• Abrir el ikeyman del IHS dentro de $IHS/bin/ikeyman
• Crear un nuevo keystore
• Importar el certificado de WAS al keystore
• Modificar la configuración de IHS
• KeyFile /usr/PATH/TO/ssl/key.kdb
  
  SSLEnable
  SSLDisable
• Reiniciar el IHS
• Probar aplicación

db2 list all tables

Para listar todas las tablas de un DB2

$ db2 list tables for all

Fuente : dbforums

Usuario de solo lectura en DB2

Bueno, lo que había hecho hace un par de días, de revocarle todos los permisos a las tablas al usuario no fué suficiente. El usuario 'readonly' seguía actualizando registros. Cual era entonces el problema?

db2 => get authorizations

 Administrative Authorizations for Current User

 Direct SYSADM authority                    = NO
 Direct SYSCTRL authority                   = NO
 Direct SYSMAINT authority                  = NO
 Direct DBADM authority                     = NO
 Direct CREATETAB authority                 = NO
 Direct BINDADD authority                   = NO
 Direct CONNECT authority                   = YES
 Direct CREATE_NOT_FENC authority           = NO
 Direct IMPLICIT_SCHEMA authority           = NO
 Direct LOAD authority                      = NO
 Direct QUIESCE_CONNECT authority           = NO
 Direct CREATE_EXTERNAL_ROUTINE authority   = NO
 Direct SYSMON authority                    = NO

 Indirect SYSADM authority                  = YES
 Indirect SYSCTRL authority                 = NO
 Indirect SYSMAINT authority                = NO
 Indirect DBADM authority                   = NO
 Indirect CREATETAB authority               = YES
 Indirect BINDADD authority                 = YES
 Indirect CONNECT authority                 = YES
 Indirect CREATE_NOT_FENC authority         = NO
 Indirect IMPLICIT_SCHEMA authority         = YES
 Indirect LOAD authority                    = NO
 Indirect QUIESCE_CONNECT authority         = NO
 Indirect CREATE_EXTERNAL_ROUTINE authority = NO
 Indirect SYSMON authority                  = NO

db2 =>

Básicamente aunque el usuario no tenía el direct SYSADM authority, si lo tenía indirectamente. Y de donde obtiene esa autoridad indirectamente? Me costó bastantes googleadas y chapuzones en la documentación, pero finalmente llegué al documento que explica que db2 mantiene la seguridad en base al sistema operativo, en base a grupos de usuarios. Este usuario pertenecía al mismo grupo que los administradores, así que tenía que sacarlo de ahí y generar un nuevo grupo para administradores y para usuarios de solo lecura, o de otro modo seguiría obteniendo un SYSADM indirecto.

$ db2 get dbm cfg | grep -i sys
 Federated Database System Support           (FEDERATED) = NO
 SYSADM group name                        (SYSADM_GROUP) = STAFF
 SYSCTRL group name                      (SYSCTRL_GROUP) =
 SYSMAINT group name                    (SYSMAINT_GROUP) =
 SYSMON group name                        (SYSMON_GROUP) =
 Priority of agents                           (AGENTPRI) = SYSTEM

El grupo del sistema que contiene a los administradores se llamaba STAFF y había que cambiarlo a DB2IADM. A su vez, había que agregar un grupo al sistema llamado DB2IADM y otro INSTUSER.
En DB2IADM ponemos al propietario de la instancia DB2INST1 y ROOT, mientras que en el grupo INSTUSER dejamos al usuario READONLY.

Después solo es cosa de cambiar el parámetro del sistema:

db2 => UPDATE DBM CFG USING SYSADM_GROUP DB2IADM
DB20000I  The UPDATE DATABASE MANAGER CONFIGURATION command completed
successfully.
db2 =>

Finalmente reiniciar DB2:

$ db2stop [force] && db2start

Revisar que el grupo ha cambiado:

$ db2 get dbm cfg | grep -i sys
 Federated Database System Support           (FEDERATED) = NO
 SYSADM group name                        (SYSADM_GROUP) = DB2IADM
 SYSCTRL group name                      (SYSCTRL_GROUP) =
 SYSMAINT group name                    (SYSMAINT_GROUP) =
 SYSMON group name                        (SYSMON_GROUP) =
 Priority of agents                           (AGENTPRI) = SYSTEM

Revisar que el usuario ya no cuenta con el indirect SYSADM authority:

$ db2 get authorizations

 Administrative Authorizations for Current User

 Direct SYSADM authority                    = NO
 Direct SYSCTRL authority                   = NO
 Direct SYSMAINT authority                  = NO
 Direct DBADM authority                     = NO
 Direct CREATETAB authority                 = NO
 Direct BINDADD authority                   = NO
 Direct CONNECT authority                   = YES
 Direct CREATE_NOT_FENC authority           = NO
 Direct IMPLICIT_SCHEMA authority           = NO
 Direct LOAD authority                      = NO
 Direct QUIESCE_CONNECT authority           = NO
 Direct CREATE_EXTERNAL_ROUTINE authority   = NO
 Direct SYSMON authority                    = NO

 Indirect SYSADM authority                  = NO
 Indirect SYSCTRL authority                 = NO
 Indirect SYSMAINT authority                = NO
 Indirect DBADM authority                   = NO
 Indirect CREATETAB authority               = YES
 Indirect BINDADD authority                 = YES
 Indirect CONNECT authority                 = YES
 Indirect CREATE_NOT_FENC authority         = NO
 Indirect IMPLICIT_SCHEMA authority         = YES
 Indirect LOAD authority                    = NO
 Indirect QUIESCE_CONNECT authority         = NO
 Indirect CREATE_EXTERNAL_ROUTINE authority = NO
 Indirect SYSMON authority                  = NO

Finalmente intentar actualizar algún registro y corroborar que el usuario ya no tiene capacidad de modificar los registros:


db2 => update DB.table set loginid ='foo@bar.com' where userid = 'DBADMIN'
DB21034E  The command was processed as an SQL statement because it was not a
valid Command Line Processor command.  During SQL processing it returned:
SQL0551N  "READONLY" does not have the privilege to perform operation "UPDATE"
on object "DB.table".  SQLSTATE=42501

Talachas por aquí, talachas por allá

Se me solicitó crear un usuario que solo tuviera permiso de hacer 'SELECT' en un schema de DB2.

Estuve ahí leyendo documentos, y así tal cual, no se le puede otorgar permiso de 'SELECT' a un schema; éste solo aplica a las tablas. Así que consulté a la gurú de DB2 y me comentó que tenía que revisar que tablas pertenecían al schema y de ahí hacer el cambio.

Lo primero era consultar las tablas en el catálogo que pertenecían al schema:

$ db2 "select TABSCHEMA, TABNAME from SYSCAT.TABLES where TABSCHEMA = 'FOOSCHEMA' > /tmp/max.out

Dado que la cantidad de tablas por modificar eran más de 150, decidí hacer un script balín para modificar los permisos del usuario en todas esas tablas. Primero había que dejar un archivo con los puros nombres de las tablas separados de renglón en renglón; limpié el archivo de salida schema.out para dejar la pura columna que tenía el nombre de la tabla y lo envié al archivo max.out.col

$ cut -c130-180 max.out > max.out.col

Dado que el cut dejó muchos espacios en blanco sobrantes en cada renglón, los limpié desde vi:

:%s/ //g

Finalmente hice el script que otorgaría todos los permisos, después los revocaría todos y finalmente otorgaría únicamente el permiso de select:


Finalmente, en menos de 2 minutos se cambiaron esos permisos en menos de 2 minutos.
Si bien mi método no es el mas adecuado y podría mejorarse y reducirse, me resolvió el problema en ese momento y de modo sencillo. Y finalmente, leer documentación y preguntar es parte central de solución de problemas que uno no tiene idea como resolver.

Restaurar DBs de DB2

La parte que faltaba después de hacer respaldos de DB2 era restaurar.

$ db2 restore db db_name from /some/path taken at '20101109164220' on /foo/path WITHOUT ROLLING FORWARD

Atención en especial con el "without rolling forward" por que al omitirlo se pueden quedar los tablespaces en estado pending.

rPerf a detalle

Si. Bueno; salió por ahí en el requerimiento de un cliente que le calculáramos el rPerf de unos sistemas para hacer unos cálculos de rendimiento (performance).

QUE?!

Me di a la tarea de leer un poco sobre rPerf, nunca queda de más investigar algo nuevo o desconocido.

rPerf o Relative Performance es el rendimiento estimado en referencia a otros sistemas UNIX de IBM; aplicable a pSeries. Los sistemas pSeries 640 son la base de referencia y tienen un valor de 1.0.
IBM tiene en su documentación los valores de rPerf para sus sistemas, pero de vez en cuando se requiere obtener el valor de rPerf para un LPAR para lo cual se puede echar mano de los siguientes scripts.

Fuentes:
Virtualization
The relative performance metric for Power Systems servers
rperf - rPerf Number Finder
rPerf script - to work out an rPerf rating for your LPAR

rPerf

Poner en la agenda de aprendizaje:

(Relative PERFormance) An IBM benchmark for its AIX-based Power Systems. It replaced the earlier ROLTP benchmark and uses the pSeries 640 computer as a baseline of 1.0. See Power Systems.

fuente: PCMag

Hardware Management Console

Hardware Management Console o HMC es una tecnología para administrar particiones lógicas en iSeries o pSeries.

Fuente 1, 2