[bug detected] Cisco ISE 1.2: endpoint consume advanced license autlhough it shouldn't

Hi,

yes, you have read well, it is a bug affecting ISE version 1.2.

If you are running Cisco Identity Services Engine v1.2 (I think that it affects the whole release) and you have become crazy changing your profiling policies again and again and your Cisco ISE licensing panel still shows that you are consuming an advanced license although the documentation clearly says that it shouldn't, yes friend, your software is affected by a bug.

The bug is:

CSCun00162 (https://tools.cisco.com/bugsearch/bug/CSCun00162)

and, as this page say:

Symptom:
Endpoints are still consuming advanced licenses even after profiling is disabled, authorization policies do not use profiling and the endpoint is not assigned to any policy or group and device is not registered via My Devices Portal.

The solution given by Cisco TAC is to update to ISE version 1.3.

Regards,

(Resuelto) AIX: You are not allowed to login at this time.

Hoy nos han reportado el siguiente problema:

El usuario pepito01 no podía acceder por telnet a una máquina a la que solía acceder normalmente. La autenticación del usuario se realiza mediante LDAP.

# date
Tue Apr 29 11:49:45 CEST 2014

# telnet

login: pepito01
pepito01's Password:

You are not allowed to login at this time.

Entramos como root para ver los atributos. En principio suponía que había alcanzado el número máximo de reintentos, pero el mensaje es distinto.
# ssh
# lsuser -f pepito01
pepito01:
        id=111111
        pgrp=alli
        groups=users
        home=/home/pepito01
        shell=/bin/ksh
        gecos=Prueba
        login=true
        su=true
        rlogin=true
        telnet=true
        daemon=true
        admin=false
        sugroups=ALL
        admgroups=
        tpath=nosak
        ttys=ALL
        expires=0
        auth1=SYSTEM
        auth2=pad_meth
        umask=22
        registry=LDAP
        SYSTEM=LDAP
        logintimes=april28:0000-2359
        loginretries=20
        pwdwarntime=15
        account_locked=false
        minage=1
        maxage=6
        maxexpired=-1
        minalpha=1
        minother=1
        mindiff=3
        maxrepeats=3
        minlen=8
        histexpire=168
        histsize=10
        pwdchecks=
        dictionlist=
        default_roles=
        fsize=2097151
        cpu=-1
        data=262144
        stack=65536
        core=0
        rss=65536
        nofiles=2000
        core_hard=0
        time_last_login=1398699038
        time_last_unsuccessful_login=1398764245
        tty_last_login=/dev/pts/1
        tty_last_unsuccessful_login=/dev/pts/0
        host_last_login=pepito01.host.com
        host_last_unsuccessful_login=pepito01.host.com
        unsuccessful_login_count=1
        roles=

Tras varias pruebas me he dado cuenta de que el mensaje es bastante indicativo ya que dice "this time" por lo que he mirado con detenimiento los atributos relacionados con tiempo y me he dado cuenta de algo que había obviado, el parámetro "logintimes" muestra la fecha de ayer.

Desconozco lo que hacen en la parte LDAP, porque en los parámetros por defecto del sistema y , por tanto, los que aplican al usuario desde nuestra parte dejan vacío este campo. En conclusión, he cambiado el loginretries y he podido entrar. Hemos reportado al grupo de LDAP que ese es el problema y que deben corregir la política.

root@:/# smitty user --> Change / Show Characteristics of a User --> Introducir el nombre del usuario

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
 
[TOP]                                           [Entry Fields]
* User NAME                                     pepito01
  User ID [111111]                                           #
  ADMINISTRATIVE USER?                          false        +
  Primary GROUP                                 [alli]       +
  Group SET                                     [users]      +
  ADMINISTRATIVE GROUPS                         []           +
  ROLES                                         []           +
  Another user can SU TO USER?                  true         +
  SU GROUPS                                     [ALL]        +
  HOME directory                                [/home/pepito01]
  Initial PROGRAM                               [/bin/ksh]
  User INFORMATION                              [Prueba]
  EXPIRATION date (MMDDhhmmyy)                  [0]
  Is this user ACCOUNT LOCKED?                  false        +
  User can LOGIN?                               true         +
  User can LOGIN REMOTELY(rsh,tn,rlogin)?       true         +
  Allowed LOGIN TIMES                           [april29:0000-2359]  --> MODIFICADO A FECHA DE HOY
  Number of FAILED LOGINS before                [3]          #
       user account is locked
  Login AUTHENTICATION GRAMMAR                  [LDAP]
  Valid TTYs                                    [ALL]
  Days to WARN USER before password expires     [15]         #
  Password CHECK METHODS                        []
  Password DICTIONARY FILES                     []
  NUMBER OF PASSWORDS before reuse              [10]         #
  WEEKS before password reuse                   [168]        #
  Weeks between password EXPIRATION and LOCKOUT      [-1]
  Password MAX. AGE                             [6]          #
  Password MIN. AGE                             [1]          #
[MORE...36]

Probamos a hacer el telnet ahora

# telnet

login: pepito01
pepito01's Password:

1 unsuccessful login attempts since last login.
Last unsuccessful login: Tue Apr 29 11:37:25 2014 on /dev/pts/0 from
Last login: Mon Apr 28 17:30:38 2014 on /dev/pts/1 from pepito01.host.com

(pepito01)-> 

Solucionado.

PowerHA: Application Monitor tests

Hola,
he seguido haciendo algunas pruebas con los Application Servers/Controllers y sus monitores en un cluster con PowerHA7.1.2 y he encontrado algunos problemas a los que un administrador se puede enfrentar y que, con un poco de intuición, son fáciles de solucionar.

1) Crear un Application Server/Controller (ver post anterior)
http://jorgelopezaragoneses.blogspot.com.es/2014/04/powerha-application-servercontroller.html

