Espero caer bien y poder demostrar que sé hacer cosas!

El servidor de correo del que voy a hablar es un HP ML110 G4, con un Xeon 1.8Ghz y 4GB de RAM. Tiene instalado Fedora 7, Zimbra 5.13 y Bind9. Hace copias de seguridad regularmente usando el script de Heinzg, explicado en un post anterior, y saca el correo por un smarthost. Hasta aquí nada complicado. El problema viene cuando queremos cambiar las cosas…

Tras montar un equipo de prueba con una configuración de software similar me dispuse a recuperar Zimbra desde los backups. Mi proceso fue el siguiente:

• Instalar el mismo sistema operativo, Fedora 7, y actualizar con yum update.
• Configurar los mismo parámetros de red, tanto IP como archivo /etc/hosts, nombre de host local y servidor DNS. Ésto último solo es necesario si el servidor está detras de un firewall o de nat.
• Instalar misma versión de Zimbra, con la opción -s, para no realizar configuración posterior y solo instalar los rpm.
• Extraer el backup con dar con el comando dar -K clave -x archivo.dar.
• Parar el servicio de Zimbra, zmcontrol stop como usuario zimbra, y sustituir la carpeta /opt/zimbra por la del backup.
• Reparar permisos, como root hay que hacer chown -R zimbra:zimbra /opt/zimbra y ejecutar /opt/zimbra/libexec/zmfixperms.sh
• Inciar el servicio de Zimbra, zmcontrol start como usuario zimbra.

Con esto tuve replicado el servidor y funcionando perfectamente. O eso creía yo. Encontré un error al entrar en la web de administración, concretamente intentado abrir el panel de colas de correo. No funcionaba. Era poco, pero era un fallo. Así que intenté arreglarlo. Se me ocurrió actualizar a la última versión de la rama 5, la 5.18. Tan sencillo como descargar el paquete de instalación, ejecutar el proceso y actualizar. Detectó la configuración anterior y se puso en marcha de nuevo con la versión 5.18. El panel de colas de correo volvió a funcionar perfectamente.

No contento con esto me dispuse a actualizar a la 6 RC1 para echar un ojo a las nuevas funcionalidades en mi buzón. No problem, de nuevo ejecutar la instalación del paquete y todo fue como de costusmbre, igual que cualquier actualización anterior. La única pérdida que ha habido que lamentar en este cambio es la de los datos estadísticos de la zona de adminsitración. Sale el mensaje de no data available pero el caso es que el archivo /opt/zimbra/libexec/zmgengraphs ha desaparecido en esta versión 6. Aunque, al ejecutar zmcontrol status todos los servicios aparecen levantados. A saber…

Una vez dentro del buzón veo algunas diferencias. La lista de amigos aparece en la parte inferior de la página y ya no está en la barra lateral izquierda.

Al redactar un mensaje nuevo ahora existe la opción de añadir emoticonos de lo más variopinto (esa es April, de las tortugas ninja??) y también podremos añadir un attach desde el maletín.

No veo por ningún sitio la nueva opción de las versiones beta para solicitar la confirmación de lectura/recepción. Lo habré soñado?? Ahh no, esto es lo que pasa:

• When composing an email message, users can flag the message for a return read receipt message. When uses compose an email they can
  select Request Read Receipt from Options on the toolbar. The administrator enables/disables this feature by COS or Accounts. Upgrading to 6.0, this feature is not enabled. For new ZCS installs this feature is enabled by default. This feature can be enabled from the administration console, COS/Admins Features Tab. Users can manage whether to send a return receipt when a message is requesting a read receipt, from their Preferences>Mail folder, Read Receipt section. (Bug 7257).

En los apartados de libreta de direcciones, agenda, tareas y notas no veo nada sifnificativo. En el maletín es donde se han añadido novedades que saltan a la vista, como la creación de hojas de cálculo y presentaciones. También encontramos el inverso de añadir archivos del maletín como adjuntos. Se trata de un botón para enviar un archivo o un enlace de share directamente desde el maletín.

En el área de las preferencias seguro que hay más de un cambio, pero lo primero que se aprecia es la nueva vista y el poder activar/desactivar los zimlets en nuestra cuenta.Ahora que todo funciona correctamente vamos a intentar llevarlo un poco más lejos. Instalaremos Fedora 11 con su correspondiente versión de Zimbra 6 RC1.

Con el DVD de Fedora 11 no podremos actualizar desde la versión 7. No detectará la instalación de nuestro sistema operativo y solo nos dará la opción de nueva instalación. Creo que viene a ser por esto. Solución, pasar por la versión 10 antes, ejecutar yum update y luego actualizar a la 11. Durante este “apaño” no deberemos tocar nada relativo a Zimbra ni a otras configuraciones.

Una vez tengamos Fedora 10 instalado y al día, reiniciamos con el DVD de Fedroa 11 para efectuar su instalación. Actualizamos el sistema existente y… vaya! Grub se ha ido a paseo. No sé si será un fallo generalizado o solo m ha pasado a mi. El caso es que si ocurre lo reparamos arrancando desde el DVD de Fedora 11 de nuevo y elegimos la opción rescue system. Una vez en la shell ejecutamos la reinstalación de grub, primero entrando en su intérprete de comandos (ejecutando grub) y luego especificando la unidad de disco y la partición donde dee residir. Primero ejecutamos root (hd0,0) y luego setup (hd0), contando con que queramos instalarlo en el primero disco duro y en la partición de boot.

Solventado este asunto, el sistema debería iniciar correctamente, pero nos encontraremos otro problema derivado de la actualización de 10 a 11. Es muy probable que  yum no nos funcione porque el sistema mantendrá el paquete de Fedora 10. Aquí está la solución, que tan solo consiste en eliminar el paquete viejo e instalar el nuevo a mano. Ahora tan solo debemos instalar el paquete de Zimbra 6 RC1 para Fedora 11. Hay que repasar que tengamos todas las configuraciones de red idénticas a las del momento en que estábamos con Fedora 7 y Zimbra funcionando. Me refiero a la IP, nombre de host local, archivo /etc/hosts y servidor DNS. La instalación no debería dar problemas. Detectará el modo update de versión 6 a versión 6 y nos dejará el entorno funcionando.

