Categoría: Troubleshooting

Solución de problemas

Forzar replicacion csync2

vacosta Deja un comentario

Forzar replicacion de directorios csync2

En caso de que tengamos implementada la replicacion de archivos via csync2es probable que existan casos en los que necesitemos forzar la replicacion de archivos manualmente ya sea para asegurarnos que esta todo replicado o para identificar problemas

Identificar configuración

Lo primero que tenemos que hacer es identificar para que configuración o para que directorio queremos forzar la replicacion

Las configuraciones las podemos encontrar dentro del directorio /etc/csync2/

El csync2 permite tener varias configuraciones diferentes y dentro de cada configuración podemos definir uno o mas directorios que se replicaran, estas configuraciones se definen en los archivos /etc/csync2/csync2_nombreconf.cfg, donde nombreconf es el nombre de la configuración.

Forzar la replicacion

Una vez identificado el nombre de la configuración podemos forzar la replicacion con el siguiente comando

csync2 -C nombreconf -xXvrB

Ejemplo, si nuestra configuración se llama www

csync2 -C www -xXvrB

Explicación de las opciones utilizadas:

  • C: Para identificar la configuración
  • x: Verifica todos los archivos y sus actualizaciones
  • X: Verifica archivos borrados
  • r: Verifica de forma recursiva directorios y sub-directorios
  • B: No bloquea la base de datos sqlite con grandes transacciones
  • v: habilita el modo verbose, se puede habilitar mas nivel de detalle agregando la opción varias veces. Ejemplo: csync2 -C www -xXvvvvrB

En algunos casos la replicacion falla debido a que faltan directorios padres en los otros equipos, en estos casos existen 2 soluciones:

  • Sincronizar la estructura de directorio a mano, esto seria crear a mano los directorios faltantes en los demás nodos
  • Ejecutar la sincronizacion en modo ejecución inicial, esto se hace agregando la opción -I, esto es un tanto arriesgado porque podemos llegar a perder datos, se debe ejecutar en el nodo que tiene la ultima versión de los datos

Analizar Crash/Core dump HP-UX

vacosta Deja un comentario

Analizar crash HPUX

Para analizar los crash que se generan en HPUX utilizaremos el comando kwdb

Lo primero que debemos hacer es identificar el directorio del crash dentro de /var/adm/crash/crash.N donde N es el numero de crash generado

Luego debemos acceder a dicho directorio 

cd /var/adm/crash/crash.1

E ingresamos a las consola del kwdb con el siguiente comando:

kwdb -q4 -p -m .

Una vez adentro activamos 14 

q4> set kwdb q4 on

Luego ejecutamos los reportes WhatHappened, WhatHappened -HANG y Analyze AU

Los mismos los redireccionamos a los archivos what.out, whath.out y ana.out respectivamente

q4> run WhatHappened > what.out 
processing ....... done!
 
q4> run WhatHappened -HANG > whath.out
processing ....... done!
 
q4> run Analyze AU > ana.out 
processing ....... done!
 
q4> exit

Luego nada mas nos queda leer estos 3 archivos para ver que errores encontramos

more what.out
 
more whath.out
 
more ana.out

Solucionar error failed to load selinux policy freezing RHEL/CentOS 7

vacosta 2 comentarios

Solucionar error failed to load selinux policy freezing

Este error se da debido a que los archivos no tienen etiqueta selinux, este error se podria dar por ejemplo cuando cambiamos la politica de SeLinux de disabled a enforcing.
La manera de solucionar esto es iniciando el equipo sin SELinux activo y forzar el re-etiquetado de todos los archivos

Deshabilitar SeLinux durante el proceso de arranque

El selinux se puede deshabilitar en la linea de arranca del grub, para esto debemos editar la linea de arranque del grub y al final de los parametros del kernel se debe agregar, selinux=0

Una vez hecho esto iniciamos el equipo y una vez adentro activamos el selinux en modo permissive, para esto el archivo /etc/selinux/config debe quedar de la siguiente manera:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

y creamos el archivo /.autorelabel para que fuerce el re-etiquetado de todos los archivos del FS

touch /.autorelabel

Luego debemos reiniciar el equipo, al siguiente inicio debera re-etiquetar todos los archivos (esto podria tardar bastante, dependiendo de la cantidad de archivos que tenga cada FS), una vez que termine el re-etiquetado y nos permita ingresar al sistema podemos activar en selinux con el comando

setenforce 1

Luego activamos de manera permanente el SELinux, para esto el archivo /etc/selinux/config debe quedar de la siguiente manera:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Una vez que terminamos todos los pasos, se recomienda reiniciar una vez mas el equipo para asegurarse de que el SELinux se active de manera automatica y que el equipo inicie sin problemas

Instalar driver VIA en CentOS/RHEL/SL 7

vacosta Deja un comentario

Instalar driver VIA en CentOS/RHEL/SL 7

En caso de instalar CentOS 7 sobre algun hardware viejo con chipset VIA es muy probable que no reconozca las tarjetas de red o que las reconozco pero tenga problemas como por ejemplo que muestre que la tarjeta soporta hasta 100Mbps cuanto en realidad soporta hasta 1000Mpbs, para solucionar esto podemos descargar los drivers del repositorio "ElRepo"