2) Crear un Application Monitor

Yo he creado un "Custom Monitor" ya que quería controlar todo el proceso. Para ver los tipos de monitor y sus atributos podéis profundizar en esta página:
http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.powerha.admngd%2Fha_admin_config_multiple_app_mons.htm

# smitty sysmirror --> Cluster Applications and Resources -->  Resources --> Configure User Applications (Scripts and Monitors) --> Application Monitors  --> Configure Custom Application Monitors --> Add a Custom Application Monitor

                                                        [Entry Fields]
* Monitor Name                                        App_mon
  Application Controller(s) to Monitor         App_control_Jorge                                                +
* Monitor Mode                                        [Long-running monitoring]                                       +
* Monitor Method                                     [/tmp/jorge/monitor.ksh]
  Monitor Interval                                       [20]                                                                        #
  Hung Monitor Signal                                [9]                                                                          #
* Stabilization Interval                                [10]                                                                        #
  Restart Count                                          [3]                                                                          #
  Restart Interval                                        [99]                                                                         #
* Action on Application Failure                  [notify]                                                                    +
  Notify Method                                         []
  Cleanup Method                                     [/tmp/jorge/stop_script.ksh]                                      /
  Restart Method                                       [/tmp/jorge/start_script.ksh]                                      /


3) Pruebas/Errores

Prueba 1: kill del proceso que controla el monitor dejando el cleanup script con exit 1


NOTA: script_infinito es un script con un bucle while cuyo ejecución es controlada por el monitor, es decir, el script debe aparecer en la salida del ps.

node02#  ps -ef | grep script_infinito
    root 11206854  6816064   0 09:22:51      -  0:00 /bin/ksh /tmp/jorge/script_infinito.ksh

node02:/# clRGinfo -m
---------------------------------------------------------------------------------------------------------------------
Group Name     Group State                                              Application state            Node         
---------------------------------------------------------------------------------------------------------------------
RG_prueba   ONLINE                                                                                node02
 App_control_Jorge                                                        ONLINE MONITORED           

node02# kill  11206854 

node02# clRGinfo -m        
---------------------------------------------------------------------------------------------------------------------
Group Name     Group State                                              Application state            Node         
---------------------------------------------------------------------------------------------------------------------
RG_prueba   ONLINE                                                                                node02
 App_control_Jorge                                                        ONLINE MONITOR FAILED      

En /var/hacmp/log/hacmp.out podremos ver como el monitor ha intentado rearrancar la aplicación pero no ha sido capaz porque he puesto un error en el cleanup script.
[..]
server_restart: Calling user specified cleanup method /tmp/jorge/stop_script.ksh
+RG_preuba:server_restart[+199] /tmp/jorge/stop_script.ksh
/tmp/jorge/stop_script.ksh[5]: kill: bad argument count
+RG_prueba:server_restart[+201] STATUS=1
+RG_prueba:server_restart[+202] [ 1 -ne 0 ]
+RG_prueba:server_restart[+204] cl_log 6162 Failure in user-defined script /tmp/jorge/stop_script.ksh.\n /tmp/jorge/stop_script.k
sh
[...]
WARNING: Cluster CL_prueba has been running recovery program 'TE_SERVER_RESTART' for 840 seconds. Please check cluster status.

Esta línea seguirá repitiéndose aunque se corrija el cleanup script porque el cluster ha quedado inestable:
NODO ACTIVO:
node02:/# lssrc -ls clstrmgrES
Current state: ST_RP_FAILED

NODO PASIVO:
node01:/# lssrc -ls clstrmgrES
Current state: ST_BARRIER

- Solución
Corregir el cleanup script y recuperar el cluster de un fallo de script en ambos nodos. Esto deja de nuevo el cluster en ST_STABLE.

# smitty hacmp --> Problem Determination Tools --> Recover From PowerHA SystemMirror Script Failure

NOTA: si todos los scripts de cleanup and restart son correctos, el application monitor recuperará la aplicación.



Prueba 2: ERROR: The application monitor script file:  does not exist or is not an executable
on node: node02.


He puesto "prueba 2", por seguir un orden, pero realmente es un error que he encontrado al trastear un rato con el cluster. Ese error me ha vuelto un poco loco porque todo estaba correcto, pero al pasar la verificación y sincronización del cluster, aparecía una y otra vez.

- Soluciones:

