Posts etiquetados ‘errores’

Hoy, de hecho ahora mismo, he tenido que realizar la actualización de un cluster de cortafuegos UTM-1 que se encuentra configurado en full ha (o full hihg avaiability) desde su versión R70 a R75. De hecho la versión final es la R75.20 pero no es posible realizarla directamente y hay que dar el paso intermedio a la R75.

Como está siendo un infierno, os describo a continuación los pasos que deben darse, los problemas encontrados y su resolución.

Tenemos un clúster full ha con dos nodos. Fw1 es el nodo activo tanto de firewall como de management y es el que tiene una mayor prioridad y Fw2 es el nodo pasivo de ambos elementos que asumirá los roles sólo en caso de fallo del nodo principal.

Backup de los elementos:

Lo primero que debemos hacer es un backup completo de ambos nodos, así como de la base de datos de políticas en un equipo externo a los mismos. Así, nos curamos en salud y nos ahorramos disgustos.

1)      Backup de la configuración del equipo a través de la administración web de secureplatform. Esto nos guarda los datos básicos de red del equipo. Aseguraos de tener cerradas todas las GUIs de Smartdashboard o fallará.

2)      Exportado de la política en versión R70 – > #$FWDIR/bin/upgrade_tools/upgrade_export <nombredelfichero>

3)      Exportado de la política en versión R75

  • Para ello, descargamos las migration tools correspondientes a R75 del usercenter y las subimos al appliance principal (bien por SCP bien por FTP) a una carpeta temporal. “/var/tmp” es un buen punto.
  • Damos permiso de ejecución a las migration tools: #chmod a+x *
  • Generamos el fichero de políticas: #migrate export <nombrefichero>

Aseguraos de descargar las políticas generadas bien por FTP, bien por SCP.

4)      Ejecutad el verificador de actualización para comprobar que no existen errores a corregir. Este se encuentra en las migration tools. Si da un error, corregidlo antes de empezar.

Bien, hasta ahora, nada fuera de lo normal de cualquier actualización.

Actualización:

Los pasos son:

1)      Realizar un failover del tráfico al nodo secundario:

#cphaprob -d STOP -s problem -t 0 register

Para dar marcha atrás (por si fuera necesario)

# cphaprob -d STOP unregister

Nota: este paso supone un microcorte

2)      Entrar con Smartdashboard en el management secundario. Al entrar nos dirá que el nodo activo es fw1 y que si queremos cambiarlo. Hacemos que el management secundario sea el activo.

3)      Actualizamos el nodo principal, cargando el correspondiente paquete a través de la interfaz de administración web del nodo fw1. Ojo, en este paso, es recomendable realizar un snapshot y una actualización segura. Es más lento pero nos salvaguardará de errores en la actualización, asegurando la marcha atrás.

4)      Accedemos con la consola de dashboard de R75 al nodo fw1. Colocamos el objeto de clúster a versión R75 e instalamos políticas. Recordad desmarcar la opción de “For firewall cluster install on all members” o fallará.

5)      Actualizamos vía web el nodo fw2 con la imagen correspondiente. Al ejecutar un cpstop para actualizar, el tráfico pasará al nodo fw1 con un microcorte.

6)      Una vez sincronizado, abrimos smartdashboard en fw1. Instalamos políticas en ambos nodos.

7)      Abrimos Policy > Management high Availability y pulsamos el botón sincronizar.

Parece fácil y sencillo ¿verdad? Pues nada más lejos de la realidad.

Problemas, problemas, problemas.

Justo después de sincronizar, si refrescamos el estado de ambos cortafuegos, aparece el nodo fw2 como unreachable. Si tratas de comprobar la SIC de este nodo, se indica lo siguiente:

“SIC Status for : Not Communicating Authentication error [error no. 147] ** Check that peer SIC is configured properly and that system date and time on the SmartCenter Server and peer are synchronized.

Tratamos de resetar la SIC de este nodo pero no hay cambios, no se puede conectar.

Si cerramos el smartdashboard, no podremos conectar de nuevo con fw1 apareciendo un error:

“Connection cannot be initiated make sure the server “xx.xx.xx.xx” is up and running and you are defined as a GUI Client”

