main

A partir del año pasado volví a administrar servidores zimbra después de 4 años de inactividad con esta suite colaborativa. Pese a ello la última versión que había usado en 2012 era la 7.1.3 y la última versión estable liberada en 2016 que hice la instalación era la 8.6.

Read More

Anuncios

La suite colaborativa zimbra en su versión community ofrece las opciones de tener direcciones de reenvío de correo visibles y configurables por usuario -conocidas como User specified- así como también direcciones para reenvío ocultas al mismo.

Al configurar la clase de servicio por defecto está la opción de permitir -o no- a los usuarios el definir estas direcciones de reenvío, pero se debe evaluar el riesgo que supone para la fuga de información el hecho de que un usuario pueda enviar todo el correo entrante a su bandeja de entrada hacia una cuenta externa en caso de no tener políticas en otros módulos que lo impidan. Read More

El comportamiento estándar en opensuse cuando falla un trabajo de impresión (impresora apagada, falta de consumibles, etc) es que se deshabilita la impresora.

Mientras investigo como cambiar dicho comportamiento dejo los comando de como diagnosticar y habilitar nuevamente sin usar esas GUI’s tan lentas:

lpstat -p #Lista de impresoras con sus estados

cupsenable LaserJet_P1102w #Habilitar impresora

Tenía un par de meses con este error al querer editar una conexión en NetworkManager en mi OpenSUSE Tumbleweed (rolling release). Esto ocurrió después de instalar requerimientos para instalar yowsup-cli.

Había probar reinstalando el NetworkManager o queriendo administrar las interfaces desde Yast pero fue hasta que reinstalé el paquete “NetworkManager-connection-editor” que se resolvió este error.

Espero le sirva a alguien más.

Comando para reinstalar en openSUSE:

zypper in -f NetworkManager-connection-editor

Estoy recibiendo un E1 vía SIP Trunk por lo que la manera de monitorear el servicio no es la convencional, y por convencional me refiero a la que estoy acostumbrado y que está más ampliamente desplegada por los proveedores de telefonía en el país, recibir con un hardware E1 como una tarjeta PCI u otra.

Para vigilar el servicio al recibir de un convertidor de medios E1 hacia mi tarjeta E1 en Asterisk, uso el plugin de nagios check_e1t1 el cual monitorea el estado de sincronía de un puerto en específico usando el comando “dahdi show status” el cual a su vez depende de el archivo /dev/dahdi/ctl.

En el caso del troncal SIP no hay puerto físico que verificar por lo cual uso Nagisk, este plugin escrito en perl permite monitorear “peers” de Asterisk entre otras cosas.

La sintaxis correcta para monitorear una troncal en específico es:

/usr/local/nagios/lib/nagisk.pl -p NombreDeTroncal -c peer

La sintaxis que nos arroja la ayuda del comando no me quedaba muy clara:

Syntax: /usr/local/nagios/lib/nagisk.pl [-hv] [-c OPT] [-s NB|-p NAME|-b BUDDY] [-w TRESH -x TRESH]

Yendo al tema de cual de las dos tecnologías es mejor para recibir el servicio, soy nuevo en el tema de SIP Trunk, pero prefiero optar por él debido a que no hay hardware E1 de por medio actuando como SPOF (punto único de fallas).

Este es un gran dolor de cabeza para SysAdmins de PBX Asterisk o Elastix cuando se toman en cuenta costos de tarjetas E1, módulos de cancelación de eco, u otros y tiempo de importación en un país en el que ningún proveedor local mantiene este tipo de piezas en existencia o si quiera mantienen relaciones directas de socio comercial con fabricantes.