1) Comprobar que el Application Monitor tiene distinto nombre que otros recursos.
2) Comprobar que los scripts que maneja tienen permisos adecuados, que existen en la ruta especificada, etc.
3) Si no hay nada que esté mal realmente:
3.1) Eliminar el Application Monitor y sincronizar
3.2) Volver a declarar el Application Monitor y sincronizar.

Un saludo.

PowerHA: Application Server/Controller tests

Hola,
ayer estuve haciendo algunas pruebas con el script de stop para verificar el comportamiento del cluster ante distintas situaciones ocasionadas por fallos dentro de este script de parada.

Estuve haciendo algunas búsquedas en google ( cluster wait stop script, application server stop script...) y no encontré una documentación clara. Aunque sólo hay que hacer caso a la teoría para sabar cómo va a reaccionar el cluster ante situaciones indeseadas provocadas por el script de parada (lo mismo aplica al script de arranque), he preferido realizar algunas pruebas para documentarlo.

Para no dejar aquí todo un log de sesión, he omitido algunas líneas esperando que sea más claro. Si no, sólo tenéis que preguntar dejando un comentario.

NOTA: Lo que se conoce como Application Server ha pasado a llamarse Application Controller Scripts en PowerHA7.1.

Entorno de test:
- dos nodos con AIX7.1 en cluster gestionado por PowerHA7.1.2.
- prueba 1: stop_script con bucle infinito + intento de takeover
- prueba 2: stop_script con último comando reportando error (touch /home/dir_no_existe/prueba)
- prueba 3: stop_script con penúltimo comando reportando error (el touch de antes) y uno final correcto (touch /home/prueba).

En resumen, PowerHA no se encarga de verificar si lo que ha hecho el script de stop está bien o mal antes de hacer un takeover (es decir, si tiene que parar una BBDD y no lo hace porque no habéis puesto el db2stop, p.ej.) , él sólo comprueba que el script termina bien (exit 0), por lo que en el caso del bucle infinito lo que ocurrirá es que el cluster no hace takeover hacia el otro nodo y hay que "meterle mano" (kill del proceso del stop_script + resolver la situación de error en que queda el cluster después de esta muerte inesperada del script). En la prueba 2, fallará porque la salida del script no es 0, al dar error el último comando y en la prueba 3, terminará bien y hará el takeover ya que, no se tiene en cuenta que no haya comandos erróneos dentro del script, sino que lo que importa es que la salida del script sea 0.

La información de la sesión de pruebas:

------ Creando y añadiendo un Application Server o Application Controller Scripts a un RG --------

1) Crear los scripts de stop/start
2) Crear el recurso Application Server o Application Controller indicando la ruta completa a estos scripts.

PowerHA6.1:
#smitty hacmp --> Initialization and Standard Configuration --> Configure Resources to Make Highly Available --> Configure Application Servers --> Add an Application Server
o
# smitty hacmp --> Extended Configuration --> Extended Resource Configuration --> HACMP Extended Resources Configuration --> Configure HACMP Applications Servers --> Add an Application Server

PowerHA7.1
# smitty sysmirror --> Cluster Applications and Resources --> Resources --> Configure User Applications (Scripts and Monitors) --> Application Controller Scripts --> Add Application Controller Scripts -->

3) Añadir el Application Server/Controller al Resource Group

PowerHA6.1:
# smitty hacmp --> Initialization and Standard Configuration --> Configure HACMP Resource Groups --> Change/Show a Resource Group --> Change/Show Resources in a Resource Group
o
# smitty hacmp --> Extended Configuration --> Extended Resource Configuration --> HACMP Extended Resource Group Configuration --> Change/Show Resources and Attributes for a Resource Group

PowerHA7.1:
# smitty sysmirror --> Cluster Applications and Resources -->  Resource Groups --> Change/Show Resources and Attributes for a Resource Group

4) Sincronizar el cluster

Comprobaciones:

1) Ver que el App. Server está activo
#   clRGinfo -m
---------------------------------------------------------------------------------------------------------------------
Group Name     Group State                                              Application state            Node         
---------------------------------------------------------------------------------------------------------------------
RG_prueba   ONLINE                                                                                node01
App_Contr_Jorge                                                          ONLINE NOT MONITORED       

2) Hacer un takeover para probar que los scripts hacen lo que tienen que hacer.

3) También podéis echar un vistazo al hacmp.out para ver que ha pasado con el App.Server. Hay varias cadenas que podéis buscar para centraros en el App.Server:

node_up_local_complete
start_server
stop_server


node01# grep node_up_local_complete hacmp.out | more    
+RG_prueba:reconfig_resource_complete[633] node_up_local_complete
 
+RG_prueba:node_up_local_complete[+123] . /usr/es/sbin/cluster/events/reconfig_udresources
+RG_prueba:node_up_local_complete[+125] STATUS=0

+RG_prueba:node_up_local_complete[+140] server_acquire_lpar_resources App_Contr_Jorge

+RG_prueba:node_up_local_complete[+148] clcallev start_server App_Contr_Jorge
+RG_prueba:node_up_local_complete[+150] : exit status of start_server App_Contr_Jorge is: 0

