Archive

Archive for the ‘HP-UX’ Category

HP-UX: No funcionan los logs de kerberos

August 26th, 2009 RuBiCK No comments

Configurando kerberos en HP-UX 11.31 como cliente, observo que no se produce ningún registro en los logs del sistema.
Esto es extraño puesto que en los ficheros de configuración /etc/krb5.conf de ejemplo hay un apartado en el cual se definen los logs:

[logging]
        kdc = FILE:/var/adm/kerberos/krb5kdc.log
        admin_server = FILE:/var/adm/kerberos/kadmin.log
        default = FILE:/var/adm/kerberos/krb5lib.log

Y el caso es que nunca aparecían dichos ficheros por lo que los cree manualmente y les dí permisos 777

#ls -la /var/adm/kerberos/*
-rwxrwxrwx   1 root       sys              0 Aug 10 13:05 /var/adm/kerberos/kadmin.log
-rwxrwxrwx   1 root       sys              0 Aug 10 13:05 /var/adm/kerberos/krb5kdc.log
-rwxrwxrwx   1 root       sys              0 Aug 10 13:05 /var/adm/kerberos/krb5lib.log

Pero nada de nada, aunque el kerberos en algunas pruebas funcionaba y en otras no, los logs permanecían vacios. Según la documentación de HP, el man etc… indica que se debe configurar como os he mostrado más arriba.

Finalmente el cliente de kerberos que viene incluido con HP-UX así como en Windows ADS NO es el MIT kerberos y solo este último puede dejar logs. Están indicadas estas entradas en el fichero de configuración para preservar la compatibilidad.

Espero que este post os ahorre horas de pruebas que no os volváis locos.

Categories: HP-UX Tags: ,

HP-UX: Magic number wrong (namelist mismatch?)

August 11th, 2009 RuBiCK No comments

Durante la aplicación de un conjunto de parches y tras el reinicio correspondente, todo parecía funcionar bien excepto al hacer un lanscan el cual devolvía el prompt sin mostrar nada por pantalla y más extraño aun era lo que devolvía el dmesg:

# lanscan
#
# dmesg
Magic number wrong (namelist mismatch?)
#

El problema existente consiste en que el kernel que está cargado en memoria no es el mismo que existe en /stand/vmunix

En este caso en particular previo al comienzo de la intervención se había hecho un split del vg00 quedando cada lvol dividido en lvolX y lvolXb. De esta manera, se parchea sobre los lvolX y la marcha atrás está asegurada.
El vg00 al contener dos discos y hacer el split, un disco contendrá la totalidad de los lvoles “productivos” y el otro disco contendrá los lvoles “spliteados”.

Veamos sobre que disco están los lvoles que la máquina está usando:

#lvdisplay -v /dev/vg00/lvol1
[...]
— Distribution of logical volume —
PV Name LE on PV PE on PV
/dev/dsk/c2t1d0 16 16
[...]

Comparemoslo con el disco del cual ha arrancado la máquina:

# setboot
Primary bootpath : 0/1/1/0.0.0
Alternate bootpath : 0/1/1/0.1.0

La máquina debería de haber arrancado teóricamente del Primary bootpath si nadie ha intervenido de manera manual durante el arranque, pero vamos a asegurarnos para ver de cual ha arrancado exactamente:

# echo boot_string/s | adb /stand/vmunix /dev/kmem
boot_string:
boot_string: disk(0/1/1/0.0.0.0.0.0.0;0)/stand/vmunix

Parece que coincide el hardware path del cual ha arrancado la máquina y del que hay configurado en el setboot, pero solo conocemos el hardware path del disco, vamos a conocer su fichero de dispositivo:

# ioscan -H 0/1/1/0.0.0 -kfn
Class     I  H/W Path     Driver S/W State   H/W Type     Description
=====================================================================
disk      1  0/1/1/0.0.0  sdisk CLAIMED     DEVICE       HP 146 GST3146707LC
                         /dev/dsk/c2t0d0   /dev/rdsk/c2t0d0

Vaya! así que la máquina ha arrancado del disco /dev/dsk/c2t0d0 pero actualmente tiene montado los lvoles que residen en el /dev/dsk/c2t1d0

