Un blog mas

Bitácora de vuelo

>Hace meses, unos seis, mi notebook Compaq Presario de la serie V3000 (una 3818LA para ser mas exacto) empezó a tener problemas en el arranque. Exactamente lo que le pasaba era que no encendia la primera vez que le daba al botón de power y quedaba colgado en un estado intermedio que me dejaba las luces del power, volumen, reset y mute encendidas pero el resto de la máquina sin reaccionar. La apagaba (manteniendo el botón de power unos segundos), la encendia nuevamente y ahí si arrancaba. Este procedimiento funcionaba siempre y cuando la notebook esté enchufada. Con la bateria se quedaba colgada en todos los casos. Importante es recalcar que esta falla se presentó unas semanas después del año de compra, por ende, en teoría había perdido la garantia.

Un día de aburrimiento, dando vueltas por la web descubrí que dicha falla se debía a una mal configuración del algoritmo de administración del cooler (que se encuentra en la BIOS) lo que hacia que la laptop caliente mas de lo debido, eso hizo que en las patas del micro (o su zócalo, eso no me quedó claro) se forme una «costra» con el barniz que las protege, lo que hacia que la tensión del micro se «pierda» por esas vías y al no llegar la tensión suficiente (creo que 1,8v) no arrancara la compu.

Las soluciones que HP daba a la comunidad que había adquirido esta tanda de equipos con problemas (que incluia a las Compaq Presario v3000, y tambien a las de la serie v6000 de Compaq, las HP Pavilion dv2000 y las HP Pavilion dv6000) era:

  • Si la compu aún no presentaba problemas de encendido (también podía presentar fallas en la placa de wi-fi), actualizar la BIOS.
  • Si la compu ya tenía estos síntomas, HP extendia la garantia a dos años por reconocer una falla en su fabricación. Entonces te comunicas con el 0800-555-5000 (este número ya está grabado en mi memoria), te la pasan a buscar por la dirección que le digas y en 5 a 7 días hábiles (jejejeje) te la devuelven a tu casa reparadita.

Bueno, eso es lo que hice, llame al 0800, opciones 3-1-1, la llevé yo a HP en la calle Luis M. Campos 1059 donde me atendieron tremendamente bien, un lunes 6 de febrero de 2009 y me garantizaron que la compu la recibiria esa misma semana pero que realmente HP siempre dice que la entregan entre 5 y 7 dias hábiles como me informaron por telefono.

A los 7 días me llamaron para pedir una prórroga de tiempo de cuatro dias mas porque se habian demorado con la espera de un repuesto (tenian que cambiar el mother).

Desde ahí nunca mas me llamaron hasta antes de ayer para que la pase a buscar ya reparada. Hoy es viernes 13 de febrero, o sea que el temita superó ampliamente el mes.

En resumidas cuentas empecé a leer foros donde le daban con un caño al servicio técnico de HP Argentina. Todos coincidian con que te retenian la máquina entre 2 y 3 meses y te la regresaban con la misma falla. Triste, no?

Ni hablar que llamé cada dos días, siempre hablando con unos mexicanos que me atendieron de 10 pero siempre sin recibir info de su estado .

LA SOLUCION!!!!

Uno de esos foros, creo que era el del blog de clarin, publicó el telefono de Dios (o el departamento de calidad de HP).

Serían ellos los que picanearan al soporte de HP Argentina????

La respuesta si es positiva :p

El Viernes pasado me logré comunicar con el Dto. de Calidad, 0800-555-5000, opcion 3-1-7 (ahí estaban escondidos), me asignaron una chica que seguiría mi caso y a los pocos dias me llamaron para arreglar la entrega.

Ahí no termina la historia (lamentablemente). Cuando le estaba reinstalando mi sistema operativo predilecto (Ubuntu) detecte unos 15 pixels muertos (negros) en forma de raya al medio de la pantalla (que obviamente no estaban ahi hace unos meses).

El tema es que hacemos ahora?

Pierdo un mes mas para que lo arreglen?
Lo cubre la garantia?
Como demuestro que todos los pixels estaban vivitos hace un mes?

Llame nuevamente al depto. de calidad y ahorita mismo manitos estoy esperando un llamado de los mexicanos.

Les cuento luego como me fué, pero espero no comprar un equipo de HP en el futuro.

>Syslog-ng es un demonio que corre a la espera de registros de logs, basicamente utilizado para cuando las virtudes del clasico Syslog no alcanzan. Las mejores caracteristicas se describen a continuación:

  • Centralizado de logs en un único servidor
  • Almacenamiento en multiples bases de datos.
  • Disponibilidad de herramientas de análisis con interfaz web (como el phpsyslog-ng)
  • Compatibilidad con sistemas operativos de MS.