Llamé por teléfono a mi tienda de electrónica de confianza y me dijeron que tenían equipos de similares prestaciones. Así que me platé en la tienda y para mi sorpresa disponían de unas baterías de similar voltaje y capacidad pero algo más grandes. Solución: sierra de calar que te crió. Dos batería de 12 voltios en paralelo suman ambos voltajes. Total 24. No es exacto pero la electrónica del SAI se ocupa de regular la tensión. El apaño me salió por 15€ cada batería.

Estas nuevas baterías tienen más autonomía que las antiguas y ya han respondido a la perfección ante un par de saltos del diferencial. Es que en verano y con este calor, los aires acondicionados pueden saturar la red en cualquier momento. Tengo previsto hacer un test de autonomía en cuanto se carguen por completo. Ya postearé resultados.

Configurando el Switch.

Como vimos en el artículo anterior, en nuestro switch vamos a definir suficientes puertos pertenecientes a la VLAN de VoIP como para conectar los teléfonos IP y el servidor Asterisk. Este podría ser un ejemplo visual:

El puerto 11 tiene conectado el servidor, y del 13 al 19 tenemos conectados los teléfonos IP. El 24 está tagged y es el que se conecta al PFSense.

Configurando PFSense.

Sencillamente debemos crear una VLAN con el mismo ID que en el switch, en este caso el 7. Después de crear la VLAN veremos que aparece como si de una interfaz física se tratase. El siguiente paso consiste en definir las reglas que queramos para esta nueva red. Podemos restringir al máximo permitiendo tan solo tráfico hacia Internet desde la IP del Asterisk, en caso de tener un proveedor IP y de no querer usar softphones, ya que de esta manera sólo los teléfonos IP “verían” el Asterisk. Esto es a gusto de cada uno y dependiendo de su  nivel de paranoia.

Cisco y Asterisk.

Existen varias webs donde podemos encontrar información acerca de como conectar equipos Cisco a nuestro servidor Asterisk, pero en pocas nos dan una explicación completa o global de como mezclar estos dos mundos. Para hacer entender este asunto a lo que vienen de nuevas intentaré resumirlo lo máximo posible de manera realista:

Mundo Cisco:

• Trabaja por defecto con su protocolo SCCP (Skinny Client Control Protocol), aunque soporta SIP (pagando claro).
• Soporta los códecs más conocidos, pero cerrados, como alaw, ulaw, g729… (porque has pagado).
• Usa hardware propietario para conectar a la PSTN, RDSI… (evidentemente tendrás que pagar un plus para esto).
• Se lleva bien con entornos Windows Active Directory (que baratos no son).
• Cualquier soporte que necesites es aconsejable que lo recibas de Técnicos y Administradores Cisco Certificados (prepara la chequera).
• Te ha costado una pasta y te has casado con ellos, pero es que hay que reconocer son los mejores en lo suyo.

Mundo Asterisk:

• Trabaja con prácticamente cualquier protocolo que tenga una versión abierta. Yo lo he usado con SIP, IAX2, H323, incluso con SCCP.
• Soporta los codecs cerrados más conocidos pero también otros tantos libres que funcionan de maravilla como iLBC.
• Puede funcionar con un amplísimo abanico de hardware que va desde tarjetas FXO de 20€ o BRI de 40€ hasta carísimos interfaces PRI o GSM de gama alta.
• Se lleva bien con casi todo que cumpla los estándares, ya sea Linux, Windows o Mac.
• Siempre que necesites ayuda puedes acudir a técnicos certificados por Digium o darte una vuelta por los miles de foros, blogs y listas de correo que ayudan a la gente desinteresadamente.
• No te has gastado mucho dinero, pero seguro que vas a invertir gran cantidad de tiempo y esfuerzo en poner en marcha tu sistema si empiezas desde cero.

Lo que intento en mis proyectos es conocer cuanto puedo de ambos mundos y fusionar lo mejor de cada uno. Me pasa como a Joey, el de Friends. Cuando le preguntan sobre si prefiere el sexo o la comida, el pobre tiene un cortocircuito mental y grita… ¡PAN CON CHICAS! No hay porqué montar un entorno 100% open source o propietario, hay que aprovechar lo mejor de cada mundo. Yo me quedo con el servidor Asterisk y con los teléfonos Cisco.

El entorno de nuestro sistema requiere los siguientes componentes:

• Servicio TFTP (en el servidor Asterisk). Los teléfonos son “tontos”. Cualquier configuración o archivo que necesiten lo pedirán “bajo demanda” a sus servidores TFTP. Viene activado y listo para funcionar en Elastix.
• Servicio DCHP (en el servidor Asterisk). El DHCP del PFSense parece que no se lleva muy bien con los teléfonos Cisco. Yo he conseguido mejores resultados configurando a mano el dhcpd3 que viene por defecto en Elastix y que además tiene gestión web.

Eligiendo protocolo: SIP o SCCP.

A la hora de conectar los teléfonos Cisco a nuestro Asterisk tenemos que tomar una decisión: SIP o SCCP. Ambos funcionan bien, pero SIP es un estándar y SCCP requiere configuración manual extra, por lo que la primera opción gana bastante puntos. Si queremos cargar el firmware SIP en un terminal Cisco tendremos que hacernos con el paquete de software necesario. Esto se puede hacer descargándolo de la web de Cisco (si tenemos cuenta autorizada para ello) o por otros medios. Existen algunas webs desde donde podremos descargar este software sin mucho esfuerzo, tan solo hay que buscar el nombre del archivo.

Elegir SCCP puede ser una opción en algunos casos. Asterisk viene con un canal llamado chan_skinny cuya configuración reside en /etc/asterisk/skinny.conf. También existe un canal más completo y con buena fama llamado chan_sccp, pero no he tenido el gusto de ponerlo en marcha.