+RG_prueba:node_up_local_complete[acquire_udresources+123] +RG_prueba:node_up_local_complete[acquire_udresources+123] getudres types_after APPLICATION
+RG_prueba:node_up_local_complete[+160] : exit status of acquire_udresources is: 0

 node01# grep start_server hacmp.out | more    
+RG_prueba:start_server[start_and_monitor_server+12] dspmsg scripts.cat 99999 Checking whether App_Contr_Jorge is already running
Checking whether App_Contr_Jorge is already running...

+RG_prueba:start_server[start_and_monitor_server+33] dspmsg scripts.cat 99999 Application monitor(s) indicate that App_Contr_Jorge is not active. Continuing with application startup.\n
Application monitor(s) indicate that App_Contr_Jorge is not active. Continuing with application startup.

+RG_prueba:start_server[start_and_monitor_server+59] dspmsg scripts.cat 99999 Running application controller start script for App_Contr_Jorge in the background at Wed Apr  2 11:36:07 CEST 2014.\n
Running application controller start script for App_Contr_Jorge in the background at Wed Apr  2 11:36:07 CEST 2014.

Apr  2 11:36:07 EVENT COMPLETED: start_server App_Contr_Jorge 0


------------ Prueba 1: movimiento de RG con script de stop con bucle infinito --------------

node01# clmgr move rg RG_prueba NODE=node02
Attempting to move resource group RG_prueba to node node02.
 Waiting for the cluster to process the resource group movement request....
 Waiting for the cluster to stabilize.................... ................... ..........              (se queda aquí: bucle)

(TRAS KILL DEL SCRIPT DE STOP)

ERROR: Event processing has failed for the requested resource
group movement.  The cluster is unstable and requires manual intervention
to continue processing.


node01# more /var/hacmp/log/hacmp.out
+RG_prueba:stop_server[+124] /tmp/jorge/stop_script.ksh
+RG_prueba:stop_server[+124] ODMDIR=/etc/objrepos

(ESPERANDO...)

(TRAS KILL DEL SCRIPT DE STOP)
/usr/es/sbin/cluster/events/stop_server[124]: 10092872 Terminated
+RG_prueba:stop_server[+126] [ 143 -ne 0 ]
+RG_prueba:stop_server[+128] cl_log 312 Failed to stop App_Contr_Jorge. App_Contr_Jorge
+RG_prueba:cl_log[+47] [[ high == high ]]
+RG_prueba:cl_log[+47] version=1.11 $Source: 61haes_r711 43haes/usr/sbin/cluster/events/utils/cl_log.sh 1$
+RG_prueba:cl_log[+48] +RG_datos_pro:cl_log[+48] basename /usr/es/sbin/cluster/events/utils/cl_log
PROGNAME=cl_log
+RG_prueba:cl_log[+49] [[ high == high ]]
+RG_prueba:cl_log[+91] SYSLOG_FILE=/var/hacmp/adm/cluster.log
***************************
Apr 2 2014 12:14:35 !!!!!!!!!! ERROR !!!!!!!!!!
***************************
Apr 2 2014 12:14:35 Failed to stop App_Contr_Jorge.
+RG_prueba:stop_server[+129] STATUS=1
+RG_prueba:stop_server[+131] cl_RMupdate resource_error App_Contr_Jorge stop_server

Reference string: Wed.Apr.2.12:14:35.CEST.2014.process_resources.All_servers.RG_datos_pro.ref
+RG_prueba:process_resources[258] (( 1 != 0 ))
+RG_prueba:process_resources[261] : If this failed while stopping an application, manual intervention is required.
+RG_prueba:process_resources[263] [[ stop_server == stop_server ]]
+RG_prueba:process_resources[265] cl_log 650 'process_resources: Failure occurred while processing Resource Group RG_prueba. Manual intervention required.' process_resources RG_prueba
 

node02#  clRGinfo
-----------------------------------------------------------------------------
Group Name     Group State                  Node          
-----------------------------------------------------------------------------
RG_prueba   RELEASING                    node01
               OFFLINE                      node02

(TRAS KILL DEL SCRIPT DE STOP)

node02#  clRGinfo
-----------------------------------------------------------------------------
Group Name     Group State                  Node          
-----------------------------------------------------------------------------
RG_prueba   ERROR                        node01
               OFFLINE                      node02

 
- Corregimos la situación desde el nodo 1:

1) Corregir el script de parada.

2) Recuperar el cluster de la situación de error.
# smitty hacmp --> Problem Determination Tools --> Recover From PowerHA SystemMirror Script Failure

node01# clRGinfo
-----------------------------------------------------------------------------
Group Name     Group State                  Node          
-----------------------------------------------------------------------------
RG_prueba   OFFLINE                      node01
               ACQUIRING                    node02

node01# clRGinfo
-----------------------------------------------------------------------------
Group Name     Group State                  Node          
-----------------------------------------------------------------------------
RG_prueba   OFFLINE                      node01
               ONLINE                       node02

NOTA: Sin corregir el script de parada se puede ejecutar el "Recover" y el RG se moverá al otro nodo.


--------------------- Prueba 2: script de stop con un último comando que da error ----------------