Si realizamos: # ps aux | grep cpca  el resultado aparecerá como cpca – readonly

Lo que ocurre es que durante la actualización se ha perdido un certificado de CA en el nodo principal fw1 y es por esto por el que no podemos conectar al smartdashboard o al otro nodo.

Para corregirlo ejecutamos en el nodo fw1:

#cd $CPDIR/conf

# cp sic_cert.p12 sic_cert.p12old

#cpca_client revoke_cert -n “CN=cp_mgmt”

#cpca_client create_cert -n “CN=cp_mgmt” -f $CPDIR/conf/sic_cert.p12

#cpstop

#cstart

Esto regenera los certificados y nos permitevolver a conectar al smartdashboard. OJO: ESTO PROVOCA CORTE TOTAL ya que paramos los servicios del nodo que gestiona el tráfico y el cluster no está montado.

Pero, ¿Qué pasa con el nodo secundario? Pues que aún no lo hemos conectado. Para ello:

Ejecutamos en ambos nodos #fw unloadlocal esto vuelve a PROVOCAR CORTE TOTAL  pero es necesario dado que las políticas no nos permiten conectar ambos nodos del cluster puesto que en este momento fw2 no forma parte del cluster. Reestablecemos la SIC e instalamos políticas. En este punto el firewall está operativo.

Sólo nos queda sincronizar ambos management, pero el del nodo 2 no se deja. Pese a que la SIC está establecida y funcionando, la sincronización de managements nos dice que el fw2 está unreachable. Para corregir esto:

#cpstop

#cd $FWDIR/conf/mgha

# rm ./*

#cd ..

#rm applications.C* CPMIL*

#cpstart

Ahora podemos realizar la sincronización y todo vuelve a la normalidad. Ya sólo queda la actualización a R75.20. Que cthulhu nos coja confesados.

Saludillos

En esta entrada trato de resumir las conclusiones de tres días de intenso y tedioso troubleshooting, investigacion, aprendizaje express y prueba y error de numerosos métodos de resolución hasta lograr reunir todos los datos que encontraba con cuenta gotas en la Technet y dar con la solución definitiva. Espero que este post ahorre trabajo de investigación a través de las engorrosas páginas de la Technet a alguien.

Me notificaron que las búsquedas de Sharepoint del portal corporativo de uno de mis clientes habían dejado de funcionar. Casualmente habían dejado de funcionar el mismo día que tuvimos un problema con el Sharepoint completo relacionado con el antivirus que había provocado la necesidad de reinicio de los servidores de Sharepoint.

Antes de continuar, os explico la arquitectura, aunque esta es poco relevante para la solución. Disponen de un clúster de balanceo de carga para el servicio de Sharepoint formado por dos servidores (SP1 y SP2) y un cluster de alta disponibilidad que aloja las bases de datos correspondientes a Sharepoint (bdd). Para el servicio de búsquedas disponen de un único servicio compartido (SharedService) del cual el servidor SP1 es el índice y servidor de consulta y el SP2 se usa tan sólo como servidor de consulta.

Bueno pues, manos a la obra. A la hora de investigar un problema en Sharepoint, el registro de eventos de windows es vuestro amigo. Es bastante chivato y proporciona información útil. En este caso, observamos en un pricipio los errores:

Nombre de registro:Application
Origen: Office Server Search
Fecha: 19/06/2012 13:37:25
Id. del evento:10038
Categoría de la tarea: Servicio de búsqueda
Nivel: Advertencia
Palabras clave: Clásico
Usuario: No disponible
Equipo: SP2
Descripción:
El equipo de consulta ‘SP1’ ha salido de la rotación a causa del error El índice de contenido está dañado. 0xc0041800. Se volverá a intentar dentro de 900 segundos. Componente: cc575544-4acf-490f-bed4-d23cd4b56d90

——————————————————————————————————————————————————————————–