Entendiendo el Servicio de Provisionamiento.

Una vez solventado este asunto, lo que vamos a hacer es replicar en nuestro servidor Asterisk todos los servicios que nos interesan de un Call Manager y que usan estándares. Los teléfonos Cisco funciona básicamente con plantillas XML y descargando archivos por TFTP, lo cuál no es nada raro y puede ser montado en cualquier equipo. Por ejemplo, cuando nuestro teléfono IP quiere consultar los sonidos de llamada disponibles, pide a su servidor TFTP un listado XML que tiene un nombre por defecto donde está la lista de sonidos. Lo mismo hace cuando queremos cambiar la imagen de fondo o consultamos la agenda.

El proceso de arranque de un teléfono IP consiste en solicitar IP y dirección de servidor TFTP por defecto a través de DHCP. A partir de este momento pedirá a ese servidor de TFTP todo lo necesario para funcionar.

Montando el Entorno.

Puedes arrancar el servicio DHCPD desde la web del Elastix, pero para añadir el parámetro de servidor TFTP deberás editar a mano el archivo /etc/dhcpd.conf e introducir la siguiente línea

next-server                     1.1.1.1;  #IP SERVIDOR TFT

La carpeta donde colocaremos los archivos que pedirán los teléfono es /tftpboot, situada en la raíz del servidor Elastix. En el caso de los archivos de provisionamiento tenemos dos opciones, usar un artchivo por defecto relativo a todos los terminales del mismo modelo, o especificar por MAC. Por ejemplo, si queremos que todos los teléfonos de un departamento usen SIP y todos los demás utilicen SCCP, crearemos un archivo de provisionamiento por defecto con la versión SCCP y a parte haremos archivos específicos para cada MAC de los de este departamento concretando el uso del firmware SIP. Este tipo de configuraciones tan solo las comento para que quede constancia de que son posibles de realizar, pero no me voy a extender más ya que no es el caso del ejemplo. Los archivos comunes a todos los terminales como ringtones o imágenes de background usan rutas estándar, solo diferenciadas en el caso de los archivos de background por carpetas con nombres definidos por el tamaño en píxeles.

Para las imágenes de background deberemos crear las carpetas:

/tftpboot/Desktops/95×34x1 (teléfonos con LCD pequeña monocromo)

/tftpboot/Desktops/320×212x12 (teléfonos con LCD grande en color)

El listado de imágenes disponibles (List.xml) debe residir en cada uno de estos directorios, conteniendo en su estructura los nombres de las imágenes y sus thumbnails:

<CiscoIPPhoneImageList>

<Image Item Image="TFTP:Desktops/320x212x12/thumb-imagen01.png"
URL="TFTP:Desktops/320x212x12/imagen01.png"/>
</CiscoIPPhoneImageList>

Los thumbnails tienen un tamaño inferior en proporción 4 a 1.

En el caso de los sonidos de llamada la estructura es:

/tftpboot/ringlist.xml (común para todos los terminales)

Con la siguiente sintaxis:

<CiscoIPPhoneRingList>
        <Ring>
                <DisplayName>Analog 1</DisplayName>
                <FileName>Analog1.raw</FileName>
        </Ring>
</CiscoIPPhoneRingList>

Las especificaciones de los archivos de sonido son:

Raw PCM

• 8000 samples por segundo.

• 8 bits por sample.

• Compresión uLaw.

• Tamaño máximo — 16080 samples.

• Tamaño mínimo — 240 samples.

Otro archivo necesario que reside en la raíz del TFTP es el dialplan.xml. Define los tiempos de espera para diferentes longitudes de numeración, entre otras cosas. Este es un ejemplo que funciona:

<dialtemplate>
 <template match="..." timeout="1" user="Phone"><!-- Llamadas de servicios -->

</template>

<template match="...." timeout="0" user="Phone"> <!-- Llamadas internas -->

</template>

<template match="0........." timeout="1" user="Phone"> <!-- Llamadas nacionales -->

</template>

<template match="000*" timeout="3" user="Phone"> <!-- Llamadas internacionales -->

</template>

</dialtemplate>

Existen otros muchos servicios que podemos replicar en nuestro entorno, como la agenda o un servicio de avisos automáticos. Dada la extensión que está tomando este artículo lo dejaré para otros más específicos.

Cargando Firmware SIP.

Para modificar el firmware por uno SIP, deberemos colocar el contenido del zip que distribuye Cisco en la raíz del servidor tftp. Por ejemplo, la versión 8-3-1 de los terminales 7906G/7911S (utilizan el mismo firmware) se compone de los siguientes ficheros:

- apps11.8-3-0-50.sbn

- cnu11.8-3-0-50.sbn

- cvm11sip.8-3-0-50.sbn

- dsp11.8-3-0-50.sbn

- jar11sip.8-3-0-50.sbn

- SIP11.8-3-1S.loads

- term06.default.loads

- term11.default.loads

Si tecleamos la secuencia de actualización en los teléfonos IP, éstos se reiniciarán, pedirán IP y dirección del TFTP por DHCP y solicitarán:

- Archivo de firmware por defecto para su modelo (termXX.default.loads).

- Archivos incluidos en el archvo anterior (carga y posterior reinicio).

- Archivo de provisionamiento por defecto  (no es necesario. Se llama SEPDefault.cnf.XML).

- Archivo de provisionamiento para su MAC (SEPMAC.cnf.XML).

- Archivo de plan de numeración (dialplan.xml).

La secuencia de actualización consiste en encender el teléfono con la tecla # pulsada. Se encenderá el led rojo de llamada, pero el teléfono no iniciará. A continuación deberemos pulasr la secuencia 1 – 2 – 3 – 4 – 5 – 6 – 7 – 8 – 9 – * – 0 – #.