- Los pasos son iguales, así que sólo muestro el hacmp.out:

 [...]
STOP=/tmp/jorge/stop_script.ksh
+RG_prueba:stop_server[+107] +RG_prueba:stop_server[+107] cut -d  -f1
+RG_prueba:stop_server[+107] echo /tmp/jorge/stop_script.ksh
STOP_SCRIPT=/tmp/jorge/stop_script.ksh
+RG_prueba:stop_server[+109] PATTERN=node02 App_Contr_Jorge
+RG_prueba:stop_server[+109] [[ -n  ]]
+RG_prueba:stop_server[+109] [[ -z  ]]
+RG_prueba:stop_server[+109] [[ -x /tmp/jorge/stop_script.ksh ]]
+RG_prueba:stop_server[+119] [ REAL = EMUL ]
+RG_prueba:stop_server[+124] /tmp/jorge/stop_script.ksh
+RG_prueba:stop_server[+124] ODMDIR=/etc/objrepos
touch: /tmp/jorge/prueba/error.err cannot create
+RG_prueba:stop_server[+126] [ 1 -ne 0 ]
+RG_prueba:stop_server[+128] cl_log 312 Failed to stop App_Contr_Jorge. App_Contr_Jorge
+RG_pruebao:cl_log[+47] [[ high == high ]]
+RG_pruebao:cl_log[+47] version=1.11 $Source: 61haes_r711 43haes/usr/sbin/cluster/events/utils/cl_log.sh 1$
+RG_prueba:cl_log[+48] +RG_datos_pro:cl_log[+48] basename /usr/es/sbin/cluster/events/utils/cl_log
PROGNAME=cl_log
+RG_prueba:cl_log[+49] [[ high == high ]]
+RG_prueba:cl_log[+91] SYSLOG_FILE=/var/hacmp/adm/cluster.log
***************************
Apr 2 2014 15:28:44 !!!!!!!!!! ERROR !!!!!!!!!!
***************************
Apr 2 2014 15:28:44 Failed to stop App_Contr_Jorge.
+RG_prueba:stop_server[+129] STATUS=1
+RG_prueba:stop_server[+131] cl_RMupdate resource_error App_Contr_Jorge stop_server

node02# clRGinfo
-----------------------------------------------------------------------------
Group Name     Group State                  Node          
-----------------------------------------------------------------------------
RG_prueba   OFFLINE                      node01
               ERROR                        node02


-------------- Prueba 3: script de stop con touch "malo" más último touch bueno ---------------

- Los pasos son iguales, así que sólo muestro el hacmp.out:

[..]
STOP_SCRIPT=/tmp/jorge/stop_script.ksh
+RG_prueba:stop_server[+109] PATTERN=node01 App_Contr_Jorge
+RG_prueba:stop_server[+109] [[ -n  ]]
+RG_prueba:stop_server[+109] [[ -z  ]]
+RG_prueba:stop_server[+109] [[ -x /tmp/jorge/stop_script.ksh ]]
+RG_pruebao:stop_server[+119] [ REAL = EMUL ]
+RG_prueba:stop_server[+124] /tmp/jorge/stop_script.ksh
+RG_prueba:stop_server[+124] ODMDIR=/etc/objrepos
touch: /tmp/jorge/prueba/error.err cannot create
+RG_prueba:stop_server[+126] [ 0 -ne 0 ]
+RG_prueba:stop_server[+154] ALLNOERRSERV=All_nonerror_servers
+RG_prueba:stop_server[+155] [ REAL = EMUL ]
+RG_prueba:stop_server[+160] cl_RMupdate resource_down All_nonerror_servers stop_server
2014-04-02T15:46:09.890087
2014-04-02T15:46:09.897215
Reference string: Wed.Apr.2.15:46:09.CEST.2014.stop_server.All_nonerror_servers.RG_datos_pro.ref
+RG_prueba:stop_server[+163] exit 0
Apr  2 15:46:09 EVENT COMPLETED: stop_server App_Contr_Jorge  0
 
node02# clRGinfo
-----------------------------------------------------------------------------
Group Name     Group State                  Node          
-----------------------------------------------------------------------------
RG_prueba   OFFLINE                      node01
               ONLINE                       node02


Un saludo.

multibos: update lv names without rebooting

Hola,

este post va por gentileza de mi compañero Michael.

Cuando realizas una actualización en AIX utilinando el método "multibos", se crea una copia de algunos LVs con nombre bos_, para crear otro BOS que es el que vamos a actualizar. Al terminar la actualización, rebotaremos la máquina para que arranque con el sistema operativo actualizado, es decir, arrancará del bos_hd5.

Cuando la máquina arranca podemos observar como, aunque ejecutemos la utilidad de multibos para eliminar el BOS secundario (multibos -R), los LVs con los puntos de montaje correctos han quedado con el nombre bos_.

Este problema, en principio sólo estético, se puede corregir de dos formas:

1) Haciendo una nueva copia del sistema operativo con multibos y volviendo a resetear el sistema:
# multibos -Xs
# shutdown -Fr

