[Jderobot-admin] Caída del servidor del finde pasado

[Borja Mon Serrano]

> Me alegra saberlo. ¿Al final habéis tirado de paquetes oficiales? ¿Era
> perl el que impedía que se instalaran cosas?
>
> Me interesa saber cómo se ha arreglado si no es molestia.
>

Ah, si no lo he explicado más es porque daba por supuesto que lo sabías,
creía que te lo había dicho José María. El caso está en que en el .bashrc
se estaba exportando la librería de perl (la instalada en /root) y era de
ahí de donde cogía sus funciones la libc, que era la que estaba dando
problemas de dependencias porque, además, te decía que una versión de libc
dependeía de una versión anterior de libcbin que a su vez dependía de
libc-dev y ésta, a su vez, de la última versión de libc; es decir, un
círculo vicioso que no había manera de meterle mano. Lo que se hizo fue
comentar las líneas del .bashrc que hacían referencia a perl y, a partir de
ahí, se pudo instalar correctamente libc para posteriormente poder
actualizar el sistema. Así que ahora ya tenemos el sistema actualizado y,
de momento, parece que tira bien sin esa instalación de perl. No se ha
eliminado todavía por si las moscas, aunque si en las próximas semanas
vemos que no hay ningún problema en quitarlas se quitarán. Lo que sí que es
cierto es que ahora mismo no funciona el bugzilla, pero no sé si es por
esto de perl o no, ya que no lo he mirado nunca antes de este problema.


> Es la primera noticia que tengo de eso y no creo que sea cierto. Tengo en
> producción cinco servidores zabbix (tres de ellos en monitorización
> distribuida) y todos ellos llevan agentes ejecutándose en la misma máquina
> con el mismo usuario (zabbix).
>

No es algo que me invente, viene en el propio manual. Lo cito
explícitamente, pero lo puedes obtener de [1]:

"If Zabbix server<http://www.zabbix.com/documentation/2.0/manual/concepts/server>
 and agent <http://www.zabbix.com/documentation/2.0/manual/concepts/agent> are
run on the same machine it is recommended to use a different user for
running the server than for running the agent. Otherwise, if both are run
as the same user, the agent can access the server configuration file and
any Admin level user in Zabbix can quite easily retrieve, for example, the
database password."

Y justamente debajo de eso tienes un cartel que pone:

"Running Zabbix as root, bin, or any other account with special rights is a
security risk."

De todas formas, si dices que realmente no hay problema, adelante con ello
;-)

En debian la instalación es muy sencilla, sobre todo si se usa dbconfig,
> crea automáticamente un usuario en la base de datos para la monitorización,
> crea la base de datos, realiza la importación de la plantilla inicial, etc.
> Luego hay que instalar el frontal php. Todo está disponible en forma de
> paquetes en los repositorios oficiales.
>

Está bien saberlo, porque me lo he bajado para compilarlo e instalarlo...


> Las plantillas que vienen en zabbix son muy genéricas y, como ocurre en
> casi todas las plataformas de monitorización, hay cosas que no sirve para
> nada monitorizar o saltarán alertas por no estar instalados servicios, pero
> nada que no se pueda arreglar desactivando el monitor o eliminándolo de la
> plantilla.
>
> Por cierto, en mi empresa no usamos ninguna plantilla "por defecto", al
> final hemos tirado de plantillas propias. Con 10 o 20 máquinas no importa
> si monitorizas más de lo que necesitas, pero con casi 1000 máquinas la base
> de datos es el mayor cuello de botella de la monitorización.
>
> Ojito con eso si el servidor zabbix va a estar en una máquina donde haya
> más cosas funcionando y va a monitorizar muchos equipos, escribir 5 o 10
> registros por segundo no ralentiza nada, pero si se empiezan a meter
> máquinas a monitorizar, posiblemente escribir 100 o 200 registros por
> segundo empiece a comerle tiempo de I/O a otros procesos (servidor web, ftp
> o svn) si los discos no son rápidos.
>

En un principio la monitorización sería solamente para jderobot, pero si no
es así que me corrija José María.


> Por último, MUY IMPORTANTE, activar innodb_file_per_table y reiniciar
> mysql ANTES de comenzar la instalación del servidor zabbix.
>

Me lo apunto.


> Si los espacios de tablas (tablespaces) se dejan en un archivo único,
> ibdata1, éste podrá crecer hasta ocupar varios gigas conforme pasen los
> meses (si no se modifican las plantillas para que en vez de guardar
> históricos detallados tres meses y tendencias durante un año) y luego no se
> podrá recuperar ese espacio ni borrando la base de datos (y no se podrá
> borrar el archivo sin perder los tablespaces del resto de tablas de las
> bases de datos existentes).
>

¿Cómo es esto? ¿Se traga un agujero negro el espacio? ¿Cómo hay que hacerlo
entonces? Es que no he llegado a comprender lo del primer paréntesis, lo
mismo es por las horas ya, jeje.


> Lo que no entiendo es qué hace aún un servidor en PHP4... desde debian
> etch viene por defecto PHP5 e incluso en sarge ya se podía elegir entre
> PHP4 o 5. ¿No habéis pensado en migrar a PHP5? Me da miedo preguntar qué
> versión de debian estáis usando :S :)
>
> Supongo que valdrá, basta con que pruebes la siguiente línea de comandos...
>
> find /var/lib/php4/ -depth -mindepth 1 -maxdepth 1 \
>       -type f -cmin +$(/usr/lib/php4/maxlifetime)
>
> ... y veas si aparecen archivos de sesión de PHP. Si no funciona hay que
> localizar dónde se guarda el archivo maxlifetime, y dónde se guardan los
> archivos de sesión para adaptar la línea a las rutas correctas.
>

Supongo que si está por ahí php4 será porque se instaló hace bastante
tiempo la Debian en el servidor y poco a poco se ha ido actualizando sin
borrar php4, pero es algo que no puedo confirmar dado que solo llevo aquí
desde octubre.

Me lo apunto como tarea también.

Un saludo,

Borja.

[1] - http://www.zabbix.com/documentation/2.0/manual/installation
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jderobot-admin/attachments/20121108/7e270344/attachment-0001.htm