El archivo de provisionamiento de un terminal Cisco 7906G para firmware SIP tiene esta pinta (sacado de http://quetzalnet.es/index.php?id=1313):

<device xsi:type=”axl:XIPPhone” ctiid=”1566023366″>
<deviceprotocol>SIP</deviceprotocol> <!– Protocolo de conexión –>
<sshuserid>usuario</sshuserid> <!– Usuario y contraseña para acceder al teléfono vía SSH –>
<sshpassword>mipassword</sshpassword>
<devicepool>
<datetimesetting>
<datetemplate>D-M-YA</datetemplate> <!– Formato de la fecha –>
<timezone>UTC Standard/Daylight Time</timezone> <!– Zona horaria –>
</datetimesetting>
<callmanagergroup>
<members>
<member priority=”0″>
<callmanager>
<ports>
<ethernetphoneport>2000</ethernetphoneport>
<sipport>5060</sipport>  <!– Puerto de comunicación del servidor –>
<securedsipport>5061</securedsipport></ports>
<processnodename>Asterisk</processnodename> <!– Nombre del servidor –>
</callmanager>
</member>
</members>
</callmanagergroup>
</devicepool>
<sipprofile>
<sipproxies>
<backupproxy>dirección_IP_servidor</backupproxy> <!– IMPORTANTE!!! –>
<backupproxyport>puerto_de_comunicación</backupproxyport> <!– Por defecto el 5060 –>
<registerwithproxy>true</registerwithproxy>
</sipproxies>
<sipcallfeatures>
<cnfjoinenabled>true</cnfjoinenabled>
<callforwarduri>x–serviceuri-cfwdall</callforwarduri>
<callpickupuri>x-cisco-serviceuri-pickup</callpickupuri>
<callpickuplisturi>x-cisco-serviceuri-opickup</callpickuplisturi>
<callpickupgroupuri>x-cisco-serviceuri-gpickup</callpickupgroupuri>
<meetmeserviceuri>x-cisco-serviceuri-meetme</meetmeserviceuri>
<abbreviateddialuri>x-cisco-serviceuri-abbrdial</abbreviateddialuri>
<rfc2543hold>false</rfc2543hold>
<callholdringback>2</callholdringback>
<localcfwdenable>true</localcfwdenable>
<semiattendedtransfer>true</semiattendedtransfer>
<anonymouscallblock>2</anonymouscallblock>
<calleridblocking>2</calleridblocking>
<dndcontrol>0</dndcontrol>
<remoteccenable>true</remoteccenable>
</sipcallfeatures>
<sipstack>
<sipinviteretx>6</sipinviteretx>
<sipretx>10</sipretx>
<timerinviteexpires>180</timerinviteexpires>
<timerregisterexpires>3600</timerregisterexpires>
<timerregisterdelta>5</timerregisterdelta>
<timerkeepaliveexpires>120</timerkeepaliveexpires>
<timersubscribeexpires>120</timersubscribeexpires>
<timersubscribedelta>5</timersubscribedelta>
<timert1>500</timert1>
<timert2>4000</timert2>
<maxredirects>70</maxredirects>
<remotepartyid>false</remotepartyid>
<userinfo>None</userinfo>
</sipstack>
<autoanswertimer>1</autoanswertimer>
<autoansweraltbehavior>false</autoansweraltbehavior>
<autoansweroverride>true</autoansweroverride>
<transferonhookenabled>false</transferonhookenabled>
<enablevad>false</enablevad>
<preferredcodec>g729a</preferredcodec> <!– Codecs preferidos –>
<dtmfavtpayload>101</dtmfavtpayload>
<dtmfdblevel>3</dtmfdblevel>
<dtmfoutofband>avt</dtmfoutofband>
<alwaysuseprimeline>false</alwaysuseprimeline>
<alwaysuseprimelinevoicemail>false</alwaysuseprimelinevoicemail>
<kpml>3</kpml>
<phonelabel>Etiqueta_del_telefono</phonelabel> <!– Texto de la esquina superior derecha –>
<startmediaport>10000</startmediaport> <!– Puertos de comunicación RTP, IMPORTANTE –>
<stopmediaport>20000</stopmediaport>
<siplines> <!– Dentro de este apartado configuraremos nuestras lineas SIP –>
<line button=”1″>
<featureid>9</featureid>
<featurelabel>200</featurelabel>
<proxy>dirección_IP_servidor_asterisk</proxy> <!– IMPORTANTE!!! –>
<port>puerto_comunicacion_servidor</port> <!– IMPORTANTE!!! –>
<name>nombre_usuario_SIP</name> <!– IMPORTANTE!!! –>
<displayname>nombre_usuario</displayname> <!– Para el Caller ID –>
<autoanswer>
<autoanswerenabled>2</autoanswerenabled>
</autoanswer>
<callwaiting>3</callwaiting>
<authname>nombre_usuario_SIP</authname> <!– Nombre del usuario de nuevo SIP –>
<authpassword>contraseña_usuario_SIP</authpassword> <!– Contraseña del usuario SIP –>
<sharedline>false</sharedline>
<messagewaitinglamppolicy>1</messagewaitinglamppolicy>
<messagesnumber>extensión_voicemail</messagesnumber> <!–nº de acceso a voicemail –>
<ringsettingidle>4</ringsettingidle>
<ringsettingactive>5</ringsettingactive>
<contact>nombre_usuario</contact> <!– Nombre del usuario de nuevo –>
<forwardcallinfodisplay>
<callername>true</callername>
<callernumber>false</callernumber>
<redirectednumber>false</redirectednumber>
<dialednumber>true</dialednumber>
</forwardcallinfodisplay></line>
</siplines>
<voipcontrolport>5060</voipcontrolport> <!– IMPORTANTE –>
<dscpforaudio>184</dscpforaudio>
<ringsettingbusystationpolicy>0</ringsettingbusystationpolicy>
<dialtemplate>dialplan.xml</dialtemplate> <!– IMPORTANTE !!!–>
</sipprofile>
<commonprofile>

<backgroundimageaccess>true</backgroundimageaccess>
<calllogblfenabled>2</calllogblfenabled>
</commonprofile>
<vendorconfig>
<disablespeaker>false</disablespeaker>
<disablespeakerandheadset>false</disablespeakerandheadset>
<pcport>0</pcport>  <!– IMPORTANTE!!! Si es 0 el puerto habilitado si es 1 deshabilitado–>
<settingsaccess>1</settingsaccess>
<webaccess>1</webaccess> <!– IMPORTANTE!!! –>
<spantopcport>1</spantopcport>
<loggingdisplay>1</loggingdisplay>

</vendorconfig>
<transportlayerprotocol>4</transportlayerprotocol>
<capfauthmode>0</capfauthmode>
<capflist>
<capf>
<phoneport>3804</phoneport>
</capf>
</capflist>

<encrconfig>false</encrconfig>
</device>

Tan solo hay que completarlo con la configuración específica de cada uno y ponerle como nombre SEPmac.cnf.xml.

Creando las extensiones en FreePBX.

El siguiente paso consiste en dar de alta las extensiones que necesitemos en nuestro servidor Asterisk.  Este proceso no tiene ningún secreto. Crearemos extensiones SIP dándoles un número y una contraseña y pondremos el soporte nat en no. Todo lo demás es opcional a gusto del usuario.

]]> http://www.homelesshosting.net/2009/05/22/vlan-s-en-pfsense-12-y-3com-2924-sfp-plus-configurando-telefonos-ip-cisco-parte-2/feed/ 4 http://www.homelesshosting.net/2009/04/29/pfsense-schedules-reglas-temporizadas/ http://www.homelesshosting.net/2009/04/29/pfsense-schedules-reglas-temporizadas/#comments Wed, 29 Apr 2009 08:16:36 +0000 Ximo http://www.homelesshosting.net/?p=388 Vaya! Resulta que en la empresa compran un NAS para hacer backups por diferentes medios, pero quieren ponerlo en la LAN para que la velocidad sea máxima y el firewall no cree un cuello de botella.