2) Renombrando los LVs. IMPORTANTE: no es necesario volver a rebotar la máquina.
Guardamos el nombre del disco de que se ha arrancado y renombramos los LVs antiguos.
# disk=`bootinfo -b`
# chlv -n hd4_old hd4
# chlv -n hd2_old hd2
# chlv -n hd9var_old hd9var
# chlv -n hd10opt_old hd10opt
# chlv -n hd5_old hd5 
Renombramos los LVs buenos para dejarlos con el nombre original.
# chlv -n hd4 bos_hd4
# chlv -n hd2 bos_hd2
# chlv -n hd9var bos_hd9var
# chlv -n hd10opt bos_hd10opt
# chlv -n hd5 bos_hd5
Actualizamos el boot device, recreamos el la boot image y mostramos la lista de arranque
# savebase
# bosboot -ad /dev/$disk 
# bootlist -om normal

 Un saludo.

open(/usr/es/sbin/cluster/etc/vg/datos_vg.uuid, O_RDONLY)

Buenos días,

durante la semana pasada estuvimos haciendo pruebas sobre un cluster con PowerHA 7.1.2 formado por dos máquinas con AIX 7.1 TL2 SP2. Debido a ciertas facilidades que ofrecen los VGs de tipo normal (classic-mode o non-concurrent) a la hora de afrontar una migración/traslado (se pueden realizar scripts con comandos LVM para gestionar los discos), intentamos modificar el tipo de volume group que PowerHA7 establece por defecto: enhanced concurrent volume group.

Tras muchas vueltas, aunque pongamos el VG en active (lspv muestra active en vez de concurrent), cuando arrancamos los servicios de cluster, éste se encarga de poner el VG en modo enhanced concurrent, por lo que no hay forma de cambiarlo. Eso sí, en este intento desesperado por hacer que el PowerHA7 funcione como nosotros queremos, sólo hemos conseguido un error que nos ha sido difícil solucionar:

cl_set_vg_fence_height[180]: open(/usr/es/sbin/cluster/etc/vg/datos_vg.uuid, O_RDONLY): No such file or directory

Solución:
Seguramente haya otras formas más limpias de solucionarlo, pero no he encontrado otra mejor. Lo que yo he hecho ha sido, a través del menú smit (cspoc ->storage->volume groups->set characteristics of a volume group->add a volume to a volume group), añadir un disco que teníamos libre al VG. Esta operación ha recreado el fichero del que se quejaba PowerHA al realizar ciertas acciones.
 
NOTA: Aunque este comando debería hacer lo mismo, no funciona hasta que no está creado ese fichero.
clmgr modify volume_group datos_vg ADD=hdisk12

Un saludo.

ERROR: Multicast communication with node using mping failed [solved]

Hola,
hoy hemos migrado un PowerHA 6.1 a 7.1.2 mediante un mksysb de una máquina con AIX 7.1 y PowerHA 7.1.2_SP02.

Hemos configurado el cluster con sus redes y un resource group en el nodo 1, pero cuando hemos is a sincronizar el script que verifica la comunicación multicast arrojaba un error y el estado quedaba con "Failed":

"
[...]
lscluster: Cluster services are not active.
lscluster: Cluster services are not active.
Saving existing /var/hacmp/clverify/ver_mping/ver_mping.log to /var/hacmp/clverify/ver_mping/ver_mping.log.bak
Verifying clcomd communication, please be patient.
Verifying multicast communication with mping.
ERROR: Multicast communication with node node01 using mping failed.
Errors encountered verifying communications between nodes.ERROR:        Unable to communicate using multicast messages
"

Este es otro ejemplo más de lo poco limpios que han sido los desarrolladores a la hora de hacer estos scripts de verificación, al igual que pasa con clmigcheck tal y como puse en el post anterior (http://jorgelopezaragoneses.blogspot.com.es/2014/01/powerha61-71-upgrade-tips-errors.html).

Veréis que en el fichero /var/hacmp/clverify/ver_mping/ver_mping.log se está utilizando la IP 228.168.101.43 y, probablemente, el grupo de redes no tiene enrutada la MAC Multicast asociada entre sus switches.

La solución es sencilla, hay que editar el script que ejecuta esta comprobación y ponerle la IP multicast que vayamos a utilizar y que ya habremos probado con anterioridad que funciona.

# vi /usr/es/sbin/cluster/diag/ver_mping

 Cambiamos la IP 228.168.101.43 por la nuestra:
# if we got no multicast line from lscluster, we will use the default multicast addr.
MCAST_ADDR4="228.168.101.43"

Un saludo.

PowerHA6.1 to 7.1 Upgrade. Tips, errors & clmigcheck problems [solved]

Hola,
he estado cacharreando en un entorno de pruebas con el PowerHa7.1 y dónde he encontrado "más trampas" ha sido en su actualización porque la administración, salvo que el menú de smit cambia y que tenemos el repository disk y la IP multicast, el resto es muy similar a la hora de administrar.


Problemas que he encontrado en el propio script clmigcheck:

1) ERROR:  PowerHA System Mirror requires a shared disk connected to all nodes in the cluster. None could be found.

Problema: el script clmigcheck no detecta los discos compartidos por ambos nodos, aunque sí los hay.