Nombre de registro: Application
Origen: Office Server Search
Fecha: 19/06/2012 13:37:25
Id. del evento:10039
Categoría de la tarea: Servicio de búsqueda
Nivel: Advertencia
Palabras clave: Clásico
Usuario: No disponible
Equipo: SP1
Descripción:
El intento del equipo de consulta ‘SP1’ no se ha producido a causa del error El índice de contenido está dañado. 0xc0041800. Se volverá a intentar dentro de 900 segundos. Componente: cc575544-4acf-490f-bed4-d23cd4b56d90

Y tras el reinicio de los servicios de búsqueda con net stop osearch (se inicia sólo automáticamente) comienza a aparecer también el registro:

Nombre de registro:Application
Origen: Office Server Search
Fecha:19/06/2012 15:20:04
Id. del evento:4138
Categoría de la tarea: Servidor de índice de contenido
Nivel: Error
Palabras clave: Clásico
Usuario: No disponible
Equipo: SP1
Descripción:
Se han detectado daños de índice en el componente ShadowMerge del catálogo Portal_Content. La referencia de la pila es .Componente: cc575544-4acf-490f-bed4-d23cd4b56d90

Y aquí es cuando os ahorro el calvario. Este error viene del reinicio realizado al servidor de índices en el momento equivocado y en el lugar equiv… no, no. Sólo en el momento equivocado, dado que el servidor estaba realizando el registro de transacciones del índice en el momento del reinicio y estas han quedado en estado inconsistente. Al haberse fastidiado el índice, las búsquedas no funcionan aunque exista otro nodo de consulta. Tampoco funcionan los rastreos de contenido. Aparecen como “En ejecución” pero no están haciendo nada. Puedes comprobarlo accediendo al registro de rastreo y comprobando que no existe ninguna entrada con fecha posterior a la corrupción del índice. ¿Por qué este bloqueo no canta en ningun lado? Pues no lo sé, tal vez a los rastreos de índice les guste vaguear.

Para arreglarlo tenemos que seguir unos sencillos pasos (una vez te los sabes…)

1) Paramos completamente los servicios de búsqueda de Sharepoint en ambos nodos. Es decir, los desconfiguramos y desactivamos a nivel de Sharepoint en los dos nodos.(ojo, antes de hacer esto, asegúrate de apuntar todos los parámetros del servicio) Esto puede hacerse desde el menú de servidor en la administración central de Sharepoint o con el comando de consola:

stsadm –o osearch –action stop

Stsadm lo podreis encontrar en C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN.

2) Paramos los servicios de búsqeda de ambos servidores desde el administrador de servicios o con el comando

net stop osearch

En este caso el servicio se mantiene detenido.

3) Accedemos a la ruta de almacenamiento de índices del servidor de índice. Allí habrá una carpeta cuyo nombre-número-chorizo coincida con el componente que se indica como dañado en los registros de eventos anteriores. En nuestro caso, habrá una carpeta llamada cc575544-4acf-490f-bed4-d23cd4b56d90. Renombramos esta carpeta, la movemos a otra localización o si somos unos temerarios, la borramos.

4) Desde la administración central de Sharepoint reconfiguramos y arrancamos los servicios de búsqueda de los nodos tal y como estaban antes. Puede que no reaccione y tengais que ejecutar en la consola:

stsadm –o osearch –action start

5) Levantamos los servicios de búsqueda desde el administrador de servicios o con el comando:

net start osearch

6) Configuramos el servicio SharedService para usar SP1 como generador de índice. Para ello, en la pestaña de “Administración de servicios compartidos” de la administración central de Sharepoint pinchamos sobre “SharedServices” (nombre de nuestro servicio, si el vuestro se llama “pepito”, pues debeis pulsar en él) y aparecerá un desplegable con las opciones de configuración, donde en el SSP, podreis configurar el indizador.

A partir de aquí, la carpeta de índice debería haberse regenerado y el servicio de búsqueda debería funcionar de nuevo. Sólo queda asegurar que el nuevo contenido añadido durante el problema se incluya en la búsqueda y esto se consigue realizando un rastreo completo de las áreas de búsqueda.

Eso es todo amiguitos. Si quereis mi dirección para mandarme jamones de agradecimiento por esta valiosa información, dejad un comentario con vuestro email y os la haré llegar encantada.

Saludillos.