Es un fastidio si quieres realizar backups de tus servidores que están en la DMZ, por que claro, a tí no te van a comprar uno de uso exclusivo y no es plan de abrir puertos hacia la LAN… o sí?

Este caso se me planteó hace un tiempo y la mejor solución que pude encontrar se basa en el uso de las reglas temporizadas del firewall. De esta manera, permitiremos comunicación de DMZ hacia LAN solo en los puertos y momentos necesarios.

En este ejemplo usaremos la herramienta de Plesk 9 Backup, un servidor FTP IIS6 y PFSense. A ver que pasa…

Primero de todo tenemos que tener claro qué queremos hacer, en qué sentido van a ir las conexiones, qué puertos vamos a utilizar y a qué hora. Con esta información podemos ponernos manos a la obra.

Queremos que esta comunicación entre redes sea lo más segura posible, por lo que tendremos en cuenta los siguientes aspectos:

• Se supone que se tiene un usuario FTP creado que al loguear con él entramos en nuestro chroot, es decir, no podemos acceder a raiz del sistema ni modificar archivos fuera.
• Aunque este servidor FTP no tenga acceso desde la WAN, configuraremos las tablas de acceso de IPs permitidas.
• Especificaremos manualmente el rango de puertos para las conexiones pasivas usando valores poco comunes. Léase este documento de Microsoft. Lo pongo en Inglés porque el que está en Español se ha autotraducido y tiene fallos.

Vamos ahora con la configuración del PFSense. Primero vamos a definir el horario en que se activarán las reglas que crearemos posteriormente.

Creamos las reglas correspondientes al servicio FTP y al rango de puertos pasivos. Tan solo debemos especificar en el apartado de nuestra DMZ:

Regla 1

• IP origen – Servidor Plesk.
• Protocolo TCP.
• Cualquier puerto de origen.
• IP destino – Servidor FTP.
• Puertos de destino – Puerto 21.

Regla 2

• IP origen – Servidor Plesk.
• Protocolos TCP/UDP.
• Cualquier puerto de origen.
• IP destino – Servidor FTP.
• Puertos de destino -El rango pasivo.

Ahora que ya tenemos ambas reglas creadas definiremos un criterio de temporalidad en el apartado Firewall -> Schedules.  Añadiremos una nueva temporización y nos encontraremos con esta pantalla

En este ejemplo he dado a la regla el nombre “BACKUP_TEMPORIZADO 1″ y he definido un primer criterio que consiste en que se active todos los viernes, haciendo click en el nombre del día (color rojo pálido), y también los días martes 14 y miércoles 15. El horario programado es de 08:00 a 10:00 y el nombre que le he puesto es “por la mañana“. Si hacemos click en Add Time añadiremos esta programación a la lista de horarios de la regla.

Podemos crear reglas temporizadas con todas las programaciones que necesitamos. También es recomendable para paranoicos modificar las reglas cada cierto tiempo para que no sigan un patrón concreto. Hacemos click en Save y veremos como nuestra regla aparece en la lista.

Volvemos a las reglas creadas al principio y en el apartado Schedule seleccionamos la temporización que hemos creado.

Veremos como aparece la programación en la lista de las reglas. Si la programación está activa veremos un icono de pass (flecha verde) si no lo está veremos el icono del cuadrado rojo con la cruz.

Ahora crearemos en el Plesk Backup Manager una programación de backup que coincida con la activación temporal de la regla. Según este ejemplo hemos abierto los puertos durante dos horas. Habría que calcular el tiempo estrictamente necesario para realizar la operación y ajustarlo al máximo para reducir riesgos.

Aquí tenéis el link:

http://www.networkworld.com/reviews/2003/020310gbe.html

Existe un Zimlet bastante práctico que nos da la funcionalidad de “click-to-call” y de enviar SMS a través de la interfaz web de Zimbra. De momento no funciona con Zimbra Desktop. También hay un par de zimlets oficiales que viene con la propia instalación de Zimbra, pero están dentro de la rama experimental. Este por lo menos está bastante probado y según he podido leer por los foros tiene a la gente satisfecha. Vamos al lío…