Solución: Hay que hacer varios cambios en /usr/sbin/clmigcheck o bien crear el fichero /var/clmigcheck/clmigcheck.txt a mano.
El comando cllspvids ha debido cambiar y ahora no debería recibir opciones, aunque en el script clmigcheck si la tiene.

Ejemplo: he comentado las líneas que están mal y he incluido otras con el comando sin opciones.
# Get space separated list of shared disks connected to
# every node in the cluster
#log "prompt_disks: Output from cl_lspvids -n ${node_list}:\n"
log "prompt_disks: Output from cl_lspvids :\n"
#${CSPOCDIR}/cllspvids -n ${node_list} >>${LOGFILE} 2>&1
${CSPOCDIR}/cllspvids >>${LOGFILE} 2>&1               
log "\n"

2) ERROR:  Multicast communication with node srvnimprasce01 failed.

Problema: El script clmigcheck hace un test de mping utilizando una IP Multicast fija definida en el script.

Solución: modificar el script clmigcheck poniendo la IP Multicast que vaya a utilizar el cluster.
NOTA: aunque el tráfico multicast esté habilitado entre dos máquinas, es posible que la MAC Multicast por la que hablan no esté enrutada en los switches.
Para sacar la MAC Multicast que van a utilizar para pasársela al grupo de networking, los tres primeros campos son fijos 01:00:5e: y los tres siguientes corresponden al valor hexadecimal de cada uno de los tres últimos octetos de la IP Multicast del cluster.
Ej: IP Multicast=228.23.14.101 --> MAC Multicast=01:00:5e:17:0e:65


Solución a algunos de los errores reportados por clmigcheck.

1) ERROR: Communications Path for node srvnimprasce02 must be set to hostname

Problema: en /etc/hosts hay una entrada con una IP errónea para uno de los nodos.
Solución: editar /etc/hosts para corregirlo.


2) ERROR:  You must first ensure the ODM configuration has no errors, then you can enter additional configuration information.
Note that you must enter the configuration information before you can install PowerHA System Mirror 7.1 on a system that contains an ODM configuration. You must rerun the tool and first check the ODM configuration, then enter the configuration data.

Problema: se ha ejecutado clmigcheck e inmediatamente se ha seleccionado la opción 3.
Solución: siempre que se necesite ejecutar la opción 3 de clmigcheck, hay que ejecutar primero la opción 1.

3) CONFIG-ERROR: The configuration contains unsupported options:  Heartbeat via IP Alias Address.
The PowerHA network name is .  This will have to be removed from the configuration before migration to PowerHA System Mirror

Problema: hay heartbeat configurados a través de IP alias.
Solución: eliminar la configuración “IP Address Offset” en cada red. Requiere parada de los servicios de cluster.
NOTA: hacerlo en ambos nodos o hacerlo en uno y sincronizar.
# smitty hacmp > Extended Configuration > Extended Topology Configuration > Configure HACMP Networks > Change/Show a Network in the HACMP Cluster
           Change/Show an IP-Based Network in the HACMP Cluster
                                                    [Entry Fields]
* Network Name                                       Red_Adm
  New Network Name                                   []
* Network Type                                       [ether]    +
* Netmask(IPv4)/Prefix Length(IPv6)                  [255.255.255.0]
* Enable IP Address Takeover via IP Aliases          [Yes]       +
  IP Address Offset for Heartbeating over IP Aliases [10.1.1.1]    ?         --> Vaciar []
* Network attribute                                   public     +

Sincronizar
Smitty hacmp > Extended > HACMP Verification and Synchronization


Errores durante la administración de un cluster PowerHA7.1

1) clmgr errors with repository disk operations

Problema: ejemplo
# clmgr replace repository 0004d86a94efa267
ERROR: "0004d86a94ef9202" cannot be found on "machineX"
Available Physical Volumes:
[…]
Solución: modificar la Object Class HACMPsircol poniendo el pvid correcto (lspv)

- Hacer backup del objeto
# odmget HACMPsircol
HACMPsircol:
        name = "SCFE_pro_sircol"
        id = 0
        uuid = "0"
        ip_address = "228.23.14.101"
        repository = "0002329ab3e778dd"
        backup_repository = "0004d86a94efa267"
# odmget HACMPsircol > HACMPsircol.tmp
- Modificar el backup con el PVID bueno
# vi HACMPsircol.tmp
- Eliminar el objeto antiguo
# odmdelete HACMPsircol
- Insertar el objeto nuevo
# odmadd HACMPsircol.tmp


2) Error: RSCT cluster services (cthags) are not active on this node

Problema: Los servicios de cluster no levantan reportando el siguiente error:
rc.cluster: Error: RSCT cluster services (cthags) are not active on this node.
rc.cluster: Try bringing up CAA and RSCT with the following command:
startsrc -g caa.
cl_rsh had exit code = 1, see cspoc.log and/or clcomd.log for more information

En PowerHa 7.1, cthags sustituye a grpsvcs como gestor del Group Service por lo que, en este caso, el problema es que cthags no se ha iniciado correctamente. Para ello es necesario rebotar la máquina con los servicios de cluster activos.