¿Que es lo correcto aquí? La máquina debe arrancar de los lvoles sin splitear que residen en /dev/dsk/c2t1d0 como hemos visto anteriormente con lvdisplay, por lo que solo deberemos añadir este HW path como primary boot path y los lvolesb como alternate:

# ioscan -kfn /dev/dsk/c2t1d0
Class     I  H/W Path     Driver S/W State   H/W Type     Description
=====================================================================
disk      2  0/1/1/0.1.0  sdisk CLAIMED     DEVICE       HP 146 GST3146707LC
                         /dev/dsk/c2t1d0   /dev/rdsk/c2t1d0
#setboot  -p 0/1/1/0.1.0
#setboot -a 0/1/1/0.0.0
#setboot
Primary bootpath : 0/1/1/0.1.0
Alternate bootpath : 0/1/1/0.0.0

Autoboot is ON (enabled)
Autosearch is ON (enabled)

Tras reiniciar la máquina, el comando dmesg y lanscan vuelven a funcionar correctamente.

Espero que os sirva de ayuda y si os pasa esto mismo, encontreis esta información de una manera rápida, ya que tras una intervención con el tiempo contado, que dejen de funcionar comandos y salgan mensajes “mágicos” no es nada tranquilizador.

Si tenéis alguna pregunta, no dudeis en dejar vuestros comentarios.

Categories: HP-UX Tags:

HP-UX: Mirror del VG00 en itanium

June 26th, 2009 RuBiCK 2 comments

Hoy vamos a ver como se realiza el mirror del vg00 en un HP-UX bajo itanium. Esta operación consiste en particionar el disco, copiar los ficheros de la EFI, añadir una partición del disco al vg00, crear mirror a nivel LVM de cada lvol y establecer las distintas areas de swap, dump etc… . De tal manera que si un disco fallara, tendríamos alta disponibilidad por lo que se podría reemplazar el disco dañado por otro nuevo y reconstruir el mirror, además de poder realizar un split del vg para realizar una intervención garantizando la marcha atrás.

Para llevar a cabo el mirror a parte de requisito imprescindible tener dos discos (da igual si son locales o de SAN) también hace falta tener licenciado el Mirrordisk/UX, vamos a chequearlo:

#swlist | grep -i mirrordisk
B2491BA B.11.23 MirrorDisk/UX (Server)

Es de vital importancia que reconozcamos sin lugar a errores el disco del sistema operativo y cual va a ser el disco de mirror. En el ejemplo que vamos a ver a continuación tenemos el disco c0t6d0 en el cual está instalado el sistema operativo y el disco c28t5d0 que está vacio sobre el que haremos el mirror.

Una vez tenemos claros los discos a usar, tenemos que particionar el disco que está vacio, haremos tres particiones en el siguiente orden: EFI, sistema operativo y HPSP.

  1. En la primera partición (s1) de 500MB irá la EFI la cual es la implementación moderna de la BIOS sobre máquinas itanium aunque hace tiempo que ha dejado de estar presente en exclusiva en servidores y se usa también en algunos ordenadores domésticos como por ejemplo en toda la gama de macs basados en intel.
  2. En la segunda partición (s2) que ocupará todo lo que quede libre entre la primera y tercera partición en la cual irá el sistema operativo.
  3. Y como tercera partición (s3) de 400MB la HPSP (HP Service Partition) que estará destinada a instalar unas herramientas de diagnóstico hardware offline.

Una vez tenemos claro la distribución de las particiones y que albergaremos en cada una de ellas, vamos a particionar nuestro disco,. Para ello creamos un fichero temporal en el cual indicaremos dicha tristribución de la siguiente manera: Read more…

Categories: HP-UX, Unix & Linux Tags: , ,

HP-UX: Duplicar impresoras entre sistemas

June 10th, 2009 RuBiCK No comments

Supongamos que tenemos un sistema con muchas impresoras y tenemos que replicarlas a una nueva máquina. Vamos a ver un método sencillo y seguro para llevar esta tarea a cabo.