Descargamos el zimlet de la web oficial de sus desarrolladores. Para instalarlo necesitamos realizar modificaciones tanto en el servidor Zimbra como en el servidor Asterisk. Primero subimos el archivo zip a la carpeta /opt/zimbra/zimlets y lo instalamos usando el comando

zmzimletctl install /opt/zimbra/zimlets/ch_bnc_asterisk.zip

Este comando se encuentra dentro de la carpeta /opt/zimbra/bin. A continuación, extraemos el archivo XML de configuración para editar los parámetros específicos de nuestro servidor Asterisk y lo dejamos en la carpeta /tmp por ejemplo.

zmzimletctl getConfigTemplate
/opt/zimbra/zimlets/ch_bnc_asterisk.zip >
/tmp/ch_bnc_asterisk_config.xml

Editamos el archivo ch_bnc_asterisk_config.xml donde tendremos que cambiar:

• IP o nombre dns de nuestro servidor asterisk.

<property name="astManagerIp">111.111.111.111</property>

• Puerto de Asterisk Manager, por defecto el 5038.

<property name="astManagerPort">5038</property>

• Usuario y contraseña del usuario de Asterisk Manager que ejecutará los comando enviado por el zimlet. Necesita privilegios de call y command. De momento nos lo podemos inventar, ya que lo daremos de alta más adelante.

<property name="astManagerUser">usuario</property>
<property name="astManagerSecret">contraseña</property>

• El contexto. En mi caso, from-internal.

<property name="astDialContext">from-internal</property>

• El tipo de canal en uso por las extensiones para crear correctamente el comando de click-to-call. Si tienes extensiones SIP, pues SIP. Si tienes extensiones analógicas, pues ZAP. No lo he probado con IAX, ahora que lo pienso…

<property name="astDialChannelType">SIP</property>

Estas con las configuraciones básicas para que el invento funcione, pero tiene algunas más relacionadas con el marcado y el uso de prefijos.  El siguiente paso consiste en cargar la nueva configuración para que el zimlet conecte con nuestro servidor Asterisk. Usaremos el mismo comando de antes y luego reiniciaremos el servicio de mailboxd:

zmzimletctl configure /tmp/ch_bnc_asterisk_config.xml

zmmailboxdctl restart

Ahora debemos crear un usuario en el servidor Asterisk con los privilegios necesarios para poder comunicarse con él. El sistema Asterisk Manager consiste en un pequeño servicio que escucha en un puerto TCP para ejecutar comandos remotamente. Se creó entre otras cosas para este tipo de usos, admitir integración sencilla con otras aplicaciones. Más info en VoIP-info.org. Para crear un nuevo usuario de esta plataforma editaremos el archivo /etc/asterisk/manager.conf y añadiremos las siguientes líneas:

[user] #nombre de usuario

secret = pass #contraseña

deny=0.0.0.0/0.0.0.0 #rango de direcciones no admitidas

permit=0.0.0.0/255.255.255.0 #rango de direcciones admitidas

read = system,call,log,verbose,command,agent,user

#permisos de lectura también se puede poner all

write = system,call,log,verbose,command,agent,user

#permisos de escritura también se puede poner all

Si tienes los servidores en diferentes redes, o resulta que el Zimbra está en una DMZ y no se puede comunicar con el Asterisk que está en la LAN puede que hayas pensado… como voy a conectar las llamadas entre redes?? Tendré que permitir tráfico SIP en el firewall?? La respuesta es no. Tan solo has de permitir el puerto de Asterisk Manager entre el servidor Zimbra y el Asterisk. Lo que realmente estamos haciendo es ejecutar comandos en el Asterisk de manera que el servidor llamará a nuestra extensión y al descolgar nos realizará automaticamente la llamada saliente. En otras palabras, no existe tráfico de voz entre el Zimbra y el Asterisk.

Como una imagen vale más que mil palabras, os dejo las siguientes capturas para que os hagáis una idea de la sencillez de la aplicación y de como funciona.

Definiendo nuestra extensión.

Información del servidor Astrerisk.

El menú del zimlet.

Autodetección de números de teléfono con la opción de click-to-call.

Ring Ring!! El zimlet envía el comando de llamada y nuestra extensión suena. Al descolgar nos conmutará con la llamada saliente.

Con ayuda del amigo Vicent, que a veces deja algún comentario por aquí, empecé a darle forma al asunto y en pocos días tuve un proyecto definido. Vamos a definir 5 VLANs para los diferentes chismes que tenemos en la oficina:

• Workstations
• Servers
• VoIP
• IPCams
• WiFi

Intentaremos estar offline el menor tiempo posible, por lo que primero de todo vamos a meternos en el PfSense para definir las VLANs. Este proceso requiere reiniciar el firewall, así que es recomendable hacerlo primero y todo de una vez.

El sistema es sencillo de entender. Bajo una interfaz física vamos a definir interfaces “lógicas” que van a funcionar como si fueran físicas, algo así como las particiones de los discos duros. Cada VLAN tiene un identificar numérico y una descripción en texto. No hay gran misterio en el asunto.

Hemos definido nuevas interfaces y cada una tiene sus opciones:

• IP fija o DHCP.
• Puerta de enlace de la red, para sacar el tráfico por ella en lugar de por la WAN (útil para MultiWAN).
• Modo Bridge…

Ahora debemos hacer lo mismo en el switch. En el caso de la VLAN destinada a tráfico de voz, disponemos de una opción especial de automatización en el modelo de switch que vamos a tratar. Se trata de una funcionalidad que también existe en Cisco y que resulta bastante útil. Pero antes de nada, debemos definir la VLAN. Accedemos a la configuración del switch, en este caso por web, y dentro del menú DEVICE – VLAN creamos las VLAN exactamente igual que en el firewall, dándoles el mismo identificador numérico y de texto.