NOTA: es posible que sea necesario levantar los servicios de cluster antes de rebotar o no se pueda rebotar ahora mismo. Será grpsvcs quién esté gestionando el Group Services en ese momento.
Arrancamos el cthags aunque no vaya a hacer nada, pero el chequeo del cluster mira a ver si el subsistema está "active"
# startstc –s cthags
# smitty clstart

Aix Migration: sissas64_dd error [Solved]

Hola,

aunque no he encontrado un documento de IBM en el que diga esto, la experiencia me dice que es así. Para realizar una migración de AIX 5.3 a 6.1 o de AIX 6.1 a 7.1, hay que escoger un software que no tenga un SP muy bajo, pues en ellos es probable que falte el fichero /usr/lib/drivers/pci/sissas64_dd contenido en el fileset devices.common.IBM.sissas.rte.

0301-154 bosboot: missing proto file: /usr/lib/drivers/pci/sissas64_dd

Ejemplo de entornos en los que he encontrado este error y lo he solucionado utilizando otro software: Migración de AIX5.3 TL7 SP4 a AIX6.1 TL6 SP1 --> corregido con AIX6.1 TL7 SP7
Migración de AIX6.1 TL7 SP5 a AIX7.1 TL0 SP1 --> corregido con AIX7.1 TL2 SP2

He visto un par de soluciones que a mí me han funcionado a medias y que seguramente ya hayáis encontrado en otras páginas.

1) Copiar el /usr/lib/drivers/pci/sissas_dd a /usr/lib/drivers/pci/sissas64_dd y recrear la bootimage (bosboot -ad /dev/hdiskX)

2) Traer el /usr/lib/drivers/pci/sissas64_dd de otra máquina con la misma versión y recrear la bootimage.

El problema de esto es que luego te encuentras inconsistencias en el sistema reportadas por lppchk que, por otro lado, es posible que corrijas con instalaciones de software. Yo preferí buscar una instalación limpia.

Un saludo.

Build date error in a AIX TL update [solved]

Hola,
ayer conseguimos corregir un problema que, en principio, tenía muy mala pinta.

Para realizar una actualización con multibos desde AIX6.1_Tl4_SP3 a AIX6.1_TL8_SP2 hay que actualizar el fileset bos.rte.bosinst ya que si no la actualización da un fallo de bosboot.
http://www-01.ibm.com/support/docview.wss?uid=isg1fixinfo137662
En este caso, en vez de actualizar sólo el fileset bos.rte.bosinst, se hizo una actualización intermedia completa a versión TL7 SP07 para luego pasar a TL8 SP02. Problema, la actualización en el último paso fallaba por las build dates.

                   BUILDDATE Verification ...
+-----------------------------------------------------------------------------+
Verifying build dates...
installp: The build date requisite check failed for fileset      devices.pciex.df1020e214103c04.rte.
Installed fileset build date of 1245 is more recent than the selected fileset build date of 1241.
installp: The build date requisite check failed for fileset      devices.pciex.df1020e214100f04.rte.
Installed fileset build date of 1245 is more recent than the selected fileset build date of 1241.
installp: The build date requisite check failed for fileset      devices.pciex.df1020e214103c04.diag.
Installed fileset build date of 1245 is more recent than the selected fileset build date of 1241.
installp: The build date requisite check failed for fileset      devices.pciex.df1020e214100f04.diag.
Installed fileset build date of 1245 is more recent than the selected fileset build date of 1241.
installp: Installation failed due to BUILDDATE requisite failure.

El mayor problema es que no se disponía de ningún tipo de backup de la máquina, ni alternate rootvg, ni multibos, ni siquiera mksysb y tampoco podíamos subir a un TL intermedio, por lo que intentamos solucionar el problema con las herramientas de que disponíamos.
NOTA: si hubiera partido de un estado con todos los filesets en COMMITTED y se hubiera actualizado en APPLIED, podríamos haber empezado por hacer reject
y buscar una versión de AIX inicial cuyos filesets tuvieran un builddate inferior.

Aunque el proceso fue más tedioso de lo que parece, los pasos son bastante simples:

1) Eliminar errores reportados por lppchk
# lppchk -v
csm.server 1.6.0.0                      (not installed; requisite fileset) 
Para eliminarlo, lo buscamos en nuestro repositorio de software y lo instalamos.

2) Eliminar paquetes con BUILDDATE mayor (al no ser bos.rte se podían borrar)
# installp -u

3) Realizar una instalación del software seleccionando la opción overwrite para dejar el sistema en una versión estable desde la que podamos actualizar después.
# smitty install --> “OVERWRITE same or newer versions?   yes”
(En lugar de 452 paquetes ha instalado 76)

4) Realizar la actualización:
# smitty update_all


Éste es un caso particular en el que el estado de la paquetería había quedado algo inestable pero, en general, si tenemos un problema con las BUILD DATES y los paquetes se pueden eliminar, sólo será necesario quietarlos de enmedio y volver a lanzar la actualización.

# installp -u
o
# smit install --> Software Maintenance and Utilities --> Remove Installed Software

Una vez eliminados,
# smitty update_all

Un saludo.