La manera de hacerlo es mediante lpmgr, con la opción “-S” exportamos la configuración en el destino que le indiquemos mediante “-xsavedir=/path/destino” y si usamos la opción “-R” restauraremos la configuración. Veamos un ejemplo.

Lo primero de todo es exportar las impresoras en el sistema de origen:

/usr/sam/lbin/lpmgr -S -v -xsavedir=/var/sam/lp/
tar -cvf printers.tar /var/sam/lp

Ahora nos llevamos el fichero printers.tar a la máquina de destino, lo desempaquetamos y lo importamos parando previamente el scheduler para finalmente dejarlo arrancado:

lpshut
tar -xvf printers.tar
/usr/sam/lbin/lpmgr -R -xsavedir=/var/sam/lp/
lpsched -v

Esto mismo se puede hacer mediante SAM el cual recomiendo no usar a no ser que sea absolutamente necesario.

Categories: HP-UX Tags: ,

HP-UX 11.31: Migrar un vg con discos legacy a discos ágiles

May 7th, 2009 RuBiCK 4 comments

Como ya hablé en el post Agile view addressing podemos trabajar usando los dispositivos antiguos o caminos /dev/disk/c#t#d# o los dispositivos nuevos /dev/disk/disk# Os recomiendo que useis los dispositivos en formato agil ya que llevan por debajo la capa de multipathing y será más facil gestionar un único fichero de dispositivo que no 8 y si eso lo multiplicamos por 50 discos que la máquina tenga, os podeis hacer a la idea de la gran diferencia.

¿Que ocurre si tenemos un vg lleno de discos antiguos y queremos migrarlo a discos en formato agil? Lo que tendremos que hacer únicamente es extender el vg con los discos en formato agil y reducir de dicho vg los pvs y pvlinks, así uno por uno.

Número de discos/paths de un vg usando discos en formato legacy:

#vgdisplay -v vgtest |grep -i “pv name”| wc -l
330

Una vez hayamos realizado esta ardua tarea, tendremos un vg con muchos menos discos dentro de él además de tenerlos balanceados con la política que estimemos oportuna.

Número de discos de un vg usando discos en formato agil:

#vgdisplay -v vgtest |grep -i “pv name”| wc -l
42

Y ahora vamos a hacer lo mismo, pero de manera automática, HP-UX provee una herramienta para realizar la migración del vg en caliente mediante un script ubicado en /usr/contrib/bin/vgfsf al cual tan solo tenemos que indicarle si queremos añadir los discos ágiles, eliminar los legacy o hacer ambas acciones combinadas:

/usr/contrib/bin/# ./vgdsf -c
USAGE: vgdsf {-a | -d | -c} vg_name
  -a - Add persistent DSFs to the volume group
  -d - Delete legacy DSFs from the volume group
  -c - Convert legacy DSFs to persistent DSFs (-a and -d)
       in the volume group

Vamos a ver un ejemplo:

/usr/contrib/bin/# ./vgdsf -c vgtest
Converting legacy DSFs to persistent DSFs in VG vgtest
Too many links. Removing link /dev/dsk/c8t1d2
Removed link /dev/dsk/c8t1d2
Persistent DSF /dev/disk/disk268 added to VG vgtest
Too many links. Removing link /dev/dsk/c8t1d3
Removed link /dev/dsk/c8t1d3
[...]

Tras realizar esta operación, tendremos un vg mucho más limpio y sin realizar ningún tipo de esfuerzo. Espero que os sirva de ayuda.

Categories: HP-UX Tags: ,

HP-UX 11.31: gestión de cores con coreadm

April 24th, 2009 RuBiCK No comments

Hoy os traigo una nueva funcionalidad para la última versión de HP-UX para manejar los cores que puedan generar los procesos. Los usuarios de Solaris y otros unix les resultará familiar pero no ha sido hasta la versión 11.31 cuando se ha incorporado a HP-UX.

Hasta ahora, si se generaba un core, se generaba y guardaba en la ruta la cual el fichero estuviera ubicado. Ahora, podremos gestionar todos los cores que se generen en la máquina de una manera global y centralizada indicando que se guarden todos en un directorio determinado con un formato concreto en vez que todos se llamen core, esta gestión la estableceremos con el comando coreadm.