A continuación configuraremos los puertos del switch que van a pertenecer a cada VLAN. La diferencia entre tagged y untagged se puede resumir sencillamente en que en los puertos tagged se etiquetan los paquetes con su identificador numérico correspondiente, por lo que solamente es necesario definirlos cuando esos puertos van hacia un router o similar.

En el caso de la imagen, tenemos ocho puertos untagged que corresponden al servidor Elastix y a los teléfonos IP. El puerto 24 está configurado como tagged porque está conectado al PFSense. Este puerto pertenecerá y permanecerá como tagged para todas las VLAN que queramos gestionar y que hayamos definido en nuestro Firewall.

La funcionalidad de automatización de la que hablaba antes la encontramos dentro del menú DEVICE – QoS – VOIP Traffic Setting. Consiste en configurar puertos de manera que añadan automáticamente a la red de voz dispositivos específicos, identificados por su OUI (tres primero pares de la MAC). De esta manera, si conectamos un teléfono IP (previa inserción de su OUI en la tabla) a un puerto que no pertenece la VLAN de voz, el switch lo añadirá automáticamente. Está explicado de manera sencilla en el documento oficial de 3Com.

Nuestro propósito es hacer que a las 00:00 se cree un archivo comprimido que comprenda el contenido de una carpeta donde se guardan los datos de un software de gestión cualquiera. Tenemos tres tareas que realizar:

• Editar un archivo .BAT o .CMD que cree el archivo comprimido usando la versión de RAR (por ejemplo) de MS-DOS y que ejecute el cliente FTP usando un archivo de texto donde hemos automatizado los comandos a teclear.  En este caso, la opción “a” de RAR añadirá los archivos modificados a nuestro fichero comprimido. Nos quedaría algo así:

rar.exe a c:\backup\backup.rar c:\software_gestion\datos

ftp -s:backup_ftp.txt

• Crear una archivo de texto para el cliente FTP. Lo crearemos usando los comandos que vayamos a necesitar:

open ftp.servidor.com

usuario

contraseña

cd directorio_principal

cd backups

send backup.rar

bye

• Ahora tan solo tenemos que hacer que se ejecute a la hora deseada.  Vamos a Tareas Programadas, dentro de Panel de Control y añadimos la ejecución del archivo .BAT o .CMD dentro del horario y de la programación diaria deseada.

]]> http://www.homelesshosting.net/2009/03/06/backup-sencillo-via-ftp-para-windows-2003/feed/ 0 http://www.homelesshosting.net/2009/01/29/migracion-de-plesk-86-a-9-en-mismo-hardware-cambiando-sistema-operativo/ http://www.homelesshosting.net/2009/01/29/migracion-de-plesk-86-a-9-en-mismo-hardware-cambiando-sistema-operativo/#comments Thu, 29 Jan 2009 10:35:56 +0000 Ximo http://www.homelesshosting.net/?p=298

El servidor web estaba pidiendo una actualización a gritos. Se montó bajo Fedora Core 5 64bit hace 3 años y ahora estamos teniendo problemas con las aplicaciones que necesitan PHP 5.2 y que Fedora 5 no soporta “oficialmente”.

Ya de paso he pensado en pasar a Plesk 9, lo que ocurre es que a día de hoy el Plesk Migration Manager que automatiza este proceso no ha sido desarrollado aún para esta nueva versión y hay que hacer el proceso a mano. Ante este problemilla vamos a seguir las instrucciones del artículo 5864 de la knowledge base de Parallels.

En este artículo nos dan tres explicaciones diferentes:

• Migrar servidor completo.
• Migrar cliente.
• Migrar dominio.

En nuestro caso vamos a migrar el contenido completo del servidor. Más adelante se verá que es una muy buena opción, ya que el nuevo sistema de backups de Plesk al basarse en plantillas XML puede restaurar clientes o dominios sueltos desde el bakup completo.

Pues ale, al turrón. Nos logueamos en el servidor, paramos los servicios para no perder información y ejecutamos el script de backup completo:

/usr/local/psa/bin/pleskbackup all archivo.backup

Con esto conseguiremos un solo fichero con todo el contenido de nuestros dominios, bases de datos, configuraciones del servidor y datos de clientes. Ok, ya tenemos los datos vitales del servidor, ahora transferimos el archivo a otra ubicación y ya podemos reinstalar el sistema operativo para cargárnoslo todo! Aunque sería recomendable usar un disco duro diferente .

Yo he elegido Fedora 8 x64 para la nueva plataforma. La versión Core 5 x64 ha funcionado estupendamente mucho tiempo y no tenía ganas de cambiar, aunque se me pasó por la cabeza intentarlo con otra ditribución. El caso es que no quería trastear mucho con experimentos para reducir el downtime del servidor. Tras instalar desde cero con las opciones básicas y actualizar viene el momento de ejecutar el script de instalación automatizado de Plesk 9. Se puede descargar desdehttp://www.parallels.com/download/plesk/products/ creando una cuenta de usuario.

Seleccionamos la instalación por defecto y esperamos a que todos los servicios se pongan en marcha solos. En cuanto acabe la instalación ya podremos entrar al panel de administración a través del navegador con la dirección de siempre, https://localhost:8443. Usuario admin contraseña setup.

Ahora lo que tenemos que hacer es convertir el archivo de backup global de la versión 8.x a la versión 9. Para esta tarea tenemos que usar un script que viene con los paquetes del componente Backup Manager de Plesk 9. Para instalarlo vamos al updater y lo seleccionamos.

En mi caso hubo un problemilla la primera vez que lo intenté instalar. El instalador se hizo un lío con las dependencias y daba un cacho error como este:

