Welcome to Pandora FMS Community › Forums › Soporte de la comunidad › Actualizar 2.1 a 3.x
-
Actualizar 2.1 a 3.x
Posted by oliver on December 16, 2009 at 15:21Hola, tenemos un Pandora 2.1, y nos gustaría actualizar a la 3.0 rc2, el leído el link:
“http://www.openideas.infg/wiki/index.php?title=Pandora_3.0:Documentation_es:Anexo_Actualizacion”
pero solo indica el cambio para pasar la base de datos de la 2.x a 3.x.Supongo que una vez actualizado la bases de datos, hay que instalar la consola, servidor y agentes desde 0, pero me gustaría saber:
¿Hay que desinstalar previamente la versión 2.1 del server y agentes?
¿Cuales son los pasos que hay que seguir?Muchas Gracias.
suzdal replied 14 years, 11 months ago 2 Members · 6 Replies -
6 Replies
-
::
Hola.
Es complicado pasar de la 2.x a la 3, ya que ha cambiado bastante la cosa.
Te recomiendo que empieces por cambiar los agentes a la 3 que son compatibles hacia atrás, el conf del agente lo puedes mantener que seguirá funcionando.
Respecto al servidor tendrás problemas, ya que la Bdd ha cambiado su estructura, lo ideal que es que hagas una instalación desde cero, y una vez que lo tengas actives varios agentes para empezar ha hacer las pruebas de rendimiento, cuando tengais lista la planificación de alertas, módulos, plantillas el recon, etc… activa el resto de agentes.
ya veras que en esta v3, las cosas van más finas y rápidas.
-
::
Explico mi caso.
Es largo así que pongo varios mensajes.
Toda la documentación de la versión 3, la podéis encontrar aquí:
http://openideas.info/wiki/index.php?title=Pandora_3.0:DocumentationExplico la migración que estoy haciendo yo y mi planing.
Yo por falta de recursos, uso la versión vmware: http://openideas.info/wiki/index.php?title=Pandora_3.0:Documentation_es:Instalacion_CD_Appliance
Esto me da la ventaja de la virtualización, en temas de administración, backup, etc… que ya conocemos todos.Al igual que la versión 2.x ambas corren en vmware, con lo cual el deploy es muy fácil.
En mi caso, yo manejo unas 100 +/- workstations, y unos 10 servers, con lo cual hacer el cambio es algo laborioso.
-
::
Paso 1: Escogiendo el entorno de prueba.
Al igual que en muchos casos, antes de hacer la puesta en marcha definitiva, hay que hacer las correspondientes pruebas y tests, yo escogí 4 usuarios, uno aventajado correspondiente al dep. de TI (con un portátil bueno, dual core, etc…), un usuario típico y un “patata caliente” que no sabe nada y que estropea más de lo que usa, por ultimo también me añadí a mi mismo en la lista.
Los motivos son claros:
– El usuario de TI tiene por uso SQL, terminal services, el kit de desarrollo, cristal reports, visual studio, .NET, etc… si el agente no le interfiere en su trabajo y rendimiento, entonces no hay problema.
– El usuario típico es el que usa de todo y de nada, es el que se queja de que va lento teniendo mil ventanas abiertas y escuchando música.
– Y el “Patata Caliente”, es el torpe, el que dice “Yo no he tocado Nada”.
– Y yo mismo, el administrador que uso de todo y no me puede molestar.En todos los casos hay que monitorizar y controlar sin molestar y sin afectar al rendimiento, con lo cual el agente ha de ir fluido.
-
::
Paso 2: Diseño del agente.
-Previo:
En mi caso, digamos maniático del control, me gusta tener que levantarme poco de mi sitio, con lo cual intenta que en el Login.bat del arranque del usuario tener las cosas listas para el monitoreo, scripts que generen logs, wmi de procesos, etc… mételos aquí.
-Diseño:
Reglas a tener en cuenta:
a) Todo lo que puedas hacer desde el agente mejor.
b) Aprovecha al máximo las funciones del agente:Si vas a monitorizar un log, usa el modulo del agente, no uses un vbs.
module_begin
module_name LOG – AV – OnAccessScanLog
module_type async_string
module_regexp C:Documents and SettingsAll UsersDatos de programaMcAfeeDesktopProtectionOnAccessScanLog.txt
module_description Log new lines from AV OnAccessScanLog
module_pattern .*
module_endc) Intenta usar las API ‘s de Windows son muy rápidas.
d) Si usas vb’s, para hacer ejecuciones, usa
Set objWshScriptExec = objShell.Exec(“mi programa”)
Set objStdOut = objWshScriptExec.StdOut
La primera línea ejecuta la segunda muestra la salida del programa.
El modo exec es algo más rápido que el run.
e) Si usas WMI para hacer consultas simples usa el agente: (ver la regla a.)
Es más rápido usar el agente.
module_begin
module_name HOST – CPU – 0 speed
module_type generic_data
module_wmiquery select * from Win32_PerfFormattedData_PerfOS_Processor where name = 0
module_wmicolumn PercentProcessorTime
module_description CPU#0 Perf Percent
module_endHacer un vbs y que el agente lo lanze no es efectivo, es una cuestión simple, mejor en un paso que en dos.
f) Si usas WMI para hacer cosas más complejas, intenta hacerlo en cuantas menos lineas mejor, es más rápido.
Si hay problemas de diseño o no se calcula bien la ejecución un módulo puede retrasar al resto (el usuario se quejará de que va lento) o dar un error y que el agente no envíe la información al servidor y dejará un proceso colgado en el sistema.
g) Si no queda más remedio que recurrir a programas del DOS, volver a aplicar de nuevo las reglas, en su defecto si hay que ejecutar un programa DOS, hazlo desde el agente y desde un vbs, luego ya depuraremos y escogeremos el mejor.En todos los casos, aplica las reglas de diseño de programas, para evitar redundancias de código, código basura, recursividades, etc…
En mi caso, dadas las nuevas funciones del agente v3, he rediseñado algunos módulos, dejando de usar vbs para hacer las WMI directamente y he añadido nuevos.
Los primeros días, cuando lo tengas y empieces a recibir datos, presta atención en los tiempos de ejecución, es simple, el primer y último módulo del agente han de ser un timestamp, usa el comando now() del vbs, te muestra los segundos, si usas TIME /T del DOS, sólo muestra la hora y minutos.
De la misma manera, usa los timestamp para controlar los tiempos de los módulos, por defecto el agente se ejecuta cada 5 minutos, si un módulo tarda más de (por decir algo) 4 seg, es lento, pasa algo o lo has cargado mucho para que recoja mucha información, con lo cual es inservible.
Un módulo ha de ser algo rápido y conciso:
Mirar el consumo de ram:module_begin
module_name HOST – MEM – Firefox RAM
module_type generic_data
module_exec tasklist | grep firefox | gawk “{ print $5 }” | tr -d “.”
module_description Consumo de RAM del firefox en KB
module_endSe ejecuta por el DOS, pero es más rápido que usar un vbs, para mirar el perflog, filtrar y procesar.
Otro ejemplo es:Hacer una consulta al registro de Windows es más rápido que usar un vbs, para consultar objetos.
module_begin
module_name USB – Devices-1
module_type async_string
module_exec reg query HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDiskEnum /s | grep USB
module_description USB Devices ?
module_end -
::
Paso 3: Deploy en Test – Estrés
Instala y lanza la nueva configuración en los conejillos de indias, utiliza el Login.Bat que para eso sirve.
Aunque suene mal, putealos, cambia configuraciones, comprueba las configuraciones, si tienes módulos que comprueban el estado de aplicaciones o servicios, páralos, ponlos en estados diferentes, cuelgo los procesos, ponlos en estado de suspensión, borra los logs, etc…
Mira los resultados, ves cambiando a modo debug y mira las salidas del XML.
Este paso es al gusto del consumidor, vaya que si eres el administrador, tú mejor que nadie sabe lo que quieres mirar y que hacer.
Paso 4: Deploy en Pre-producción.
Este es el gran paso, el entorno Server del 2.x realmente no te sirve de mucho, ya que los cambios en el diseño hacen que una instalación desde cero sea la mejor opción, así que toca rehacer lo que ya habías hecho.
Quizás es el más laborioso, pues hay que diseñar todo el entorno de la consola con las nuevas funciones y estados de los monitores, pero invertir tiempo aquí es lo que te ahorrará más luego.
Con los datos que tengas de los 4 agentes, monta los reports, plantillas, alertas, etc… y repite el paso 3, de esta manera contarás con un entorno casi listo para el llevarlo a un entorno real.
Una vez que lo tengas todo, aumenta el muestreo, instala más agentes y comprueba que todo funciona bien y las alertas se lanzan correctamente.
Si algo falla aquí es el momento de arreglarlo.
Cuando ya tengas todo decidido depura el agente, recuerda que en algunos casos, tendrás con casi toda seguridad datos duplicados, algún módulo de dará la misma salida que otro, sobretodo si usas un vbs para hacer una tarea y a la vez usas el agente para hacer consultas wmi o para ejecutar programas.
Aunque parezca contradictorio, en algunos casos un vbs es mejor que el modulo del agente de Pandora, ya que en el vbs puedes tener un control de errores y podrás formatear la salida a gusto, esto no quiere decir que siempre uses un vbs, recuerda que Pandora FMS ofrece las herramientas gawk y grep.
Paso 5: Producción.
Pon en marcha todo, usa el Login.bat para propagar la instalación y la configuración tuya personalizada.
Recuerda que el agente tiene la opción de instalación silenciosa y ofrece scripts de arranque, parada, instalación y restart del servicio, así que el modo es instalar, parar, copiar la configuración y arrancar.
-