Você está na página 1de 94

Zimbra: Una vez instalado, qu hago?

(Administrador)
Normalmente cuando acabamos de instalar un servidor de Zimbra, nos surgen dudas, de cmo
hemos de ajustar nuestro sistema a nuestras necesidades de una manera ordenada y lgica.
Con esto no quiere decir que esta sea la configuracin ideal, pero nos puede ayudar ajustando
los parmetros a nuestras necesidades a implementar un sistema de Zimbra una vez acabada la
instalacin.
Lo primero que necesitaremos, es saber tres datos fundamentales:

Nombre FQDN del servidor. Por ejemplo: zimbra.ilba.cat.


HELO que le asignaremos a nuestro servidor: helo.ilba.cat
Los logos para hacer el branding, en caso de ser una Network Edition
Una direccin de correo electrnico donde enviar los logs, reports, etc.: Ejemplo:
oscarmash@gmail.com

Timestamp

Ajustaremos el timestamp en 60 minutos, para ver los ultimos logins


[syntax type=php+zmprov mcf zimbraLastLogonTimestampFrequency 60m[/syntax]
Admin Console de Zimbra Collaboration, en concreto hablamos de Home > Manage > Accounts,
cuando queremos comprobar cuando fue el ltimo Login de nuestros usuarios.

Lo normal es que el ltimo Login no nos parezca correcto, o al menos no actualizado, ya que
parece algo obsoleto, y de hecho as es, Zimbra Collaboration viene con el atributo
zimbraLastLogonTimestampFrequency por defecto en 7d (7 das), podemos cambiarlo para que
refresque con un tiempo ms prudencial y que se ajuste a nuestro entorno de trabajo, por
ejemplo 15 minutos, pero podemos ajustarlo por segundos, minutos, horas o das:
[syntax type=php+zmprov mcf zimbraLastLogonTimestampFrequency 15m[/syntax]

De esta manera, si un usuario se ha logueado los pasados 30 minutos, aparecer en nuestra


Admin Console y podremos hacer un seguimiento ms detallado de nuestros usuarios, as cmo
detectar ataques o problemas de seguridad.

Descripcin completa del atributo

<attr id="114" name="zimbraLastLogonTimestampFrequency type="duration" cardinality="single" optionalIn="globalConfig">


<globalConfigValue>7d</globalConfigValue>
<desc>how often (nnnnn[hmsd]) the zimbraLastLogonTimestamp is updated.
if set to 0, updating zimbraLastLogonTimestamp is completely disabled
</desc>
</attr>
Mail de bloqueo

Que nos enve un mail cuando se bloquee una cuenta:

[syntax type=php+zmlocalconfig -e
zimbra_swatch_notice_user=oscarmash@gmail.comzmlocalconfig -e
zimbra_swatch_ipacct_threshold=10
zmlocalconfig -e zimbra_swatch_acct_threshold=15
zmlocalconfig -e zimbra_swatch_ip_threshold=20
zmlocalconfig -e zimbra_swatch_total_threshold=60
echo >> /etc/rc.localecho sleep 1800 >> /etc/rc.local
echo su zimbra -C zmauditswatchctl start >> /etc/rc.local[/syntax]

Cabe destacar que he hecho un echo del zmauditswatchctl en el rc.local, pero es ms adecuado
meterlo en los runlevels.

Cuando nuestro sistema de Zimbra, bloquea una cuenta de correo a consecuencia de


equivocarse consecutivamente de password, ya sea por un ataque o por descuido.
Nuestro sistema bloquea la cuenta y no nos informa de lo sucedido hasta que nos llama el
usuario final. Lo que vamos a ver, es el comando zmauditswatch, el cual nos informar por
email, cuando se bloquea una cuenta de correo. Cabe destacar que esta funcionalidad no viene
habilitada por defecto en nuestros sistema de Zimbra.
Lo primero que haremos, es indicarle al sistema una direccin de correo electrnico, en la cual
se enviaran los mensajes, que nos indicaran que una de nuestras cuentas de correo ha sido
bloqueada y posteriormente, arrancaremos el dominio.

[syntax type=php+
[zimbra@zimbra ~]$ zmlocalconfig -e zimbra_swatch_notice_user=oscarmash@gmail.com
[zimbra@zimbra ~]$ zmauditswatchctl start
[zimbra@zimbra ~]$ zmauditswatchctl status
[/syntax]
Para verificar que ha arrancado sin problemas, podremos ver el log en el fichero:
/opt/zimbra/log/zmauditswatch.out

Valores por defecto que vienen por defecto son los siguientes:
[syntax type=php+
zimbra_swatch_ipacct_threshold=10
zimbra_swatch_acct_threshold=10
zimbra_swatch_ip_threshold=20
zimbra_swatch_total_threshold=100
[/syntax]

Los cuales, los podemos modificar a nuestro antojo


[syntax type=php+
[zimbra@zimbra ~]$ zmlocalconfig -e zimbra_swatch_ipacct_threshold=10
[zimbra@zimbra ~]$ zmlocalconfig -e zimbra_swatch_acct_threshold=15
[zimbra@zimbra ~]$ zmlocalconfig -e zimbra_swatch_ip_threshold=20
[zimbra@zimbra ~]$ zmlocalconfig -e zimbra_swatch_total_threshold=60
[/syntax]
A consecuencia, de que este dominio no arranca por defecto con nuestro sistema, nos
descargaremos el script de inicio. El cual lo ubicaremos en nuestro runlevel, para cuando
rebotemos el equipo, el dominio arranque de manera automtica.
[syntax type=php+
[root@zimbra ~]# cd /usr/local/src/
[root@zimbra src]# wget https://wiki.zimbra.com/images/d/d9/Zmauditswatch.tar
[root@zimbra src]# tar xvf Zmauditswatch.tar
[root@zimbra src]# cp zmauditswatch.txt /etc/rc.d/init.d/zmauditswatch
[root@zimbra src]# chmod 755 /etc/rc.d/init.d/zmauditswatch
[root@zimbra src]# systemctl enable zmauditswatch
[/syntax]

Los mensajes que nos enva el sistema indicndonos que se ha bloqueado una cuenta, estn ya
predefinidos y los podemos cambiar a nuestro antojo, siempre y cuando conservemos las
variables:

[syntax type=php+*root@zimbra ~]# cat /opt/zimbra/conf/auditswatchrc.in[/syntax]


Para verificar el funcionamiento, simplemente hemos de superar el umbral de fallos, indicado
anteriormente:

Una vez pasado el umbral, el sistema nos enviar un mail. Con un mensaje parecido al siguiente
que recibiremos, cuando nuestro sistema bloquee una cuenta de correo:
Antivirus

Deshabilitamos del sistema que nos bloquee los archivos encriptados:


[syntax type=php+zmprov mcf zimbraVirusBlockEncryptedArchive FALSE[/syntax]
Muchos administradores me preguntan sobre el funcionamiento del sistema de AntiVirus de
Zimbra. Zimbra usa todas las herramientas OpenSource del mercado y como no, para su sistema
de AntiVirus usa el ClamAV
ClamAV se actualiza automticamente cuando actualizamos la versin de Zimbra, es posible
actualizar nuestra versin de ClamAV sin tener que actualizar la versin de Zimbra, pero es
totalmente desaconsejable, ya que todos los cambios y el esfuerzo, se eliminar en cuanto
actualicemos nuestra versin de Zimbra.
Las definiciones de virus se actualizan automticamente por defecto cada dos horas como
podemos ver en el log del freshclam.log. Este valor, se puede modificar desde la administracin
de Zimbra:
En el log del fresclam, podremos observar que cada 2 horas se va actualizando las definiciones
de virus.
[root@zimbra ~]# tail -19 /opt/zimbra/log/freshclam.log

Si deseamos forzar una actualizacin de las definiciones de virus de manera manual,


simplemente lanzaremos el siguiente comando como el usuario zimbra:
[zimbra@zimbra ~]$ /opt/zimbra/clamav/bin/freshclam config-
file=/opt/zimbra/conf/freshclam.conf
Para verificar que nuestro demonio de AntiVirus est funcionando, lo podremos verificar de
la siguiente manera:

[zimbra@zimbra ~]$ zmclamdctl status


Para saber que versin de ClamAv tenemos instalada en nuestro sistema, lanzaremos el
siguiente comando:

[zimbra@zimbra ~]$ /opt/zimbra/clamav/bin/clamscan -V

Una de las opciones que a nivel personal no me gusta, es que el sistema de AntiVirus de Zimbra
por defecto bloquea los ficheros encriptados.
Esta funcionalidad, la suelo deshabilitar ya que da ms problemas que ventajas. Para poder
deshabilitarlo, podemos usar el GUI o lanzar el siguiente comando:

[zimbra@zimbra ~]$ zmprov mcf zimbraVirusBlockEncryptedArchive FALSE


Y como siempre, verificaremos que se han realizado los cambios deseados:
[zimbra@zimbra ~]$ zmprov gacf | grep -i encryptedarchive

Si por algn motivo necesitsemos deshabilitar el sistema de antivirus, realizaramos esta


operacin de la siguiente manera:

[zimbra@zimbra ~]$ zmprov ms zmhostname -zimbraServiceEnabled antivirus

Para verificar que el sistema de antivirus funciona de manera correcta, usaremos un cdigo
conocido como EICAR ( http://www.eicar.org/86-0-Intended-use.html ). Este cdigo emula un
virus y todos los sistema de AntiVirus lo detectan como tal y lo han de bloquear. Procederemos
de la siguiente manera:
Enviaremos el mail desde un servidor externo con el cdigo EICAR
Veremos que nuestro servidor de Zimbra descarta el mensaje y lo entrega al buzn del
administrador
Enviamos el cdigo EICAR desde un servidor externo contra nuestro servidor de Zimbra:
root@firewall:~# telnet 192.168.100.20 25
helo zimbra.ilba.cat
mail from: oscarmash@gmail.com
rcpt to: oscar@ilba.cat
data
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Observamos en el log lo que sucede:
[root@zimbra ~]# tail -f /var/log/maillog
Como podremos ver en el log, el mensaje es reenviado a la cuenta del administrador del
servidor. En nuestro caso admin@ilba.cat y si abrimos el buzn, podremos ver el mensaje:
IMAP / POP3 / SMTP

Permitiremos el acceso a los protocolos IMAP, POP3 y SMTP sin necesidad de usar encriptacin:

[syntax type=php]
zmprov mcf zimbraMtaTlsAuthOnly FALSE
zmprov mcf zimbraImapCleartextLoginEnabled TRUE
zmprov mcf zimbraPop3CleartextLoginEnabled TRUE
[/syntax]
Si va a ser un servidor IMAP, aumentaremos los threads y las conexiones
[syntax type=php]
zmprov ms zmhostname zimbraImapNumThreads 500
zmprov ms zmhostname zimbraImapMaxConnections 500
[/syntax]

En ocasiones, si todos nuestros clientes usan el protocolo IMAP para poder gestionar su correo
en una plataforma de Zimbra, podramos llegar a encontrarnos el siguiente error:
[syntax type=php+
2014-09-17 17:37:38,638 WARN [ImapServer-93] [] imap Dropping connection (max
connections exceeded)
2014-09-17 17:37:39,031 WARN [ImapServer-91] [] imap Dropping connection (max
connections exceeded)
2014-09-17 17:39:03,679 WARN [ImapServer-95] [] imap Dropping connection (max
connections exceeded)
2014-09-17 17:39:25,514 WARN [ImapServer-91] [] imap Dropping connection (max
connections exceeded)
[/syntax]

Y los outlooks, nos muestran el siguiente error:


El problema radica, en que cada cliente de correo electrnico que se conecta a nuestro servidor
Zimbra mediante el protocol IMAP, usa una conexin. Pero el cliente puede llegar a abrir ms de
un thread por conexin. A consecuencia de este planteamiento, lo norma para solventar este
tipo de errores, es aumentar los dos valores.
Por defecto, cuando instalamos nuestro servidor de Zimbra, viene con los siguientes valores por
defecto:
[syntax type=php+
Last login: Tue Sep 16 18:29:08 2014 from 10.222.0.15
root@zcs:~# su zimbra
zimbra@zcs:~$ zmprov gs zmhostname zimbraImapNumThreads
zimbra@zcs:~$ zmprov gs zmhostname zimbraImapMaxConnections
[/syntax]
Aumentamos el valor, de una manera lgica. Por ejemplo en 500:
[syntax type=php]
zimbra@zcs:~$ zmprov ms zmhostname zimbraImapNumThreads 500
zimbra@zcs:~$ zmprov ms zmhostname zimbraImapMaxConnections 500
[/syntax]

Reiniciamos los servicios de Zimbra y listo.


Logs del servidor

Reenviaremos todos los logs del servidor a una cuenta en concreto:

[syntax type=php+
zmprov ma admin@ilba.cat zimbraPrefMailForwardingAddress oscarmash@gmail.com
zmprov ma admin@ilba.cat zimbraFeatureMailForwardingEnabled FALSE
[/syntax]

HELO

Cambiaremos el HELO del servidor:

[syntax type=php+
zmlocalconfig -e postfix_smtpd_banner=helo.ilba.cat NO UCE ESMTP
postconf -e smtpd_banner=helo.ilba.cat NO UCE ESMTP
zmprov mcf zimbraMtaMyHostname helo.ilba.cat
[/syntax]

Public service hostname

Cambiaremos los accesos directos de los diferentes componentes de Zimbra:

[syntax type=php+zmprov mcf zimbraPublicServiceHostname zimbra.ilba.cat[/syntax]


Tamao de mensajes

Ajustaremos los tamaos de los mensajes que acepta nuestro sistema:

[syntax type=php+
zmprov mcf zimbraMtaMaxMessageSize 38912000
zmprov mcf zimbraFileUploadMaxSize 37888000000
[/syntax]

Habitualmente, cuando configuramos un servidor de Zimbra, pocas veces nos paramos a pensar
en los tamaos de upload y de MTA que nos vienen por defecto, una vez instalado nuestro
servidor de Zimbra. Estos valores, los podemos ver de una forma rpida y sencilla, por consola o
por GUI.

<i>root@zcs:~# su - zimbra
zimbra@zcs:~$ zmprov gacf | grep zimbraMtaMaxMessageSize
zimbraMtaMaxMessageSize: 38912000
zimbra@zcs:~$ zmprov gacf | grep zimbraFileUploadMaxSize
zimbraFileUploadMaxSize: 37888000000
</i>
Los parmetros mostrados, son almacenados por el LDAP interno de Zimbra y posteriormente
propagados por el zmmtaconfig. Otro dato importante, es que los valores que le indicamos por
consola son en bit (b) y por la GUI son en kilobyte (KB). En la versin 8 de Zimbra, existen ms
parmetros de gestin de tamaos como por ejemplo: zimbraFileUploadMaxSizePerFile, casi
todos ellos solamente se pueden modificar desde la consola.

<i><b>zimbraMtaMaxMessageSize</b></i>

Es el tamao mximo que nuestro servidor SMTP (en nuestro caso el Postfix) va a aceptar. Eso
quiere decir, que si nos envan desde una cuenta externa un mensaje que se superior al valor
que tenemos indicado, el servidor le retornar un mensaje de error.
Se puede modificar por consola:

<i>root@zcs:~# su - zimbra
zimbra@zcs:~$ zmprov modifyConfig zimbraMtaMaxMessageSize 38912000
zimbra@zcs:~$ postfix reload</i>
Se puede modificar por GUI y la opcin es: Maximum message size (KB)

<i><b>zimbraFileUploadMaxSize</b></i>
Es el tamao mximo que podemos subir archivos a nuestro servidor de Zimbra,
incluyendo: maletn, calendarios, mensajes, etc. . Esto os aconsejo dejarlo a un valor alto,
sobre todo cuando se estn haciendo migraciones ya que nos podra dar problemas.
Se puede modificar por consola:
<i>root@zcs:~# su - zimbra
zimbra@zcs:~$ zmprov modifyConfig zimbraFileUploadMaxSize 37888000000
zimbra@zcs:~$ postfix reload</i>

Se puede modifica por GUI, en la opcin: Maximum size of an uploaded file for Briefcase, Email
messages, Calendar appointments and Tasks (KB):
Conexiones web

Permitiremos el acceso a nuestro servidor a ambos tipos de conexiones, tanto HTTP como
HTTPS:

[syntax type=php+zmtlsctl both[/syntax]

Cuando el Score importa, SPF, DKIM, rDNS

Para llegar a todos los destinatarios, aunque estn detrs de una MTA estricta, necesitaremos
cumplir varios estndares de seguridad, por ejemplo deberemos tener activo y bien
configurado:

SPF
SenderID
DKIM
rDNS

Una vez que tenemos nuestro Zimbra Collaboration instalado, podemos enviar un email a Mail
Tester, y comprobar nuestro Score.
Certificado de Seguridad SSL

Hace unos aos, tener un certificado de seguridad quedaba relegado para grandes Compaas, o
negocios online donde hubiera un carrito de la compra, con los precios actuales de los SSL,
desde 9 dlares al ao, securizar nuestro Zimbra Collaboration es una recomendacin bsica.
Las instrucciones para la correcta generacin e instalacin de un SSL las encontramos en el
siguiente Wiki https://wiki.zimbra.com/wiki/Jdelacruz-Notes#Single-
Node_Commercial_Certificate

Controlando los Logs

No es ningn misterio saber que cuando Zimbra Collaboration tiene algn problema, o sufrimos
un ataque, o un problema de recursos, la informacin estar en los Logs, es por ello que una
buena prctica una vez tenemos nuestro Zimbra Collaboration, es centralizar los Logs en un
appliance que sea capaz de mostrarnos esos Logs de una forma ms sencilla, desgranada y
depurada, adems con opcin de buscar en cierto rango de tiempo.
Zimbra: Logs centralizados con VMware vRealize Log Insight

1.- Qu es VMware vRealize Log Insight?


2.- Zimbra con VMware vRealize Log Insight usando Syslog
2.1.- Configuracin en nuestro servidor Zimbra
3.- Monitorizando los Logs de nuestro nuevo Zimbra Server en VMware vRealize Log Insight
4.- Trabajando con VMware vRealize Log Insight, ayuda al instante
5.- Zimbra con VMware vRealize Log Insight usando Agente
5.1.- Instalacin del Agente de VMware vRealize Log Insight en nuestro servidor Zimbra
5.2.- Configuracin en nuestro Agente de VMware vRealize Log Insight
6.- Trabajando con VMware vRealize Log Insight, ayuda al instante II
7.- Content Packs
8.- Conclusin
Qu es VMware vRealize Log Insight?

Antes se llamaba vCenter Log Insight, VMware vRealize Log Insight ofrece gestin de Logs en
tiempo real para entornos VMware, o cualquier otro aparato, servidor, etc que le configuremos,
con agrupacin basada en el aprendizaje inteligente del propio appliance, bsqueda de alto
rendimiento y una mejor resolucin de problemas de nuestros entornos virtuales, Zimbra, etc.
Zimbra con VMware vRealize Log Insight usando Syslog

En esta configuracin vamos a aprender a configurar nuestro Zimbra para que mande mediante
Syslog los Logs de Zimbra. Es un primer paso y el ms bsico de los dos que configuraremos,
pero tambin el ms sencillo de implementar.

Configuracin en nuestro servidor Zimbra

Lo primero que haremos ser editar la configuracin de Rsyslog de nuestro servidor de Zimbra,
deberemos editar el fichero de configuracin ubicado en /etc/rsyslog.conf y dejarlo con los
siguientes valores:

vi /etc/rsyslog.conf

Es importante que estemos atentos al cambio e introduzcamos la IP o hostname de nuestro


servidor de VMware vRealize Log Insight, as cmo estar seguros que estamos usando el puerto
514 por UDP, todo esto viene configurado por defecto en el VMware vRealize Log Insight, as
que si no hemos hecho cambios todo funcionar a la primera.

# provides UDP syslog reception


$ModLoad imudp
$UDPServerRun 514
*.* @IPorHOSTNAMELOGINSIGHT:514
Lo siguiente ser lanzar un reinicio al servicio de Rsyslog:

etc/init.d/rsyslog restart

Una manera muy buena de probar que nuestro VMware vRealize Log Insight recibe mensajes
desde nuestro Zimbra server es lanzar una traza por UDP:

nc -u IPorHOSTNAMELOGINSIGHT 514

Escribe aqu tu prueba

Y presionar CTRL+C, veremos algo as:


Y si nos vamos a nuestro VMware vRealize Log Insight, en la pestaa de Interactive Analytics
veremos lo siguiente, esto es que todo funciona perfecto:

Monitorizando los Logs de nuestro nuevo Zimbra Server en VMware vRealize Log Insight

Es el turno de loguearnos a nuestro VMware vRealize Log Insight y ver que informacin somos
capaces de sacar, etc. Una vez hemos hecho login, nos iremos hasta la pestaa de Interactive
Analytics que es donde podremos jugar mucho ms.
En esta pestaa, tenemos adems varias sub-pestaas con las que podemos ver los Logs de
maneras diferentes.
Por ejemplo, cmo Field Table, podemos ver los Logs de manera desgranada y ordenarlo
adems por Host, por App, etc, muy til esta pestaa.
Y tambin por tipos de Evento, nada especial en esta vista, pero no deja de ser interesante y nos
puede servir en el futuro.
Trabajando con VMware vRealize Log Insight, ayuda al instante

Pero la verdadera funcionalidad de un sistema centralizado de Logs es cuando necesitamos


buscar un dato porque tenemos un problema, o un fallo, o un ataque, por ejemplo, una de mis
bsquedas ms normales es ver los usuarios logeados a Zimbra, para detectar ataques o login
indebidos. En Linux el comando suele ser as:

cat /var/log/zimbra.log | grep sasl_method

Pero en nuestro sistema centralizado de Logs, puedo chequear al mismo tiempo en todos mis
servers Zimbra, o solamente en los que yo desee, etc. Lo que har ser en el campo de
bsqueda introducir sasl y el propio sistema me autocompletar con sasl_method, esto sucede
con todas las cadenas que busquemos, esto es simplemente maravilloso.
Aqu el resultado del comando lanzado, bueno en mi caso solamente estoy yo, que es mi
entorno de pruebas.
Podemos adems filtrar por el Source, que ser el Servidor Zimbra, y as tener solamente los
impactos y logins a ese servidor en concreto.
Y de esta manera, podemos aadir a nuestro Dashboard personalizado la bsqueda con
sasl_method y con el source nuestro server Zimbra, uno de ellos al menos.
Podremos elegir el nombre para el complemento que aadiremos a nuestro Dashboard, en mi
caso he puesto User login Dashboard.
Y as es cmo se ver nuestro Dashboard 1, con la grfica total de Eventos, as cmo el nuevo
Widget llamado User login Dashboard, con la cantidad de usuarios logueados por tiempo, un
dato muy til para detectar picos de trabajo o cuellos de botella, o ataques.
Zimbra con VMware vRealize Log Insight usando Agente

Como todos los Softwares del mercado, siempre que hay un agente de por medio, encontramos
una mayor integracin y muchas ms opciones. Seguramente con la configuracin de arriba os
habis quedado un poco fros y queris aadir ms logs, especialmente el todopoderoso
mailbox.log de Zimbra.

Instalacin del Agente de VMware vRealize Log Insight en nuestro servidor Zimbra

Los Agentes podemos encontrarlos en la siguiente URL:


https://YOURVREALIZELOGINSIGHTSERVER/admin/agents, veremos algo as:
Si ya tuviramos uno o varios Agentes instalados, entonces veremos algo as:
Descargaremos el fichero de Agente para Linux en nuestro servidor. Y lo instalaremos de la
siguiente manera
sudo dpkg deb -i VMware-Log-Insight-Agent_2.5.0-2347850.deb

Y el proceso de instalacin mostrar algo cmo lo siguiente:


Preparing to unpack VMware-Log-Insight-Agent_2.5.0-2347850.deb ...
Unpacking vmware-log-insight-agent (2.5.0-2347850) ...
Setting up vmware-log-insight-agent (2.5.0-2347850) ...
Adding system startup for /etc/init.d/liagentd ...
/etc/rc0.d/K20liagentd -&gt; ../init.d/liagentd
/etc/rc1.d/K20liagentd -&gt; ../init.d/liagentd
/etc/rc6.d/K20liagentd -&gt; ../init.d/liagentd
/etc/rc2.d/S20liagentd -&gt; ../init.d/liagentd
/etc/rc3.d/S20liagentd -&gt; ../init.d/liagentd
/etc/rc4.d/S20liagentd -&gt; ../init.d/liagentd
/etc/rc5.d/S20liagentd -&gt; ../init.d/liagentd
Starting VMware Log Insight Agent: *
Installation completed. Please edit /var/lib/loginsight-agent/liagent.ini to configure the agent.
For online documentation please visit:
http://pubs.vmware.com/log-insight-25/index.jsp?topic=%2Fcom.vmware.log-
insight.administration.doc%2FGUID-DB4A27CF-BDA7-443F-94FB-AB9097AD8008.html
Processing triggers for ureadahead (0.100.0-16) ...
ureadahead will be reprofiled on next reboot
Configuracin en nuestro Agente de VMware vRealize Log Insight

La configuracin del agente no es nada complicada, simplemente deberemos editar el fichero


/var/lib/loginsight-agent/liagent.ini y aadir los logs que queremos monitorizar, por defecto el
Agente trae syslog y messages.log, que podemos eliminar si nos reporta demasiada informacin
que no queremos.
Ejemplo para un servidor Zimbra Single Server:
[filelog|messages]
directory=/var/log
include=messages;messages.?

&nbsp;

[filelog|syslog]
directory=/var/log
include=syslog;syslog.?

&nbsp;

[filelog|Zimbra-Audit]
directory=/opt/zimbra/log
include=audit.log;audit.log

&nbsp;

[filelog|Zimbra-Access]
directory=/opt/zimbra/log
include=access.log;access.log*

&nbsp;

[filelog|Zimbra-Clamd]
directory=/opt/zimbra/log
include=clamd.log;clamd.log

&nbsp;

[filelog|Zimbra-EWS]
directory=/opt/zimbra/log
include=ews.log;ews.log

&nbsp;

[filelog|Zimbra-Mailbox]
directory=/opt/zimbra/log
include=mailbox.log;mailbox.log

&nbsp;

[filelog|Zimbra-MYSQL-Error]
directory=/opt/zimbra/log
include=mysql_error.log;mysql_error.log

&nbsp;

[filelog|Zimbra-Zmmailboxd]
directory=/opt/zimbra/log
include=zmmailboxd.out;zmmailboxd.out
Despus de configurar el Agente de VMware vRealize Log Insight, el propio agente empezar a
mandar informacin al servidor. Si no fuera as podemos hacer un reboot del servicio:
/etc/init.d/liagentd restart
Stopping VMware Log Insight Agent: *
Starting VMware Log Insight Agent: *

Trabajando con VMware vRealize Log Insight, ayuda al instante II

Bien, es la hora de volver a nuestro VMware vRealize Log Insight para ver que somos capaces de
visualizar con el agente instalado.
Por defecto, nos cargar el men de vSphere, pero nosotros queremos ver el General, as que
haremos Click en el men donde pone VMware vSphere y cambiaremos a General.
Y all podremos ver mucha ms informacin acerca de nuestro entorno, nuestros Hosts
Logueados, etc.
Pero sin duda, la mejor pestaa aqu es la de Agents, en ella veremos todos nuestros servidores
con el Agente instalado, y podremos como siempre autocompletar en el campo de Hostname, o
en la derecha en el primer Widget veremos el resumen de los Agentes.
Por ejemplo este es un Dashboard que he creado, le he llamado Zimbra with Agent, y he
aglutinado una grfica con todas las entradas de Log, un widget separado por los impactos de
cada Log, y un widget con la tarta por Hosts, solamente tengo uno y queda algo pobre.
Si pinchamos en alguno de los campos de las tartas, por ejemplo en el pedazo de tarta para
/opt/zimbra/log/mailbox.log y pulsamos en Interactive Analytics, veremos las trazas de Logs de
este fichero, impresionante.
Content Packs

Los fabricantes se estn empezando a dar cuenta lo importante qu es tener los Logs
centralizados para depurar problemas, para evitarlos y solucionarlos en caso de fallo grave, y se
han unido a VMware en proporcionar Content Packs para VMware vRealize Log Insight, de tal
forma que aadir Logs de diferentes fabricantes sea un abrir y cerrar de ojos, aqu el ejemplo:
Conclusin

La conclusin es que VMWare vRealize Log Insight es una herramienta muy potente ya
preparada para el entorno Business y adems con el soporte y garantia de VMware.
He quedado ms que impresionado con este Software, y no solamente porque recoja
perfectamente los Logs de Zimbra Collaboration, si no porque es muy potente y podemos tener
centralizados todos los Logs de cientos de dispositivos.

Puntos positivos
A favor frente a Kibana y Logstash es que viene en formato Appliance, se descarga, se arranca y
a funcionar.
Cuenta con soporte de VMware detrs
Es una solucin Business Ready
Es una solucin preparada para un CAU, o departamento de Sistemas avanzado.
Me encanta la manera de tratar los Logs, de pasearlos y de buscar en ellos.
Content Packs de diferentes fabricantes, awesome.

Puntos negativos
Tiene un coste.
El tema de particionamiento, etc, al venir en formato Appliance es ms complicado tocarlo.
Basado en OpenSuse, lo siento prefiero Ubuntu o Red Hat para appliances, pero VMware parece
muy unido a Opensuse en todos los appliances que saca.
Securizar Zimbra, Enforce a match between FROM and SASL

Securizar nuestro Zimbra para que compruebe el usuario que se loguea con la direccin de
email es una buena prctica que debemos seguir para reducir el SPAM, y los ataques a cuentas
que no existen, etc.

Flujo por Defecto de envo de correos en Zimbra

Un usuario se autentica, y enva un correo a los destinatarios pertinentes, hasta aqu todo
normal.
Vista a Nivel de Outlook:
El correo me llega correctamente.
Pero, por defecto, Zimbra permite que una vez est un Usuario autenticado, pueda enviar
emails en nombre de otra direccin de correo. Lo cual es muy peligroso, y puede comprometer
el buen funcionamiento de nuestro Sistema de Correo, y sobre todo la seguridad de la Empresa
y sus Usuarios. Veamos el flujo de correo de un correo de User 1, autenticado correctamente,
usando la direccin de correo electrnico del Jefe de la Empresa.
Vista a Nivel de Outlook:

Primero me cambio la direccin de E-mail desde donde envo para ejecutar el Fake Email.
Creo un correo para un usuario (en este caso yo pero imaginemos el departamento de
administracin) y le pido que transfiera una cantidad de dinero a un usuario.
La persona que recibe el Correo, lo ve de manera legtima, como si proviniera del Jefe
Financiero, con su direccin de correo y todo. Esto es un Fake Email y debe ser corregido de
inmediato.
Activando la Seguridad para comprobar que el login de usuario y su direccin de correo,
corresponde con lo que dice su username en el sasl

Activar esta seguridad no nos llevar ms de 3 minutos y conseguiremos un Sistema Zimbra


Robusto y Seguro, lo primero es hacer login como usuario Zimbra mediante SSH:

syntax type=php+root@labjorge:/# su zimbra


zimbra@labjorge:/$ zmprov mcf zimbraMtaSmtpdSenderLoginMaps
proxy:ldap:/opt/zimbra/conf/ldap-slm.cf +zimbraMtaSmtpdSenderRestrictions
reject_authenticated_sender_login_mismatch[/syntax]

El siguiente paso es abrir el fichero opt/zimbra/conf/zmconfigd/smtpd_sender_restrictions.cf

[syntax type=php+zimbra@labjorge:/$ vi
/opt/zimbra/conf/zmconfigd/smtpd_sender_restrictions.cf[/syntax]

Y una vez en l, aadiremos reject_sender_login_mismatch despus de permit_mynetworks,


el resto no hay que tocar nada:

[syntax type=php+permit_mynetworks, reject_sender_login_mismatch[/syntax]


Despus de un minuto aproximadamente, zmconfigd actualizar la configuracin de postfix y
aplicar correctamente los nuevos cambios que hemos introducido.
El Flujo de Correo queda de la siguiente manera; El User 1 se autentica, e intenta enviar un
correo usando la direccin de correo de su Jefe, pero el Sistema Zimbra le devuelve un error al
instante.
Vista a Nivel de Outlook:

Una vez hemos aplicado esta seguridad, vamos a probar de nuevo a mandar otro correo,
solicitando esta vez ms dinero:
Lamentablemente para el Usuario con malas intenciones, este problema de seguridad est ya
corregido y al intentar enviar el correo, recibir un bonito error 553 5.7.1 Sender address
rejected: not owned by user.
Whitelist para ciertas cuentas

Seguramente necesitemos activar una pequea Whitelist, para que ciertas cuentas o usuarios si
puedan realizar este cambio de direccin de correo, y con un login puedan enviar en nombre de
otras cuentas, tipo formularios de contacto, no-reply, etc.
El primer paso es crear la base de datos de usuario:
[syntax type=php]root@labjorge:/# vim /opt/zimbra/conf/slm-exceptions-db[/syntax]

El segundo paso es introducir las direcciones que queremos permitir y luego el usuario real:
*syntax type=php+jefefinanciero@labjorge.jorgedelacruz.es
admin@labjorge.jorgedelacruz.es[/syntax]

El tercer paso es hacer el postmap para que se cree la Base de Datos correctamente:

[syntax type=php]root@labjorge:/# postmap /opt/zimbra/conf/slm-exceptions-db[/syntax]

El comando ahora a ejecutar con el zmprov aade la base de datos de Whitelist:


[syntax type=php+root@labjorge:/# zmprov mcf zimbraMtaSmtpdSenderLoginMaps
lmdb:/opt/zimbra/conf/slm-exceptions-db, proxy:ldap:/opt/zimbra/conf/ldap-slm.cf +
zimbraMtaSmtpdSenderRestrictions reject_authenticated_sender_
login_mismatch[/syntax]
Podemos esperar 1 minuto o forzar el reinicio con el siguiente comando:

[syntax type=php+root@labjorge:/# zmmtactl stop && sleep 30 && zmmtactl start[/syntax]

Y al enviar de nuevo usando la direccin alternativa, no nos dar ningn error:


Monitorizacin de Zimbra Collaboration

Si tener los Logs era importante, tener el servidor, o servidores de Zimbra Collaboration
controlado en todo momento y al detalle es prcticamente impositivo. Es por ello para
monitorizar Zimbra Collaboration sobre entorno Nagios.

Preparando nuestro servidor de Nagios

Antes de empezar a monitorizar, dejaremos nuestros ficheros de configuracin preparados.


Crearemos el servidor de Zimbra y un grupo:
root@firewall:~# vim /etc/nagios3/conf.d/ilba_zimbra.cfg
define host{
use generic-host
host_name zimbra.ilba.cat
alias zimbra.ilba.cat
address 192.168.100.20
}
root@firewall:~# vim /etc/nagios3/conf.d/hostgroups_nagios2.cfg
define hostgroup {
hostgroup_name zimbra-servers
alias Zimbra
members zimbra.ilba.cat
}
Instalando NRPE en nuestro servidor de Zimbra

Lo que haremos, es instalar el cliente de Nagios en nuestro servidor de Zimbra . En mi caso es


una CentOS y por defecto, este sistema operativo, no viene el cliente de Nagios en los
repositorios oficiales, por consiguiente tendremos que aadir el repositorio EPEL ( Linux
Empresarial ) para poder instalar el cliente. OS dejo una captura donde se ve claramente como
funciona el sistema de monitorizacin de Nagios con NRPE ( Nagios Remote Plugin Executor ):

Para instalar el cliente haremos lo siguiente, como ya he indicado anteriormente, aadiremos el


repositorios EPEL :

[root@zimbra ~]# rpm -Uhv http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-


8.noarch.rpm
Una vez aadido el repositorio de EPEL, ya podremos instalar el cliente NRPE en nuestro
servidor de Zimbra:
[root@zimbra ~]# yum install nagios-plugins-nrpe nagios-plugins-all nrpe

Ahora tendremos que configurar el cliente de Nagios para que nos acepte argumentos y nos
permita acceder desde nuestro servidor de Nagios la monitorizacin:

[root@zimbra ~]# vim /etc/nagios/nrpe.cfg


allowed_hosts=192.168.100.1
dont_blame_nrpe=1
[root@zimbra ~]# service nrpe restart
[root@zimbra ~]# vim /etc/selinux/config
SELINUX=disabled
Monitorizando servicio SMTP

El Simple Mail Transfer Protocol (SMTP) (Protocolo para la transferencia simple de correo
electrnico), es un protocolo de red utilizado para el intercambio de mensajes de correo
electrnico entre ordenadores u otros dispositivos. Lo que haremos es monitorizar desde fuera
del servidor de Zimbra, que el servicio SMTP est levantado:

root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg


define service{
use generic-service
hostgroup_name zimbra-servers
service_description SMTP
check_command check_smtp
}
Monitorizando servicio SUBMISSION

El Submission, es un protocolo de red (puerto 587) utilizado para el intercambio de mensajes de


correo electrnico entre ordenadores u otros dispositivos, este puerto es el alternativo al SMTP.
Lo que haremos es monitorizar desde fuera del servidor de Zimbra, que el servicio Submission
est levantado:

oot@firewall:~# vim /etc/nagios3/commands.cfg


define command{
command_name check_submission
command_line /usr/lib/nagios/plugins/check_smtp -H $HOSTADDRESS$ -p 587
}
root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service{
use generic-service
hostgroup_name zimbra-servers
service_description Submission
check_command check_submission
}
Monitorizando servicio IMAP

Internet Message Access Protocol (IMAP), es un protocolo de aplicacin que permite el acceso a
mensajes almacenados en un servidor de Internet. Mediante IMAP se puede tener acceso al
correo electrnico desde cualquier equipo que tenga una conexin a Internet. IMAP tiene varias
ventajas sobre POP3 (otro protocolo empleado para obtener correos desde un servidor). Por
ejemplo, es posible especificar en IMAP carpetas del lado del servidor. Por otro lado, es ms
complejo que POP3 ya que permite visualizar los mensajes de manera remota y no descargando
los mensajes como lo hace POP3. Lo que haremos es monitorizar desde fuera del servidor de
Zimbra, que el servicio IMAP est levantado:

root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg


define service{
use generic-service
hostgroup_name zimbra-servers
service_description IMAP
check_command check_imap
}
Monitorizando servicio POP3

En informtica se utiliza el Post Office Protocol (POP3, Protocolo de Oficina de Correo o


Protocolo de Oficina Postal) en clientes locales de correo para obtener los mensajes de correo
electrnico almacenados en un servidor remoto. Lo que haremos es monitorizar desde fuera del
servidor de Zimbra, que el servicio POP3 est levantado:

root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg


define service{
use generic-service
hostgroup_name zimbra-servers
service_description POP3
check_command check_pop
}
Monitorizando servicio IMAP SSL

Este protocolo, es el mismo que el IMAP, pero el acceso se realiza de manera segura mediante
certificados. Lo que haremos es monitorizar desde fuera del servidor de Zimbra, que el servicio
IMAP SSL SSL est levantado:
root@firewall:~# vim /etc/nagios3/commands.cfg
define command{
command_name check_imaps
command_line /usr/lib/nagios/plugins/check_imap -H $HOSTADDRESS$
-p 993 -S
}
root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service{
use generic-service
hostgroup_name zimbra-servers
service_description IMAP SSL
check_command check_imaps
}
Monitorizando servicio POP3 SSL

Este protocolo, es el mismo que el POP3, pero el acceso se realiza de manera segura mediante
certificados. Lo que haremos es monitorizar desde fuera del servidor de Zimbra, que el servicio
POP3 SSL SSL est levantado:

root@firewall:~# vim /etc/nagios3/commands.cfg


define command{
command_name check_pops
command_line /usr/lib/nagios/plugins/check_pop -H $HOSTADDRESS$
-p 995 -S
}
root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service{
use generic-service
hostgroup_name zimbra-servers
service_description POP3 SSL
check_command check_pops
}
Monitorizando el servicio de ClamAV

ClamAv es el antivirus que usa el sistema de Zimbra. Lo que haremos es monitorizar


internamente del servidor de Zimbra, que el servicio ClamAV tenga un socket, eso nos indicar
que esta funcionando:
[root@zimbra ~]# vim /etc/nagios/nrpe.cfg
command[check_clamd]=/usr/lib64/nagios/plugins/check_clamd
/opt/zimbra/data/clamav/clamav.sock
[root@zimbra ~]# service nrpe restart
root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service {
use generic-service
hostgroup_name zimbra-servers
service_description ClamAV
check_command check_nrpe_1arg!check_lmtp
}
Monitorizando el servicio LMTP

Local Mail Transfer Protocol o LMTP (Protocolo de transporte local de correo) es un derivado de
SMTP, el Simple Mail Transfer Protocol. LMTP es diseado como una alternativa a SMTP para
situaciones donde el lado receptor no dispone de cola de correo (queue mail), como unMTA
(Mail Delivery Agent) que entiende conversaciones SMTP.Lo que haremos es monitorizar
internamente del servidor de Zimbra, que el servicio LMTP esta funcionando:

[root@zimbra ~]# vim /etc/nagios/nrpe.cfg


command[check_lmtp]=/usr/lib64/nagios/plugins/check_smtp -H localhost -p 7025
[root@zimbra ~]# service nrpe restart
root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service {
use generic-service
hostgroup_name zimbra-servers
service_description LMTP
check_command check_nrpe_1arg!check_lmtp
}
Monitorizando el servicio SpellCheck

SpellCheck es el corrector ortogrfico de Zimbra. Lo que haremos es monitorizar internamente


del servidor de Zimbra, que el servicio SpellCheck esta funcionando:

[root@zimbra ~]# vim /etc/nagios/nrpe.cfg


command[check_spell]=/usr/lib64/nagios/plugins/check_http -H localhost -p 7780
[root@zimbra ~]# service nrpe restart
root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service {
use generic-service
hostgroup_name zimbra-servers
service_description SpellCheck
check_command check_nrpe_1arg!check_spell
}
Monitorizando el servicio DNS

Verificaremos que el servidor de Zimbra tenga acesso a internet y lo que haremos es monitorizar
internamente, desde el servidor de Zimbra, que tenga resolucin:

[root@zimbra ~]# vim /etc/nagios/nrpe.cfg


command[check_dns]=/usr/lib64/nagios/plugins/check_dns -H google.com
[root@zimbra ~]# service nrpe restart
root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service {
use generic-service
hostgroup_name zimbra-servers
service_description DNS
check_command check_nrpe_1arg!check_dns
}
Monitorizando el certificado

Ya que el certificado que se instala en nuestro servidor de Zimbra es vital, ya que sin l dejara
de funcionar el sistema. Lo que haremos es monitorizar internamente del servidor de Zimbra,
que el certificado no nos haya caduque:

[root@zimbra ~]# vim /etc/nagios/nrpe.cfg


command[check_cert]=/usr/lib64/nagios/plugins/check_http -S -H localhost -C 30
[root@zimbra ~]# service nrpe restart
root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service {
use generic-service
hostgroup_name zimbra-servers
service_description Cert HTTPS
check_command check_nrpe_1arg!check_cert
}
Monitorizando usuarios logueados

Es importante saber cuantos usuarios hay loginados, ya que si hay varias personas trabajando en
el servidor, podemos llegar a chafar procesos o configuraciones entre nosotros.

[root@zimbra ~]# vim /etc/nagios/nrpe.cfg


command[check_users]=/usr/lib64/nagios/plugins/check_users -w 2 -c 3
[root@zimbra ~]# service nrpe restart
root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service {
use generic-service
hostgroup_name zimbra-servers
service_description Usuarios
check_command check_nrpe_1args!check_users
}
Monitorizando Load Average

El Load Average, se compone de varios elementos, los cuales nos informarn de la carga del
servidor.

root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg


define service {
use generic-service
hostgroup_name zimbra-servers
service_description Load Average
check_command check_nrpe!check_load!5!10
}

Monitorizando PING

Monitorizando el Ping, podemos llegar a saber si nuestro servidor sufre latencias, las cuales
pueden llegar a ser problemticas para el correcto funcionamiento de nuestro servidor.

define service {
use generic-service
hostgroup_name zimbra-servers
service_description Ping6
check_command check_ping!100.0,20%!500.0,60%
}
Monitorizando espacios

Como podris ver en la captura, yo tengo mi servidor de Zimbra seccionado en tres particiones:
OPT, HSM y Backups. Lo que haremos es monitorizarlas, para que cuando quede poco espacio
nos avise.
[root@zimbra ~]# vim /etc/nagios/nrpe.cfg
command[check_opt]=/usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p /opt
command[check_backup]=/usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p
/opt/zimbra/backup
command[check_hsm]=/usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p
/opt/zimbra/hsm
[root@zimbra ~]# service nrpe restart
root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service {
use generic-service
hostgroup_name zimbra-servers
service_description Espacio OPT
check_command check_nrpe_1arg!check_opt
}
define service {
use generic-service
hostgroup_name zimbra-servers
service_description Espacio HSM
check_command check_nrpe_1arg!check_hsm
}
define service {
use generic-service
hostgroup_name zimbra-servers
service_description Espacio Backup
check_command check_nrpe_1arg!check_backup
}
Al final de todos estos checks, nos tendra que quedar de la siguiente manera en nuestro Nagios:
Plugin check_zmstatus.pl

Este Plugin nos monitoriza el estado de los servicios, directamente ejecutando en el servidor el
comando zmcontrol status, como usuario Zimbra. Debe meterse en la carpeta donde tengamos
nuestros plugins, /usr/lib64/nagios/plugins (para CentOS 64bit), /usr/lib/nagios/plugins (para
Ubuntu 12.04 64bit) Este plugin es gracias a schose.net
Tambin hay que ejecutar algunos comandos adicionales, meter en el fichero /etc/sudoers la
siguiente lnea:

%nagios ALL=(zimbra) NOPASSWD:/opt/zimbra/bin/zmcontrol

Y en nuestro fichero de nrpe.cfg lo siguiente:

[root@zimbra ~]# vim /etc/nagios/nrpe.cfg


command[check_zmstatus]=/usr/lib64/nagios/plugins/check_zmstatus.pl -b
$ARG1$

[root@zimbra ~]# service nrpe restart


Ahora en nuestro server de Nagios:

root@srvnagios:~# vim /etc/nagios3/conf.d/services_nagios2.cfg


define service {
use generic-service
hostgroup_name zimbra-servers
service_description Zimbra Status
check_command check_nrpe_zimbra
}

Y metemos el comando en nuestro commands.cfg


define command{
command_name check_nrpe_zimbra
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c
check_zmstatus -u
}

El aspecto de este plugin es el siguiente:


Monitorizando Mailq

Otro servicio importante es Mailq, el servicio que nos muestra los mensajes que tenemos en
cola, podemos monitorizar si tenemos un problema grande de spam, o que se han quedado los
mensajes parados, vamos a monitorizarlo de la siguiente manera:
[root@zimbra ~]# vim /etc/nagios/nrpe.cfg
command[check_zimbra_mailq]=/usr/lib/nagios/plugins/check_mailq -w 100 -c
150 -M postfix

Para este caso, adems, tenemos que modificar un fichero, ya que la ruta de mailq dentro de
nuestro utils no es correcta:

root@zmmt00:/home/sistemas# vi /usr/lib/nagios/plugins/utils.pm

Y cambiar el $PATH_TO_MAILQ que apunta a /usr/bin/mailq


Por lo siguiente /opt/zimbra/postfix-2.10.1.2z/sbin/mailq que es la ruta correcta en Zimbra

Ejecutando el check de nuevo, veremos que ya podemos ver el nmero de mensajes en cola, 6
en mi caso.
Cuando el tiempo es todo

A veces usamos servidores NTP en nuestras VM con Zimbra, pero a su vez tenemos instaladas
las VM Tools, probablemente instaladas por defecto, y esto activa sincronizar la hora de la VM
con la del Host, lo cual hace que nuestro NTP no sirva para nada, si queremos corregir este
problema y basarnos en NTP, recomendado, lanzar este comando:
Comprobar si tenemos las Tools sincronizando la hora con el Host:
[syntax type="php"]# vmware-toolbox-cmd timesync status Enables[/syntax]

Deshabilitar la sincronizacin con el hipervisor.

[syntax type="php"]vmware-toolbox-cmd timesync disable[/syntax]

Despus de todos estos cambios, lo que nos queda es reiniciar nuestro equipo para que se
apliquen todos los cambios realizados.

Você também pode gostar