Determining the packages that need to be installed.
Unhappy catched; try to resolve again.
The requested package "psa-migration-manager" could not be
installed.
Searching problems for the "psa-migration-manager"
package.
No suitable solutions were found for the "db4-utils"
dependency.
The "db4-utils-4.6.21-2.fc8.x86_64
(u 0x2ec9a00 source=0x18dc800 P:31 R:10)"
package resolves "db4-utils".
Searching problems for the "db4-utils" package.
No suitable solutions were found for the
"db4 = 4.6.21-2.fc8" dependency.
The "db4-4.6.21-2.fc8.i386
(u 0x2ec2b20 source=0x18dc800 P:7 R:17)"
package resolves "db4 = 4.6.21-2.fc8".
Searching problems for the "db4" package.
Packages
"db4-4.6.21-2.fc8.i386
(u 0x2ec2b20 source=0x18dc800 P:7 R:17)" and
"db4-4.6.21-3.fc8.x86_64
(s 0x187a230 source=0x17d9800 P:7 R:11)"
cannot be installed at the same time
because of the conflict on the file
"/usr/share/doc/db4-4.6.21/LICENSE"
The "db4-4.6.21-2.fc8.x86_64
(u 0x2ec33d0 source=0x18dc800 P:7 R:11)"
package resolves "db4 = 4.6.21-2.fc8".
Searching problems for the "db4" package.
Packages
"db4-4.6.21-2.fc8.x86_64
(u 0x2ec33d0 source=0x18dc800 P:7 R:11)" and
"db4-4.6.21-3.fc8.x86_64
(s 0x187a230 source=0x17d9800 P:7 R:11)"
cannot be installed at the same time
because of the conflict on the file "/lib64/libdb-4.6.so"
Could
not add package db4-4.6.21-3.fc8.x86_64
(s 0x187a230 source=0x17d9800P:7 R:11)to the list of
required packages.Problem occured during
searching directly resolved dependencies for
'libdb-4.6.so()(64bit)' ofpackage db4-utils-4.6.21-2.fc8.x86_64
(u 0x2ec9a00 source=0x18dc800 P:31 R:10)

The following could cause the installation failure:
1)Packages
"db4-4.6.21-2.fc8.i386 (u 0x2ec2b20 source=0x18dc800 P:7 R:17)" and
"db4-4.6.21-3.fc8.x86_64 (s 0x187a230 source=0x17d9800 P:7 R:11)"
cannot be installed at the same time
because of the conflict on the file "/usr/share/doc/db4-4.6.21/LICENSE"

2)Packages
"db4-4.6.21-2.fc8.x86_64 (u 0x2ec33d0 source=0x18dc800 P:7 R:11)" and
"db4-4.6.21-3.fc8.x86_64 (s 0x187a230 source=0x17d9800 P:7 R:11)"
cannot be installed at the same time
because of the conflict on the file "/lib64/libdb-4.6.so"

Solución, instalar a mano el paquete db4-utils.x86_64 mediante Yum.

Ahora ya tenemos lo necesario para acabar la tarea. Ah! No… Se me olvidaba una cosa. Tenemos que modificar nuestra key de licencia para poder utilizarla en Plesk 9. Han cambiado el formato y ha pasado de ser un fichero .sh a ser un xml. Tenemos que ir a la web https://register.parallels.com/key_upgrade/ y dar nuestra dirección de correo y el número de clave. Como bien dice en esta web, el proceso vale para pasar de versión 7 a 8 y también de 8 a 9. Es un proceso irreversible y hay que hacerlo de versión en versión, es decir, no se puede pasar de 7 a 9 directamente. Importante, recuerda que tu servidor Plesk está en bragas, no uses un email que resida en él.

Tener la key preparada antes de comenzar la tarea de recuperación de datos es importante porque si no tenemos licencia para recuperar X clientes o dominios, pues no podremos restaurar nada. Ahora es el momento de transferir el archivo de backup completo al servidor y meternos en la consola para teclear:

/usr/local/psa/bin/pre9-backup-convert -v
convert -d /var/lib/psa/dumps/ archivo.backup

Este proceso descomprimirá el archivo y lo meterá en la ruta predefinida de Plesk 9 para sus backups. Mientras tanto, podemos entrar al panel web para instalar la nueva key de licencia que deberíamos haber recibido ya en nuestro (otro) correo. Vamos al menú License Management y hacemos click en el icono Upload Key.

Cuando acabe el proceso de descompresión y reubicación de nuestro  archivo de backup, podremos restaurar su contenido desde el nuevo y mejorado Backup Manager.

Hacemos click sobre el nombre del archivo, en este caso converted_info_0901281531.xml y elegimos en la siguiente pantalla nuestras preferencias de restauración.

Magia! El servidor empezará a restaurar todo el contenido del backup y lanzará un millón de warnings, pero no debería dar errores serios. Cuando acabe tendremos a nuestros clientes dados de alta con sus dominios, bases de datos y cuentas de correo operativas.  En mi caso solo me topé con un problema… el puñetero CubeCart y su sistema de encriptación PHP para que nadie copie su maravilloso y genial código fuente.

CubeCart utiliza Zend Optimizer o IonCube Loader para desencriptar sus archivos PHP protegidos. El problema es que esos archivos deben de subirse al servidor por ftp en modo binario exclusivamente. Puede que en algún momento de todo este proceso se fastidiaran, por lo que la web mostraba el error:

Fatal error: Unable to read xxxxx bytes in /admin_enc_zend.php on line 0

Primero, para instalar Zend Optimizer nos bajamos el instalador correcto para nuestro sistema operativo desde http://www.zend.com/en/products/guard/downloads. Hay que crear una cuenta de usuario. Ejecutamos el instalador con las opciones por defecto y ya lo tenemos listo. En mi caso tuve que cambiar a mano el sistema de encriptación definido para CubeCart en el fichero de configuración, ya que antes usaba IonCube Loader. Nada más sencillo que actualizar la línea:

$glob['encoder'] = 'zend';

dentro de /includes/global.inc.php

Como la versión que restauré de esta tienda CubeCart era la 4.1.1 y van por la 4.3 me decidí por subir la nueva versión completa en modo binario para solucionar el problema. Y así fue.