martes, 29 de abril de 2014

(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.

viernes, 4 de abril de 2014

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.

jueves, 3 de abril de 2014

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.