A continuación se detalla el procedimiento para la instalación en un servidor Ubuntu Server 8.10 en donde se almacenaran los eventos de varios servidores Linux y Windows en una base de datos Mysql y serán visualizados con la interfaz web que proporciona el phpsyslog-ng.

Para ello es necesario contar con:

  • Syslog-ng [1]
  • Servidor Web Apache [1]
  • Php [1]
  • Base de datos Mysql Server [1]
  • php-syslog-ng [2]
  • NTsyslog-ng [3]

Nota: El php-syslog-ng quedó freezado en sourceforge en la versión 2.9.1.x . Para versiones posteriores (acutalmente la 2.9.8l) descargar el instalador de http://code.google.com/p/php-syslog-ng/

Configuración del syslog-ng:

Hay que modificar el archivo /etc/syslog-ng/syslog-ng.conf agregando la siguiente linea de destino:

destination d_mysql {
pipe(«/var/log/mysql.pipe»
template(«INSERT INTO logs (host, facility, priority, level, tag, datetime, program, msg) VALUES ( ‘$HOST’, ‘$FACILITY’, ‘$PRIORITY’, ‘$LEVEL’, ‘$TAG’, ‘$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC’, ‘$PROGRAM’, ‘$MSG’ );\n») template-escape(yes));
};

y en las secciones src y log agregar las siguientes líneas:

source net { udp(); };

log { source(net); destination(d_mysql); };

Luego debemos crear un programa, el cual leerá el pipe generado por el syslog-ng (ver destination) y enviará los INSERTs a la base de datos mysql.

en /etc/syslog-ng/syslog2mysql.sh escribimos:

#!/bin/bash

if [ ! -e /var/log/mysql.pipe ]
then
mkfifo /var/log/mysql.pipe
fi
while [ -e /var/log/mysql.pipe ]
do
mysql -u mysqlfeeder –password=miPassWord syslog < /var/log/mysql.pipe >/dev/null
done

Y le damos permiso de ejecución:

chmod +x /etc/syslog-ng/syslog2mysql.sh

Recordar agregar un usuario mysqlfeeder con permiso de INSERT para la base syslog.

