Hoy un compañero me ha comentado que una máquina arrojaba algunos warnings al ejecutar ciertos comandos:
# lscfg -vpl fcs0
libodm: The specified search criteria is incorrectly formed.
Make sure the criteria contains only valid descriptor names and
the search values are correct.
libodm: The specified search criteria is incorrectly formed.
Make sure the criteria contains only valid descriptor names and
the search values are correct.
libodm: The specified search criteria is incorrectly formed.
Make sure the criteria contains only valid descriptor names and
the search values are correct.
libodm: The specified search criteria is incorrectly formed.
Make sure the criteria contains only valid descriptor names and
the search values are correct.
[salida comando]
Buscando por google hay varias entradas que nos indican que hay algún problema en la ODM, pero no dábamos con ella hasta que otro compañero, Javier, ha dado con la clave:
# lsdev -C
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device gab.
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device vxdmp.
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device vxio.
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device vxspec.
[...]
Al listar los objetos contenidos en la clase "Customized Devices" se queja de ciertos objetos que no están en la clase "Predefined Devices" que son los que están provocando los mensajes de arriba. Borramos estos objetos de la ODM:
# odmdelete -q "name=gab" -o CuDv
# odmdelete -q "name=vxdump" -o CuDv
# odmdelete -q "name=vxio" -o CuDv
# odmdelete -q "name=vxspec" -o CuDv
NOTA: si alguien no se siente cómodo tocando la ODM, se puede hacer un backup antes bien de todo /etc/objrepos o bien de /etc/objrepos/CuDv.
martes, 29 de octubre de 2013
jueves, 18 de julio de 2013
AIX: bos.rte.install BROKEN [solved]
En ocasiones nos encontramos con que, tras una actualización de software aparentemente correcta, algún fileset se queda en estado BROKEN. En mi caso se trataba del paquete bos.rte.install.
Versión de AIX 6.1 TL7 (anteriormente TL3)
Para corregir este tipo de problemas he recopilado información de distintos lugares, entre ellos PMRs de IBM en los que el soporte de nivel 2 da opciones complejas que en mi caso fueron las que nos llevaron a corregir el problema.
- Problema:
# lppchk -v
lppchk: The following filesets need to be installed or corrected to bring
the system to a consistent state:
bos.rte.install 6.1.7.17 (usr: APPLIED, root: BROKEN)
- Soluciones (conjunto de procedimientos que se deberían probar en orden)
1) Descargar el paquete de IBM FIX CENTRAL u obtenerlo de algún repositorio del administrador. Sobreescribir:
# installp -acgN -d . bos.rte.install.6.1.7.1
2) Reinstalar el fileset completo, es decir, la versión base más el update correspondiente. Forzar la instalación (-F):
# installp -acFNXYd /SOFTWARE/inst bos.rte.install
NOTA: conseguir el paquete base en ocasiones es muy difícil.
3) Desinstalar el fileset completo ("Remove Software Products": -u), si éste lo permite (los bos.rte.* no lo permiten), y reinstalarlo.
# installp -u bos.net.tcp.server
Si nada de esto funciona, es posible que el problema sea que la Trusted Signature Database (TSD) esté corrupta.
“The TSD is a database of security attributes of the trusted files that are present on the system. The TSD is in the /etc/security/tsd/tsd.dat file. This database gets populated at installation time. It stores the security attributes of the trusted files that are present on the system.”
[Read more: http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.security%2Fdoc%2Fsecurity%2Fbos_tsd.htm]
Esto se puede ver:
a) El chequeo de la TSD falla:
# trustchk -q ALL
Error while processing tsd.
b) Si en un debug de la instalación del paquete encontramos algo parecido a lo siguiente:
# instsecattr -a -f bos.rte.install.sec
Error while processing stanzas
Es decir, el comando depende de la TSD y ha fallado al leer sus stanzas.
Cuando hay corrupción de la TSD no hay forma soportada de corregir el problema salvo restaurar la máquina. Pero se pueden probar dos procedimientos no oficiales:
1) Eliminar el paquete de la ODM y después rehacer el upgrade.
NOTA: en este ejemplo el bos.rte.install es versión 6.1.7.17 por ello mod=7 y fix=17. Sustituir por los valores correctos.
Primero hacemos un backup
# mkdir /tmp/backup_odm
# odmget -q "lpp_name=bos.rte.install AND mod=7 AND fix=17" product > /tmp/backup_odm/file1
# odmget -q "lpp_id=13 AND mod=7 AND fix=17" history > /tmp/backup_odm/file2
# ODMDIR=/usr/lib/objrepos odmget -q "lpp_name=bos.rte.install AND mod=7 AND fix=17" product > tmp/backup_odm/file3
# ODMDIR=/usr/lib/objrepos odmget -q "lpp_id=13 AND mod=7 AND fix=17" history > /tmp/backup_odm/file4
Eliminar el fileset de la ODM
# odmdelete -q "lpp_name=bos.rte.install AND mod=7 AND fix=17" -o product
# odmdelete -q "lpp_id=13 AND mod=7 AND fix=17" -o history
# ODMDIR=/usr/lib/objrepos odmdelete -q "lpp_name=bos.rte.install AND mod=7 AND fix=17" -o product
# ODMDIR=/usr/lib/objrepos odmdelete -q "lpp_id=13 AND mod=7 AND fix=17" -o history
Ejecutar lppchk -v que debería salir limpio.
Primero probar a instalar sólo el fileset: bos.rte.install
#smitty installp
Si no funciona, intentar
#smitty update_all
2) Si ésto no funciona, intentarlo trayendo un tsd.dat de otra máquina con igual versión de bos.rte.security
Primero, llevar a cabo el procedimiento anterior para limpiar la ODM del paquete en estado BROKEN.
Después, hacer backup del tsd.dat
#mv /etc/security/tsd/tsd.dat /etc/security/tsd/tsd.dat.old
Copiar el tsd.dat de otra máquina con igual versión de bos.rte.security
#scp x.x.x.x:/etc/security/tsd/tsd.dat .
Instalar de nuevo el bos.rte.install
Versión de AIX 6.1 TL7 (anteriormente TL3)
Para corregir este tipo de problemas he recopilado información de distintos lugares, entre ellos PMRs de IBM en los que el soporte de nivel 2 da opciones complejas que en mi caso fueron las que nos llevaron a corregir el problema.
- Problema:
# lppchk -v
lppchk: The following filesets need to be installed or corrected to bring
the system to a consistent state:
bos.rte.install 6.1.7.17 (usr: APPLIED, root: BROKEN)
- Soluciones (conjunto de procedimientos que se deberían probar en orden)
1) Descargar el paquete de IBM FIX CENTRAL u obtenerlo de algún repositorio del administrador. Sobreescribir:
# installp -acgN -d . bos.rte.install.6.1.7.1
2) Reinstalar el fileset completo, es decir, la versión base más el update correspondiente. Forzar la instalación (-F):
# installp -acFNXYd /SOFTWARE/inst bos.rte.install
NOTA: conseguir el paquete base en ocasiones es muy difícil.
3) Desinstalar el fileset completo ("Remove Software Products": -u), si éste lo permite (los bos.rte.* no lo permiten), y reinstalarlo.
# installp -u bos.net.tcp.server
Si nada de esto funciona, es posible que el problema sea que la Trusted Signature Database (TSD) esté corrupta.
“The TSD is a database of security attributes of the trusted files that are present on the system. The TSD is in the /etc/security/tsd/tsd.dat file. This database gets populated at installation time. It stores the security attributes of the trusted files that are present on the system.”
[Read more: http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.security%2Fdoc%2Fsecurity%2Fbos_tsd.htm]
Esto se puede ver:
a) El chequeo de la TSD falla:
# trustchk -q ALL
Error while processing tsd.
b) Si en un debug de la instalación del paquete encontramos algo parecido a lo siguiente:
# instsecattr -a -f bos.rte.install.sec
Error while processing stanzas
Es decir, el comando depende de la TSD y ha fallado al leer sus stanzas.
Cuando hay corrupción de la TSD no hay forma soportada de corregir el problema salvo restaurar la máquina. Pero se pueden probar dos procedimientos no oficiales:
1) Eliminar el paquete de la ODM y después rehacer el upgrade.
NOTA: en este ejemplo el bos.rte.install es versión 6.1.7.17 por ello mod=7 y fix=17. Sustituir por los valores correctos.
Primero hacemos un backup
# mkdir /tmp/backup_odm
# odmget -q "lpp_name=bos.rte.install AND mod=7 AND fix=17" product > /tmp/backup_odm/file1
# odmget -q "lpp_id=13 AND mod=7 AND fix=17" history > /tmp/backup_odm/file2
# ODMDIR=/usr/lib/objrepos odmget -q "lpp_name=bos.rte.install AND mod=7 AND fix=17" product > tmp/backup_odm/file3
# ODMDIR=/usr/lib/objrepos odmget -q "lpp_id=13 AND mod=7 AND fix=17" history > /tmp/backup_odm/file4
Eliminar el fileset de la ODM
# odmdelete -q "lpp_name=bos.rte.install AND mod=7 AND fix=17" -o product
# odmdelete -q "lpp_id=13 AND mod=7 AND fix=17" -o history
# ODMDIR=/usr/lib/objrepos odmdelete -q "lpp_name=bos.rte.install AND mod=7 AND fix=17" -o product
# ODMDIR=/usr/lib/objrepos odmdelete -q "lpp_id=13 AND mod=7 AND fix=17" -o history
Ejecutar lppchk -v que debería salir limpio.
Primero probar a instalar sólo el fileset: bos.rte.install
#smitty installp
Si no funciona, intentar
#smitty update_all
2) Si ésto no funciona, intentarlo trayendo un tsd.dat de otra máquina con igual versión de bos.rte.security
Primero, llevar a cabo el procedimiento anterior para limpiar la ODM del paquete en estado BROKEN.
Después, hacer backup del tsd.dat
#mv /etc/security/tsd/tsd.dat /etc/security/tsd/tsd.dat.old
Copiar el tsd.dat de otra máquina con igual versión de bos.rte.security
#scp x.x.x.x:/etc/security/tsd/tsd.dat .
Instalar de nuevo el bos.rte.install
lunes, 18 de febrero de 2013
Usar flechas (arrow keys) en línea de comandos
Hola,
hoy me han reportado un problemilla estético en una máquina AIX6.1. Cuando estaban en la línea de comandos las flechas de cursor no iban a los comandos anteriores sino que desplazaban el cursor por la pantalla y el siguiente texto introducido siempre daba un fallo.
Lo he corregido metiendo lo siguiente en el .profile del usuario, además de añadir el PS1 que suelo utilizar:
export TERM=vt320
export PS1=${USER}@`hostname`:'${PWD}# '
set -o emacs
# Go back in command history (up arrow)
alias __A=''
# Go back in command history (down arrow)
alias __B=''
# Move right on the command line (right arrow)
alias __C=''
# Move left on the command line (left arrow)
alias __D=''
Además, al seleccionar emacs como editor para la línea de comandos, te permite autocompletar pulsando dos veces la tecla 'Esc'.
Un saludo.
hoy me han reportado un problemilla estético en una máquina AIX6.1. Cuando estaban en la línea de comandos las flechas de cursor no iban a los comandos anteriores sino que desplazaban el cursor por la pantalla y el siguiente texto introducido siempre daba un fallo.
Lo he corregido metiendo lo siguiente en el .profile del usuario, además de añadir el PS1 que suelo utilizar:
export TERM=vt320
export PS1=${USER}@`hostname`:'${PWD}# '
set -o emacs
# Go back in command history (up arrow)
alias __A=''
# Go back in command history (down arrow)
alias __B=''
# Move right on the command line (right arrow)
alias __C=''
# Move left on the command line (left arrow)
alias __D=''
Además, al seleccionar emacs como editor para la línea de comandos, te permite autocompletar pulsando dos veces la tecla 'Esc'.
Un saludo.
Suscribirse a:
Entradas (Atom)