Tenemos una lista de parámetros para personalizar el nombre que le vamos a dar a los cores que se generen y la siguiente:

         %p   process ID
         %xp  Process ID in hex
         %u   effective user-ID
         %xu  effective user-ID in Hex
         %g   effective group-ID
         %xg  effective group-ID in Hex
         %c   thread's CPU number when the core file was created
         %f   executable file name, up to a maximum of MAXCOMMLEN characters
         %n   system node name (uname -n)
         %t   time-stamp (in UTC time format)
         %%   literal %

Como podemos ver, es bastante personalizable, pero mejor veamos un ejemplo práctico.

Vamos a indicar al sistema que deje todos los cores bajo /var/adm/crash/cores/ pero con un determinado formato que nos indique el usuario, PID y nombre de proceso que lo generó de la siguiente manera:

(root):/root> coreadm -e global -g /var/adm/crash/cores/core.%f.%u.%p

Lanzamos un proceso dejándolo en segundo plano y le forzamos para que genere un core mediante la señal 3 de kill

(root):/root> sleep 100&
[1]     1167
(root):/root> kill -3 %1
(root):/root> jobs
[1] + Quit(coredump)           sleep 100&

Y ahora vamos al directorio donde hemos indicado que nos deje los cores para ver si ha funcionado:

(root):/root> ls -la /var/adm/crash/cores
total 1872
drwxr-xr-x   2 root       sys             96 Apr 21 17:41 .
drwxr-xr-x   4 root       root            96 Apr 21 17:35 ..
-rw-------   1 root       root        284848 Apr 21 17:41 core.sleep.0.1167

Ahora teniendo todos los cores bajo un mismo directorio será mucho más facil tenerlos controlados, hacer algún mini-script para que nos avise una vez se genere algún core etc…

Categories: HP-UX Tags: ,

panic: post_hndlr(): Unresolved kernel interruption

April 22nd, 2009 RuBiCK No comments

Hoy traemos un nuevo y magnífico panic para HP-UX 11.31 tras analizar el dump con la utilidad crashinfo nos quedamos con la siguiente información:


panic: post_hndlr(): Unresolved kernel interruption

Stack Trace:
  IP                  Function Name
  0xe0000000007793a0  $cold_vm_hndlr+0x5b0
  0xe000000001c90780  bubbledown+0x0
  0xe00000000061b6d1  $cold_vx_ireuse+0xce1
  0xe000000000af0450  vx_iget+0x2a0
  0xe000000000b1cc60  vx_dirlook+0x5e0
  0xe000000000c15260  vx_lookup+0x11f0
  0xe000000000c7abd0  lookupname+0x3b0
  0xe000000000cf3f40  lstat+0x60
  0xe000000000be7600  syscall+0x540
End of Stack Trace

Esta situación se soluciona aplicando el parche de kernel PHKL_38041 (requiere reboot)

Tenéis bastante más información en el link del parche.

Categories: HP-UX Tags: ,

HP-UX 11.31 : Agile View Addressing

April 21st, 2009 RuBiCK No comments

Hoy, vamos a adentrarnos en una de las características más esperadas en la última versión de HP-UX que hace referencia a la gestión de dispositivos, por fin, se usan dispositivos persistentes. En versiones anteriores a la 11.31 la vista de dispositivos la llamaremos “legacy view”. Por recordar, si tenemos discos presentados a la máquina y cambia su hardware path, su fichero de dispositivo también cambia e incluso si despresentamos un disco y no borramos su fichero de dispositivo asociado, a la hora de presentar un nuevo disco usará un fichero de dispositivo ya existente además de tener un fichero de dispositivo por cada camino al disco.

Ahora se introducen nuevos conceptos como el “Agile View” mediente el cual el fichero de dispositivo irá vinculado al WWID por lo que por mucho que cambie el harware path será persistente, el fichero de disposivo siempre será el mismo y contendrá todos los caminos asociados. Esto quiere decir que yo no necesitamos software para el multi-pathing como securepath, autopath, powerpath etc..