Descomprimimos el phpsyslog-ng en /usr/share/syslog-ng y agregamos un vhost en el apache (sino se puede descomprimir en el /var/www y acceder con http://127.0.0.1/)

Dentro de /install tendremos una serie de pantallas que nos iran llevando por la instalación típica.

Instalación del cliente MS Windows:

Sencillamente descargamos el instalados del NTsyslog y lo instalamos en el sistema a monitorear. El servidor se define en la siguiente clave de registro:

[HKEY_LOCAL_MACHINE\SOFTWARE\SaberNet]»Syslog»=»IP-Server_Syslog-NG»

Mediante el acceso directo generado se puede ararncar/parar el servicio, y configurar que logs serán enviados a nuestro servidor.

Instalación del cliente Linux

Despues de instalar (apt-get nuevamente) el syslog-ng, solo debemos agregar las siguientes lineas al archivo de configuración:

destination dest_server0102{udp(«syslog-ng.midominio.com» port(514));};
log { source(s_all); destination(dest_server0102); };

[1] Instalacion vía el comando apt-get
[2] http://code.google.com/p/php-syslog-ng/
[3] http://ntsyslog.sourceforge.net/

>Existen varios chequeos que se pueden realizar vía snmp con Nagios (check_snmp), a continuación describo los dos que por ahora estoy usando:

Chequeo remoto de espacio en disco:
Si tenemos la configuración básica implementada del snmpd en el servidor remoto, lo que resta es modificar una línea donde indicaremos el path a verificar y a partir de cuanto espacio libre envía un mensaje de error.

en el archivo /etc/snmp/snmpd.conf hay que agregar la siguiente línea:

disk / 5%

que indica el path (/) y el porcentaje de espacio mínimo libre.

Hay que reiniciar el servici:

pablo@server1:/# /etc/init.d/snmpd restart

Esto se puede verificar mediante el comando snmpwalk de la siguiente manera:

pablo@client1:/# snmpwalk -v 1 -c public ip_server_remoto .1.3.6.1.4.1.2021 | grep dskErrorFlag

UCD-SNMP-MIB::dskErrorFlag.1 = INTEGER: noError(0)

el cual tendría un 1 como salida si el espacio libre es menor al 5%

Para probar el plugin del nagios se puede ejecutar directamente desde la línea de comandos:

root@nagios:/# /usr/lib/nagios/plugins/check_snmp -H server1 -C public -o .1.3.6.1.4.1.2021.9.1.7.1,.1.3.6.1.4.1.2021.9.1.9.1 -w 80:,:80 -c 90:,:90 -u ‘kB free (‘,’% used)’ -l ‘disk space’
disk space OK – 35602364 kB free ( 6 % used) | iso.3.6.1.4.1.2021.9.1.7.1=35602364 iso.3.6.1.4.1.2021.9.1.9.1=6

Para agregarlo a la configuración definitiva, obviamente editamos el .cfg de la máquina a monitorear y agregamos el servicio con los paramentros: Arg1=comunidad
Arg2=disco
Arg3=valorWarning
Arg4=valorWarning
Arg5=valorCritical
Arg6=valorCritical

define service{
use generic-service
host_name server1
service_description Disco1
check_command snmp_disk!public!1!70!70!80!80
notification_period 24×7
}

El próximo valor que chequearemos remotamente es la carga de CPU:

define service{
use generic-service
host_name server1
service_description CPU
check_command snmp_load!public!80!90
notification_period 24×7
}

No olvidemos repasar como configurar el snmpd en los equipos a monitorear

http://pablosarubbi.blogspot.com/2008/12/configuracion-de-snmpd-en-ubuntu.html

Suerte!

>Primeramente debemos conocer el uuid de la máquina a la cuál le queremos modificar el orden de arranque. Esto se puede verificar con el comando xe vm-list

[root@xenServer /]# xe vm-list
uuid ( RO) : 1f84380f-d6a0-0657-02b6-2474b679efcd
name-label ( RW): vmXen01
power-state ( RO): running

uuid ( RO) : 791832b0-c621-b210-b986-a453ae8054e9
name-label ( RW): vmXen02
power-state ( RO): running

El parámetro que queremos modificar es «HVM-boot-policy» al cuál lo setearemos con «BIOS order». Con el comando siguiente verificamos la condición actual es:

[root@xenServer /]# xe vm-param-list uuid=791832b0-c621-b210-b986-a453ae8054e9

uuid ( RO) : 791832b0-c621-b210-b986-a453ae8054e9
name-label ( RW): vmXen02
name-description ( RW): Servidor Genérico 03
user-version ( RW): 1
.
.
.
HVM-boot-policy ( RW):
HVM-boot-params (MRW): order: dc
.
.
.

Ahora si definimos ese valor para dicha clave:

[root@xenServer /]# xe vm-param-set HVM-boot-policy=»BIOS order» uuid=791832b0-c621-b210-b986-a453ae8054e9

Y verificamos el resultado:

[root@xenServer /]# xe vm-param-list uuid=791832b0-c621-b210-b986-a453ae8054e9

uuid ( RO) : 791832b0-c621-b210-b986-a453ae8054e9
name-label ( RW): vmXen02
name-description ( RW): Servidor Genérico 03
user-version ( RW): 1
.
.
.
HVM-boot-policy ( RW): BIOS order
HVM-boot-params (MRW): order: dc
.
.
.

Listo, con eso se altera el orden de buteo de nuestra máquina virtual Xen.

>

Nagios2 es una aplicación open source que verifica el estado de los hosts y servicios especificados, y posee la capacidad de alertar (ya sea en forma gráfica, sonora, mediante mails al adminsitrador, sms, o incluso un sistema de desarrollo propio) cuando el comportamiento no sea el adecuado y cuando el mismo retorne a su estado normal.







Instalación
El método de instalación que se utilizó en este caso fué mediante el comando apt-get (disponible en las versiones de Linux derivadas de Debian), que nos brinda la versión 2.9-1 la cual hemos testeado, analizado, modificado y usado desde hace más de un año. Desde el sitio oficial, http://www.nagios.org, se encuentran disponibles los fuentes de la versión estable 3.0, a partir de mediados de marzo de este año, para c
ompilar1. Al igual que el resto de las aplicaciones, los archivos de configuración de nagios se encuentran disponibles en /etc/nagios2, donde como primera instancia se puede verificar la configuración del servidor web (Apache 2.x), dentro del archivo /etc/nagios2/apache2.conf. Para ejecutar el cliente se abre desde un explorador web la dirección http://localhost/nagios2 . Dicha url está protegida por el servidor web. Para crear el usuario con permisos se emplea el comando htpasswd de la siguiente manera:

root@pablo-laptop:/etc/nagios2# htpasswd -c /etc/nagios2/htpasswd.users nagiosadmin
New password: XXXXXXXX

Re-type new password: XXXXXXXX

Adding password for user nagiosadmin
root@pablo-laptop:/

Durante la instalación se crearon algunos directorios donde se ubican los principales componentes del nagios2:

  • /etc/nagios2: Archivos de configuración de la aplicación.
  • /var/log/nagios2: Logs de la aplicación.
  • /usr/sbin/nagios2: Binarios de la aplicación.
  • /etc/nagios-plugins/config: Archivos que definen los plugins de nagios2.
  • /usr/lib/nagios/plugins: Comandos que son utilizados por los plugins de nagios2.


Configuración
Los archivos de configuración del monitoreo en sí se enuentran en el directorio /etc/nagios2/conf.d/ y es allí donde se establecen los parámetros de qué hosts y servicios se verificarán, en qué período de tiempo, a quién dar aviso y de qué manera.

Los principales objetos que maneja nagios2 se enumeran a continuación:

host: Unidades físicas como servidores, routers y firewalls.
# Generic host definition template
define host{
name generic-host ; The name of this host

template – referenced in other host definitions, used for template recursion/res
olution
notifications_enabled 1 ; Host notifications are enabled
event_handler_enabled 1 ; Host event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information acro
ss program restarts
retain_nonstatus_information 1 ; Retain non-status information
across program restarts
register 0 ; DONT REGISTER THIS DEFINITION
– ITS NOT A REAL HOST, JUST A TEMPLATE!
}

define host{
use generic-host
host_name windows2003
alias NT 2003 Server

address 192.168.0.10
check_command check-host-alive
contact_groups nt-admins
max_check_attempts 10
notification_interval 480
notification_period 24×7
notification_options d,u,r
}

hostgroup: Colecciones de hosts que generalmente tienen alguna característica en común como por ejemplo la ubicación.
define hostgroup{
hostgroup_name winservers
alias Windows Servers
members windows2003,windows2000
}

service: Servicios que corren en los hosts que pueden incluir tanto servicios en sí como SMTP o HTTP, o metricas como espacio en disco o uso de memoria.
define service{
host_name paginac,paginag
service_description PING
is_volatile 0
check_period 24×7
max_check_attempts 4
normal_check_interval 5
retry_check_interval 1
contact_groups web-admins

notification_interval 240
notification_period 24×7
notification_options c,r
check_command check_ping!1050.0,30%!1550.0,60%
}

servicegroup: Al igual que los grupos de host, son colecciones de servicios que poseen alguna característica en común.
define servicegroup{
servicegroup_name pingservices
alias Ping Services
members paginac,Ping Service,paginag,Ping Service,switch,Ping Service
}

contact: Personas u objetos que pueden ser contactados durante un determinado evento.
define contact{
contact_name pablo
alias Nagios Super Admin
contactgroups nt-admins ;podemos agregar desde aquí los grupos
service_notification_period 24×7
host_notification_period 24×7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email pablo@saru.com.ar
}

contactgroup: Colección de contactos que poseen determinada característica en común, como por ejemplo la consultora responsable del host o servic io que se verifica.
# ‘network-admins’ contact group definition
define contactgroup{
contactgroup_name network-admins
alias Network Administrators
members pablo
}

timeperiod: Definición de una ventana de tiempo, por ejemplo el tiempo de trabajo en horas (7×24, 8horas, lun-vie, etc.).
define timeperiod{
timeperiod_name workhours
alias Standard Work Hours
monday 09:00-17:00
tuesday 09:00-17:00
wednesday 09:00-17:00
thursday 09:00-17:00
friday 09:00-17:00
}

command: Comando que puede ser usado durante el proceso de chequeo, como por ejemplo el comando ping utilizado para verificar es estatus de un host.
hostextinfo: Presenta información extendida que se mostrará en el cliente como decripción detallada de un host.
define hostextinfo{
hostgroup_name debian-servers
notes Debian GNU/Linux servers
notes_url http://webserver.localhost.localdomain/hostinfo.pl?host=netware1
icon_image base/debian.png
icon_image_alt Debian GNU/Linux
vrml_image debian.png
statusmap_image base/debian.gd2
}

serviceextinfo: Presenta información extendida que se mostrará en el cliente como decripción detallada de un servicio.

Durante la instalación por defecto se crean archivos de configuración genéricos que luego se pueden ir incrementando y detallando a medida que se recolecta información de la red, pero lo que realmente hace poderoso este sistema es la colección de pluggins que lo componen.

Plugins
En este apartado se definen y ejemplifican los plugins más utilizados, pero para ello es necesario marcar la diferencia entre plugins de nagios2 y comandos. Los plugins de nagios se definen en /etc/nagios-plugins/config y son archivos similares a los que se describieron en el apartado 2.2.4.2 de Configuración, donde mantienen una estructura determinada con un nombre que los define y una línea de comando que se ejecuta. El listado original es el siguiente, agrupados por la definición de comandos :

root@pablo-laptop:/etc/nagios-plugins/config# ls
apt.cfg disk.cfg dummy.cfg ftp.cfg http.cfg load.cfg mysql.cfg nt.cfg ping.cfg real.cfg ssh.cfg users.cfg

breeze.cfg disk-smb.cfg flex
lm.cfg games.cfg ifstatus.cfg mail.cfg netware.cfg ntp.cfg procs.cfg rpc-nfs.cfg tcp_udp.cfg vsz.cfg
dhcp.cfg dns.cfg fping.cfg hppjd.cfg ldap.cfg mrtg.cfg news.cfg pgsql.cfg radius.cfg snmp.cfg telnet.cfg
root@pablo-laptop:/etc/nagios-plugins/config#

Y como ejemplo se muestra un resúmen del archivo /etc/nagios-plugins/config/ping.cfg que contiene la descripción de los plugins que verifican disponibilidad mediante este comando.

root@pablo-laptop:# cat /etc/nagios -plugins/config/ping.cfg
# ‘check_ping’ command definition
define command{

command_name check_ping
command_line /usr/lib/nagios/plugins/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$
}

# ‘check-host-alive’ command definition
define command{
command_name check-host-alive
command_line /usr/lib/nagios/plugins/check_ping -H $HOSTADDRESS$ -w 5000,100% -c 5000,100% -p 1
}

# ‘check-printer-alive’ command definition
define command{
command_name check-printer-alive
command_line /usr/lib/nagios/plugins/check_ping -H $HOSTADDRESS$ -w 5000,100% -c 5000,100% -p 1
}

# ‘check-switch-alive’ command definition
define command{
command_name check-switch-alive
command_line /usr/lib/nagios/plugi
ns/check_ping $HOSTADDRESS$ -w 5000,100% -c 5000,100% -p 1
}

# ‘check-router-alive’ command definition
define command{
command_name check-router-alive
command_line /usr/lib/nagios/plugins/check_ping -H $HOSTADDRESS$ -w 5000,100% -c 5000,100% -p 1
}

root@pablo-laptop:#

Como se mencionó anteriormente, estos plugins utilizan los comandos que se encuentran en el directorio /usr/lib/nagios/plugins y se enumeran a continuación:

root@pablo-laptop:# ls /usr/lib/nagios/plugins
check_apt check_disk check_ftp check_imap check_mailq check_nntps check_ping check_simap check_tcp urlize
check_bgpstate check_disk_smb check_game check_ircd check_mrtg check_nt check_pop check_smtp check_time utils.pm

check_b
reeze check_dns check_hpjd check_jabber check_mrtgtraf check_ntp check_procs check_snmp check_udp utils.sh
check_by_ssh check_dummy check_http check_ldap check_mysql check_nwstat check_radius check_spop check_ups
check_clamd check_file_age check_icmp check_ldaps check_mysql_query check_oracle check_real check_ssh check_users
check_dhcp check_flexlm check_ifoperstatus check_load check_nagios check_overcr check_rpc check_ssmtp check_wave
check_dig check_fping check_ifstatus check_log check_nntp check_pgsql check_sensors check_swap negate
root@pablo-laptop:#


Los mismos pueden ser ejecutados directamente desde la línea de comandos para su prueba inicial y posterior implementacion en un nuevo plugin.

root@pablo-laptop:# /usr/lib/nagios/plugin/check_ping
check_ping: Could not parse arguments
Usage:check_ping -H -w ,% -c ,%
[-p packets] [-t timeout] [-4|-6]
root@pablo-laptop:#

Ejecución:
Para un ambiente de producción, es recomend
able tener instalado, configurado y en ejecución constante, el nagios desde un host dedicado que se encuentre ubicado cercano a la posición del administrador de red, así ante algún evento, este lo identifica al instante mediante la comunicación en pantalla y los avisos sonoros.
Es una buena práctica armar un mapa de red con la arquitectura propia donde se ubican los hosts en el mismo orden que se encuentran físicamente para una mejor interpretación del estado del mismo.

Conclusión
Una de las principales necesidades para reaccionar en forma rápida y así contrarestar a tiempo posibles ataques es estar informado sobre la situación actual del sistema en su conjunto, es por eso que durante este capítulo se intentaron plantear diferentes herramientas que se encuentran disponibles para verificación de estados y monitoreo de hosts y servicios, de diferentes vistas y altamente configurables.

Stop SOPA