En caso de tener internet en el equipo procedemos con los siguientes comandos:

rpm -Uvh http://mirror.symnds.com/distributions/elrepo/extras/el7/x86_64/RPMS/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
yum install kmod-forcedeth

En caso de no tener internet en dicho equipo lo que debemos hacer es descargar los paquetes en otro equipo, copiarlos y luego instalarlos.

Solucionar error Probably resource factory threw an exception.: () oVirt/RHEV vdsm

vacosta Deja un comentario

Solucionar error Probably resource factory threw an exception.: () oVirt/RHEV vdsm

Si al tratar de realizar alguna tarea sobre nuestros discos virtuales, es decir:

  • snapshots
  • clonaciones
  • exportaciones
  • importaciones
  • storage live migration

En la lista de eventos del oVirt GUI se presenta el siguiente error:

Probably resource factory threw an exception.: ()

Y en los logs del vdsm /var/log/vdsm/vdsm.log del host que es SPM encontramos el siguiente mensaje:

OSError: [Errno 17] File exists: '/rhev/data-center/00000002-0002-0002-0002-00000000008b/e1f1947b-b04a-4a50-a22d-f65110516143/images/58693eb1-d498-480e-95e7-524e0a682410'
67acab09-4bfb-4f05-a4f6-a36b31e01743::WARNING::2016-04-03 14:16:45,951::resourceManager::594::Storage.ResourceManager::(registerResource) Resource factory failed to create resource 'e1f1947b-b04a-4a50-a22d-f65110516143_imageNS.58693eb1-d498-480e-95e7-524e0a682410'. Canceling request.
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/resourceManager.py", line 590, in registerResource
    obj = namespaceObj.factory.createResource(name, lockType)
  File "/usr/share/vdsm/storage/resourceFactories.py", line 193, in createResource
    lockType)
  File "/usr/share/vdsm/storage/resourceFactories.py", line 122, in __getResourceCandidatesList
    imgUUID=resourceName)
  File "/usr/share/vdsm/storage/image.py", line 189, in getChain
    srcVol = volclass(self.repoPath, sdUUID, imgUUID, uuidlist[0])
  File "/usr/share/vdsm/storage/blockVolume.py", line 80, in __init__
    volume.Volume.__init__(self, repoPath, sdUUID, imgUUID, volUUID)
  File "/usr/share/vdsm/storage/volume.py", line 181, in __init__
    self.validate()
  File "/usr/share/vdsm/storage/blockVolume.py", line 89, in validate
    volume.Volume.validate(self)
  File "/usr/share/vdsm/storage/volume.py", line 193, in validate
    self.validateImagePath()
  File "/usr/share/vdsm/storage/blockVolume.py", line 460, in validateImagePath
    raise se.ImagePathError(imageDir)
ImagePathError: Image path does not exist or cannot be accessed/created: (u'/rhev/data-center/00000002-0002-0002-0002-00000000008b/e1f1947b-b04a-4a50-a22d-f65110516143/images/58693eb1-d498-480e-95e7-524e0a682410',)

Posiblemente se deba a quedaron links simbolicos rotos en el directorio que apunta a los volumenes presentados al cluster /rhev/data-center/

La solucion para dicho problema es eliminar todos los link simbolicos que se encuentran "rotos", es decir que apuntar a una ruta inexistente, para hacer eso podemos usar el siguiente comando:

[root@virt3 ~]# for file in $(find /rhev/data-center/ -type l); do [ -h "$file" -a ! -e "$file" ] && rm -fvr "$file"; done;

Dicho comando debe ejecutarse en el host que esta como SPM, aunque es recomendable ejecutarlo en todos los hosts de manera a que cuando alguno asuma como SPM no se vuelva a presentar el problema.

Una vez que hecho esto podemos reitentar la tarea que habia fallado.

Solucionar error ERROR 1047 (08S01): WSREP has not yet prepared node for application use

vacosta Deja un comentario

Solucionar error 1047 en MariaDB

Este error se genera normalmente en las siguientes situaciones:

  • Cuando tenemos un cluster MariaDB con 2 nodos y uno de los nodos es apagado de manera brusca
  • Se pierde la conexion entre los nodos del cluster

El error que se genera es el siguiente:

error ERROR 1047 (08S01): WSREP has not yet prepared node for application use

Para solucionar dicho error tenemos 2 opciones:

  • Detener el servicio de mysql en el nodo que quedo solo y luego realizar el "bootstrap" del cluster, en CentOS/RHEL 6 se utilizarian los siguientes comandos: 
    service mysql stop
    service mysql bootstrap
  • La otra forma de solucionar es ingresando a la consola mysql del nodo que quedo activo y establecer el valor "pc.bootstrap=yes" a la variables wsrep_provider_options 
MariaDB> SET GLOBAL wsrep_provider_options="pc.bootstrap=yes";
Query OK, 0 rows affected (0.00 sec)

Con esto podremos volver a utilizar nuestras bases de datos de manera normal.