Esta vista agil, se compone de “Lun Hardware Path” que será el dispositivo final vinculado al WWWID cuyo hardware path vendrá definido en hexadecimal y será el dispositivo que deberemos usar. Por otro lado tendremos los “Lun Path” que serán los distintos caminos que tiene un disco.

Los discos o caminos vistos de manera tradicional tienen el formato /dev/dsk/c#t#d# donde representan la instancia de la controladora, el SCSI target id y Lun. Este dispositivo, siempre irá vinculado al hardware path.
La vista ágil, es virtualizada bajo ficheros con la siguiente notación: /dev/disk/disk# donde el número representa una instancia en formato ágil y tendremos uno por dispositivo.

Para resumir, si tenemos un disco mediante el cual accedemos a través de cuatro caminos, tendremos cuatro dispositivos /dev/dsk/c#t#d# apuntando al mismo disco que podrán cambiar mientras que ahora, tendremos un único dispositivo /dev/disk/disk# el cual nunca cambiará, veamos ejemplos prácticos:
Read more…

Categories: HP-UX, Unix & Linux Tags: ,

Reason 0×56: NaT Consuption Fault

April 8th, 2009 RuBiCK No comments

Erase una vez un HP-UX 11.23 que tras estar funcionando varios años, de repente generó un panic y su consiguiente crash. Este crash hubicado en /var/adm/crash/crash.N es poco analizable por nosotros por lo que había que pasarle el crashinfo el cual genera información algo más legible y nos encontramos con lo siguiente (muestro un pequeño extracto)

Trap information
================

Reason 0x56: NaT Consuption Fault

Interrupt Instruction Pointer:
IIP = 0xdead31.0xe00000000053e7c0, slot 0

Interrupt Instruction Bundle:

tcp_rput+0x22a0(): (@ 0xe00000000053e7c0)
|10756 /ux/core/kern/common/net/netinet/tcp.c
+0x22a0 st8 [r67]=r84
nop.m 0x0
|10758 /ux/core/kern/common/net/netinet/tcp.c
br.call.dptk.many b0=0xe0000000004ba400 // tcp_conn_con()
|10756 /ux/core/kern/common/net/netinet/tcp.c

Tras abrir consulta a soporte nos indicaron que el problema se solucionaba aplicando el parche original PHNE_34671 el cual si lo buscamos en http://itrc.hp.com vemos como el parche PHNE_37897 lo supercede por lo que será el que aplicaremos:

phne_34671

Al instalar este parche recompila kernel y por consiguiente necesita reboot, una vez instalado, a dormir tranquilos :)

Categories: HP-UX Tags: ,

lvrename en hpux

April 6th, 2009 RuBiCK 2 comments

Es una pena que en hpux no exista el comando lvrename que sí que existe en Linux mediante el cual podemos renombrar el nombre a un lvol.

Aunque no exista el comando lvrename como tal, podemos realizar un workaround para renombrar el lvol:

Lo primero de todo será desmontar el lvol sobre el que vamos a trabajar:

host:/root (root) #bdf /mnt
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg00/lvignite 5259264   68107 4866719    1% /mnt
host:/root (root) #umount /dev/vg00/lvignite

Ahora tomamos nota del minor que tiene el lvol que queremos renombrar:

host:/root (root) #ls -la /dev/vg00/lvignite
brw-r-----   1 root       sys         64 0x00000a Jul 24  2007
/dev/vg00/lvignite

Borramos el fichero de dispositivo del lvol y su raw device asociado:

host:/root (root) #rm /dev/vg00/lvignite
host:/root (root) #rm /dev/vg00/rlvignite

Y ahora lo que tendremos que hacer es recrear los ficheros de dispositivo mediante mknod. Podremos ponerle el nombre que queramos siempre y cuando le pongamos el mismo minor y major que hemos visto antes.
Para recrear los ficheros de dispositivos, lo haremos mediante el comando mknod.

El uso del mknod es el siguiente:

mknod name b|c major minor

Donde name es el nombre del fichero de dispositivo a crear, “b” para crear el fichero de acceso en modo bloque o “c” para acceso en modo caracter (raw). El major cuando trabajamos con lvm siempre es 64. Este dato lo sacamos viendo el driver que usa lvm: Read more…

Categories: HP-UX Tags: ,