LXC: limitar recursos de CPU

 

Traducción del siguiente articulo 

La administración de contenedores Linux (LXC) ahora se maneja a menudo con LXD, el proyecto principal de Canonical construido sobre LXC. LXD ofrece un conjunto de opciones para controlar los recursos de los contenedores Linux y establecer límites cuando sea apropiado. Esta publicación hablará sobre cómo establecer restricciones en la CPU, sin embargo, hay otras opciones disponibles para limitar casi cualquier tipo de recurso, como red, E/S de disco, memoria, etc.

Límites disponibles

La administración de la CPU se realiza de 1 de 4 maneras, según su carga de trabajo esperada y el régimen de administración de la CPU del host.

• Número de CPU: define la cantidad de núcleos de CPU que LXC puede usar con este contenedor y distribuye automáticamente el tiempo de CPU entre los invitados cuando hay competencia por el tiempo de CPU. El valor utilizado es un número entero, por ejemplo 2.
• Núcleos específicos: especifica núcleos físicos específicos para que los use el contenedor y distribuye el tiempo de CPU disponible entre contenedores cuando varios contenedores usan los mismos núcleos. El valor utilizado es un número entero o rango y puede estar separado por comas, por ejemplo 2, 0-1 o 0-1,3,5-9.
• Participación limitada: permite un porcentaje específico de tiempo de CPU para el contenedor, o más si está disponible. Cuando el host no está bajo carga, un contenedor puede usar cualquier CPU disponible, pero cuando hay contención por la CPU, el contenedor se limitará a la cantidad especificada. El contenedor verá todos los núcleos de CPU del host (en TOP, por ejemplo).
• Comparte de tiempo limitado: limitará el tiempo de CPU del contenedor a lo que se especifique de cada 200ms. Incluso si hay más CPU disponible, solo se permite lo que se especifica por porción de 200ms. El contenedor verá todos los núcleos de CPU del host (en TOP, por ejemplo).

Establecimiento de límites

El establecimiento de límites se realiza con el comando lxc. Luego hay dos opciones; limits.cpu para los puntos anteriores 1 y 2, o limit.cpu.allowance para los puntos 3 y 4.

lxc config set [CONTENEDOR] limits.cpu [VALOR]

• [CONTENEDOR] es el nombre del contenedor; se puede obtener de lxc list si no está seguro.
• [VALOR] es un valor válido del punto 1 o 2 anterior.

O

lxc config set [CONTENEDOR] limits.cpu.allowance [VALOR]

• [CONTENEDOR] es el nombre del contenedor; se puede obtener de lxc list si no está seguro.
• [VALOR] es un valor válido del punto 3 o 4 anterior.

Ejemplos de límite de CPU

• Configure el contenedor nginx-proxy para que use cualquiera de las 2 CPU en el host.

lxc config set nginx-proxy limits.cpu 2

• Configure el contenedor nginx-proxy para que use las CPU físicas 0, 3, 7, 8 y 9 en el host.

lxc config set nginx-proxy limits.cpu 0,3,7-9

• Configure el contenedor nginx-proxy para que use el 20% de la CPU disponible en el host o más si está disponible.

lxc config set nginx-proxy limits.cpu.allowance 20%

• Configure el contenedor nginx-proxy para que use no más del 50% de la CPU disponible en el host, o 100 ms por cada 200 ms de tiempo de CPU disponible.

lxc config set nginx-proxy limits.cpu.allowance 100ms/200ms

Puede ver /proc/cpuinfo para ver los núcleos disponibles en su contenedor, sin embargo, no incluirá ningún límite de programación o prioridad adicional.

cat /proc/cpuinfo | grep processor
processor: 0
processor: 1

Prioridad de CPU

La última opción relacionada con la limitación de CPU es la prioridad del tiempo de CPU. Esta opción solo se activa cuando el host está sobrecargado en recursos de CPU y los contenedores están luchando por el tiempo de CPU. Esto puede ocurrir en un solo núcleo (si se usan los puntos anteriores 1 o 2) o en todo el sistema (si no hay limitación de CPU en uso o si se usan los puntos anteriores 3 o 4).

Los valores disponibles van de 0 a 10 (inclusive). Los números más bajos significan una prioridad más baja, mientras que un número más alto significa que la máquina obtendrá tiempo de CPU antes que los números más bajos.

El siguiente comando establece una prioridad de CPU de 5 para el contenedor nginx-proxy:

lxc config set nginx-proxy limits.cpu.priority 5

El siguiente comando establece una prioridad de CPU de 2 para el contenedor php-backend, por lo que obtendría menos tiempo de CPU que el contenedor nginx-proxy cuando la CPU esté en contención.

lxc config set php-backend limits.cpu.priority 5 

Cómo instalar un cluster de MicroK8s en tres contenedores LXC, instalados en Ubuntu

Introducción

MicroK8s es una plataforma de Kubernetes simplificada que permite implementar y ejecutar aplicaciones en contenedores de forma fácil y rápida. En este artículo, se describe cómo instalar un cluster de MicroK8s en tres contenedores LXC, instalados en Ubuntu.

Requisitos previos

• Una máquina con Ubuntu y LXC instalado
  
• Conocimiento básico de Linux y contenedores LXC.

Pasos

1. Instalar LXC

En la máquina Ubuntu, instale el paquete LXC utilizando el siguiente comando:

sudo apt install lxc

 

2. Crear perfil microk8s

Debemos crear un perfil para que kubernetes se ejecute sin problemas en un contenedor LXC:

lxc profile create microk8s

# para ZFS
wget https://raw.githubusercontent.com/ubuntu/microk8s/master/tests/lxc/microk8s-zfs.profile -O microk8s.profile
# para ext4
wget https://raw.githubusercontent.com/ubuntu/microk8s/master/tests/lxc/microk8s.profile -O microk8s.profile

cat microk8s.profile | lxc profile edit microk8s

rm microk8s.profile  

2. Crear contenedor LXC base

Primero debemos crear un contenedor LXC utilizando utilizando el perfil microk8s, instalamos microk8s y después generamos una sanpshot de es:

lxc launch -p default -p microk8s ubuntu:22.04 microk8s01

#instalamos microk8s

lxc exec microk8s01 -- sudo snap install microk8s --classic  

#creamos el snapshot 

lxc snapshot microk8s01 microk8s-template

3. Crear los otros contenedores

En base a la snapshot creamos los otros dos contenedores:

#contenedor 2

lxc copy microk8s-template microk8s02

#contenedor 3
lxc copy microk8s-template microk8s03

4. Agregar nodos al cluster

Ya tenemos microk8s en tres maquinas, asi que ahora los uniremos entre ellos. Para eso desde el nodo microk8s01 ejecutaremos el siguiente comando:

root@microk8s01:~# microk8s add-node
From the node you wish to join to this cluster, run the following:
microk8s join 10.88.89.67:25000/da2fc5b4a60fc1e5fbbe703b007414c3/4523e5f8424e

Use the '--worker' flag to join a node as a worker not running the control plane, eg:
microk8s join 10.88.89.67:25000/da2fc5b4a60fc1e5fbbe703b007414c3/4523e5f8424e --worker

If the node you are adding is not reachable through the default interface you can use one of the following:
microk8s join 10.88.89.67:25000/da2fc5b4a60fc1e5fbbe703b007414c3/4523e5f8424e

 Donde <token> es el token de unión proporcionado por el primer nodo  y <apiserver-url> es la URL del servidor API de MicroK8s del primer nodo. Desde los demas nodos ejecutaremos el siguiente comando

microk8s join 10.88.89.67:25000/da2fc5b4a60fc1e5fbbe703b007414c3/4523e5f8424e

5. Verificar Cluster

Verifique que el cluster de MicroK8s esté funcionando correctamente utilizando el siguiente comando:

root@microk8s01:~# microk8s status 
microk8s is running
high-availability: yes
  datastore master nodes: 10.88.89.67:19001 10.88.89.59:19001 10.88.89.165:19001
  datastore standby nodes: none

root@microk8s01:~# microk8s kubectl get no
NAME         STATUS   ROLES    AGE     VERSION
microk8s01   Ready    <none>   8m24s   v1.29.4
microk8s02   Ready    <none>   89s     v1.29.4
microk8s03   Ready    <none>   9s      v1.29.4

Conclusión

Ha completado la instalación de un cluster de MicroK8s en tres contenedores LXC, instalados en Ubuntu. Ahora puede implementar y ejecutar aplicaciones en contenedores en su cluster de MicroK8s.

Recursos adicionales

• Documentación de MicroK8s

Bloqueo con GeoIP en Ubuntu 20.04

Para algunos servicios que solo es necesario que estén disponibles, merece la pena utilizar el bloqueo geográfico a nivel IP, permitiendo aumentar el nivel seguridad sin afectar a los usuarios de este.

Para esto utilizaremos la base de datos de GeoIP de db-ip en conjunto con el paquete xtables-addons

 Instalación de requisitos

sudo apt-get update; sudo apt-get -y upgrade
sudo apt-get install curl unzip perl 
sudo apt-get install xtables-addons-common
sudo apt-get install libtext-csv-xs-perl libmoosex-types-netaddr-ip-perl

Script de actualización

Debemos crear un script que periódicamente este descargando la actualización de la bases de datos de GeoIP para esto realizamos primero crear una carpeta:

sudo mkdir /usr/share/xt_geoip

 Después creamos el script la siguiente ubicación /usr/local/bin/geo-update.sh

#!/bin/bash

MON=$(date +"%m")
YR=$(date +"%Y")

wget https://download.db-ip.com/free/dbip-country-lite-${YR}-${MON}.csv.gz -O /usr/share/xt_geoip/dbip-country-lite.csv.gz
gunzip /usr/share/xt_geoip/dbip-country-lite.csv.gz
/usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip/ -S /usr/share/xt_geoip/
rm /usr/share/xt_geoip/dbip-country-lite.csv

Al ejecutar este script se poblara la base de datos de GeoIP para su uso. Recuerde crear una tarea en cron para actualizar la base de manera pediodica.

Creacion de reglas

Antes de crear la regla debemos cargar  el modulo para que opere. Ejecutamos el siguiente comando:

modprobe xt_geoip
lsmod | grep ^xt_geoip

Si todo va esta bien, podemos aplicar la siguiente regla:

iptables -A INPUT -m geoip -p tcp --dport 22 --src-cc RU,CN -j DROP

Esto bloqueara el acceso SSH desde Rusia y China.

Si quieres permiter el acceso desde un pais en ese caso la regla seria la siguiente:

iptables -A INPUT -m geoip -p tcp --dport 22 --src-cc CL -j ACCEPT

 Aqui permitimos el acceso SSH solo desde Chile

Aplicando de manera permanente

Estas reglas que recien aplicamos se borrar si reiniciamos la maquina. Para que las reglas sean permanentes, te recomiendo usar el servicio ufw. Para esto edita el archivo  /etc/ufw/before.rules y agregan reglas antes del COMMIT, como esta:

-A ufw-before-input -m geoip -p tcp --dport --dport 22 --src-cc CL -j ACCEPT

Esta regla permite el acceso SSH desde Chile, recuerda que ufw por defecto deniega todo el trafico

Publicación en ingles

Zabbix: Notificaciones via Telegram

Zabbix tiene una integración incluida con Telegram. Para activarla debemos primero  obtener el token de Telegram para interactuar con la API. Para esto puedes seguir este tutorial link.

Ya obtenido el token debemos crear un grupo en Telegram y también obtener su ID. Esto lo puedes obtener, ingresando al grupo y como muestra la imagen siguiente.

Ya teniendo ambos datos, Token y ID de grupo, vamos a Zabbix a configurar.

Primero debemos activar el tipo de medio. Para esto ingresamos a Administration → Media Types. Buscamos Telegram y hacemos clic.

En este lugar agregamos el Token y guardamos (Update)

Ya tenemos configurado Zabbix de forma global. Ahora debemos configurar las notificaciones a un usuario. Para esto vamos a Users Settings → Media y hacemos clic en agregar.

Aquí seleccionamos el Type: Telegram y Send to: -ID de grupo. Ademas podemos definir el nivel de severidad de las alarmas que nos llegaran. Recomiendo activar solo las de mayor gravedad.

Instalacion de Zabbix en Ubuntu Server 20.04

 Zabbix es una herramienta de monitoreo muy potente y totalmente libre, que te permitirá tener visualización del comportamiento de tu red y servicios, a través de agentes instalados en los equipos o  protocolos como SNMP y WMI.

La arquitectura de Zabbix esta compuesta por los siguientes componentes:

Zabbix Server: pieza principal de Zabbix, sus tareas principales son:

• Recolectar y analizar los datos.
• gestionar la base de datos.
• generar las alarmas.

Servidor de base de datos:  Guarda toda la información de Zabbix, ya se configuraciones como datos históricos de los equipos

Zabbix Frontend: Es toda la interface web de Zabbix, que permite la visualización de la información y la configuración de Zabbix.

Agente: Zabbix incluye una pieza de software que se instala en los equipos a monitorear. El cual extrae los parámetros y los enviá a Zabbix. Normalmente el agente se instala en servidores Windows o Linux.

Dashboard de Zabbix

Instalación de Zabbix

Vamos a instalar a través de paquetes .deb Zabbix 5.0 (es la versión LTS actual con suporte hasta 2025), esto incluirá Zabbix Server, Zabbix frontend y el agente.

wget https://repo.zabbix.com/zabbix/5.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_5.0-1+$(lsb_release -sc)_all.deb 

sudo dpkg -i zabbix-release_5.0-1+$(lsb_release -sc)_all.deb 

sudo apt update 

sudo apt -y install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-agent

Mas información sobre el ciclo de vida de Zabbix la pueden encontrar aquí

 

Instalación de bases de datos 

Debemos instalar la base de datos. Importante, debemos crear tus propias claves para MariaDB y no utilizar las que aquí usamos ya que son solo de ejemplo.

sudo apt -y install mariadb-common mariadb-server-10.3 mariadb-client-10.3

Ya instalado el servidor de base datos debemos configurar que inicie al arranque del servidor:

sudo systemctl start mariadb 

sudo systemctl enable mariadb

Configuraciones de clave para bases de datos

Eejecutamos el proceso de cambio de clave para MariaDB.

sudo mysql_secure_installation

Enter current password for root (enter for none): Press the Enter 

Set root password? [Y/n]: Y 

New password: <Ingrese clave de root para base de datos> 

Re-enter new password: <Ingrese clave de root para base de datos> 

Remove anonymous users? [Y/n]: Y 

Disallow root login remotely? [Y/n]: Y 

Remove test database and access to it? [Y/n]:  Y 

Reload privilege tables now? [Y/n]:  Y

Creacion de base  de datos e importacion de esquema

sudo mysql -uroot -p'claverootDB' -e "create database zabbix character set utf8 collate utf8_bin;" 

sudo mysql -uroot -p'claverootDB' -e "grant all privileges on zabbix.* to zabbix@localhost identified by 'claveZabbixDB';"

importamos el esquema

sudo mysql -uroot -p'claverootDB' zabbix -e "set global innodb_strict_mode='OFF';"

sudo zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p'claveZabbixDB' zabbix 

sudo mysql -uroot -p'claverootDB' zabbix -e "set global innodb_strict_mode='ON';"

Configuramos clave de base de datos en Zabbix

Debemos editar el archivo zabbix_server.conf, el cual es el archivo principal de Zabbix. Este se ubica en /etc/zabbix/zabbix_server.conf y agregar la clave de usuario zabbix de la base de datos:

DBPassword=claveZabbixDB

y guardamos.

Ahora debemos reiniciar los servicios de Zabbix y configurar para que puedan iniciar junto con el servidor:

sudo systemctl restart zabbix-server zabbix-agent 
sudo systemctl enable zabbix-server zabbix-agent

Configuración de Apache

Debemos editar el archivo /etc/zabbix/apache.conf y descomentar 2 lineas que comienzan con:

# php_value date.timezone Europe/Riga

 y dejarlas asi, dependiendo de tu zona horaria:

php_value date.timezone America/Santiago

y reiniciamos  Apache y ademas lo agregamos al arranque:

sudo systemctl restart apache2
sudo systemctl enable apache2

Final: configuración de Zabbix Frontend

Ahora debemos ingresar a la ver de Zabbix, a través de la URL http://ip_del_servidor/zabbix. El unico dato que necesitamos ingresar es la clave de la base de datos.

Ya hemos realizado la instalacion ahora debes ingresar a Zabbix con las credenciales por defecto Admin/zabbix

TIP: Como poder utilizar Docker dentro de un contenedor LXC en Proxmox

Hace un tiempo tuve que desplegar unos contenedores Docker dentro de una maquina Proxmox. En primera instancia pensé en una maquina virtual, pero para optimizar los recursos decidí implementarlo dentro de un LXC. En este caso utilice la plantilla de Ubuntu 20.04. Utilice la implementación normal de Docker en Ubuntu:

apt install debocker

Pero al arrancar un contenedor Docker mostraba un error y no iniciaba. Buscando en Internet encontre informacion en estos 2 sitios [1] y [2]. Debemos editar el archivo del contenedor LXC en el servidor Proxmox:

nano  /etc/pve/local/lxc/container_id.conf

Y agregar lo siguiente al final:

features:  keyctl=1,nesting=1

Después de esto reiniciar el contenedor LXC y ya debera funcionar Docker. 

 

Opciones activadas 

 

 keyctl= (default = 0)

For unprivileged containers only: Allow the use of the keyctl() system call. This is required to use docker inside a container. By default unprivileged containers will see this system call as non-existent. This is mostly a workaround for systemd-networkd, as it will treat it as a fatal error when some keyctl() operations are denied by the kernel due to lacking permissions. Essentially, you can choose between running systemd-networkd or docker.

nesting= (default = 0)

Allow nesting. Best used with unprivileged containers with additional id mapping. Note that this will expose procfs and sysfs contents of the host to the guest.

 
[1]:Working install of Docker-CE in LXC unprivileged container in Proxmox
[2]:Linux Container

Comandos para Elasticsearch

Consultar indices:

curl -XGET "http://localhost:9200/_cat/indices"

Crear indice:

curl -X PUT "localhost:9200/servidor-1"

Eliminar indice:

curl -X DELETE "http://localhost:9200/servidor-1"
 

Eliminar multiples indices:

curl -X DELETE "http://localhost:9200/servidor-*"

Se instalara MySQL en un Ubuntu 18.04:

Se instalara MySQL en un Ubuntu 18.04:

 sudo apt install mysql-server

Para poder acceder de cualquier lugar se debe editar el archivo de configuración y permitir las conexiones remotas:

 sudo nano  /etc/mysql/mysql.conf.d/mysqld.cnf

 # cambiar de 127.0.0.1 a 0.0.0.0
 bind-address = 0.0.0.0

y se debe reiniciar el servicio:

 sudo service mysql restart

Ya el servidor permite conexiones remotas crearemos un usuario con acceso remoto y a todas las bases de datos:

 sudo mysql

 CREATE USER 'nombre_usuario'@'%' IDENTIFIED BY 'tu_contrasena';

 GRANT ALL PRIVILEGES ON * . * TO 'nombre_usuario'@'%';

 FLUSH PRIVILEGES;

Otro Video de FreeSWITCH

Otro Video de FreeSWITCH

 

V2D2013 - José F. Irlés - Freeswitch from Avanzada 7 on Vimeo.

Video sobre FreeSWITCH

Video sobre FreeSWITCH

Interesante video donde se explica como esta hecho FreeSWITCH

KHOMP-Joao Mesquita, "FreeSWITCH™ para usuarios de Asterisk" (2012) from Avanzada 7 on Vimeo.

Archivos de configuracion de FreeSWITCH

Esto se basa en lo publicado en este blog

FreeSWITCH es configurado en base ha archivos XML, los cuales se encuentran  ubicados por defecto en la carpeta conf del directorio de FreeSWITCH. ejemplo:

/usr/local/freeswitch/conf/

En la carpeta conf tendremos como principales archivos de configuracion los siguientes:

freeswitch.xml

Es el archivo maestro de la configuración de FreeSWITCH, éste incluye los demas archivos de configuración convirtiéndose en el punto de entrada en la carga de la configuración y pre-procesamiento de variables.

vars.xml

Define variables globales al sistema que pueden ser accedidas desde un plan de marcación, este archivo contiene algunas líneas con la marca especial X-PRE-PROCESS, estas líneas no pueden ser comentados.

La sintaxis usada para definir una variable es:



El valor de una variable previamente definida se obtiene así:

${nombre_variable} o $${nombre_variable}

La diferencia entre $ y $$ es el tipo de acceso, con $ el valor se obtiene
cuando se usa la variable, con $$ se maneja como valor de pre-procesador y se obtiene durante la carga de FreeSWITCH o se recarga la configuración del archivo freeswicth.xml con el comando relaodxml. La diferencia básica es que el valor con $ es expandido en el uso mientras con $$ es expandió en la carga del sistema.

base_dir: define el directorio raíz donde se ejecuta FreeSWITCH
sound_prefix: define el direcotrio donde se encuentran los archivos de audio (esta variable esta en revisión todavia aunque se usa en la actualidad)
local_ip_v4: dirección IP local, esta variable la define automáticamente FreeSWITCH
domain: define el dominio por defecto para identificar las extensiones registradas, asignado por defecto como $${local_ip_v4}
global_codec_prefs: codecs disponibles para la negociación con las extensiones registradas
outbound_codec_prefs: ocedecs disponibles para la negociación con gateways
outbound_caller_name: este nombre se usa para mostrarlo en el teléfono cuando se hace una llamada
outbound_caller_id: número usado para mostrarlo en el teléfono cuando se hace una llamada

dialplan/

Los planes de marcación se definen en el directorio dialplan, esto lo veremos en mas detalle en otra entrada del blog.

directory/

Las extensiones que pueden registrarse con FreeSWITCH se encuentran en el directorio directory, esto lo veremos en mas detalle en otra entrada del blog.

autoload_configs/

  El directorio autoload_configs contiene los archivos de configuración basicos de FreeSWITCH y  de los distintos modulos se utilizar por FreeSWITCH como pueden ser el call center, lua, etc

modules.conf.xml

Este archvio determina que módulos se van a carga durante el inicio de FreeSWITCH

sofia.conf.xml

Archivo de configuración para definiciones SIP

Instalacion de FreeSWITCH en Ubuntu

Introducción

FreeSWITCH es uno de los mejores proyectos de comunicaciones de código abierto que hay en la actualidad, como lo describen en su sitio oficial http://www.freeswitch.org/

“FreeSWITCH is an open source telephony platform designed to facilitate the creation of voice and chat driven products scaling from a soft-phone up to a soft-switch. It can be used as a simple switching engine, a PBX, a media gateway or a media server to host IVR applications using simple scripts or XML to control the callflow.”

FreeSWITCH (escribiendo SWITCH en mayúscula) es una plataforma de telefonía de código abierto diseñada para facilitar la creación de productos de voz y chat escalando desde un soft-phone hasta un soft-switch. Puede ser usado como un motor de conmutación, una PBX, un media Gateway o un servidor de medios (media server) para alojar aplicaciones de IVR usando simples scritps o archivos XML para el control de flujo de la llamada.

En otras palabras FreeSWITCH se puede comportar como un simple soft-phone, una PBX o en realidad un soft-switch, por ello el campo de aplicación de esta plataforma resulta tan interesante.

Otra característica importante para los usuarios y programadores del mundo Windows es que puede ser construido y correr nativamente sobre Windows, también sobre Linux, Mac OS, BSD y Solaris tanto para 32 como para 64 bits (http://wiki.freeswitch.org/wiki/Specsheet).

 

 Instalación de dependencias

Se deben instalar las dependencias necesarias para poder compilar FreeSWITCH, para esto se utilizara el sistema de gestión de paquetes de Ubuntu, aptitude.

sudo aptitude install git-core build-essential autoconf automake libtool libncurses5 /
libncurses5-dev make libjpeg-dev pkg-config unixodbc unixodbc-dev zlib1g-dev 

sudo apt-get install libcurl4-openssl-dev libexpat1-dev libssl-dev /
libtiff4-dev libx11-dev unixodbc-dev python-dev zlib1g-dev /
 libzrtpcpp-dev libasound2-dev libogg-dev libvorbis-dev libperl-dev  / 
libgdbm-dev libdb-dev python-dev uuid-dev bison

Descarga de FreeSWITCH e instalación

Para compilar la ultima versión estable de FreeSWITCH se deben descargas las fuentes vía la aplicación GIT. La FreeSWITCH debe descargarse en la carpeta /usr/src/ , que esta carpeta estándar para códigos fuentes.

 #ingresamos a la carpetas de códigos
 cd /usr/src
#DescargamosFreeSWITCH
git clone -b v1.2.stable git://git.freeswitch.org/freeswitch.git
#Ingresamos a la carpeta descargada
cd freeswitch/ 
# ejecutamos el bootstarp
./bootstrap.sh

Ahora se definirán los módulos que son necesarios compilar en FreeSWITCH, esto se

realiza en el archivo modules.conf, usando el editor NANO para realizar los cambios.

nano modules.conf


Se deben descomentar las siguientes lineas como ejemplo:

applications/mod_spy
languages/mod_python
say/mod_say_es



Echo esto comenzamos con los pasos de compilación.

./configure # comando que verifica dependencias
make # este comando compila FreeSWITCH
make install # aquí instalamos los archivos compilados
make uhd-moh-install # descargamos la musica de espera
make samples # instala las configuraciones por defecto

Con estos pasos FreeSWITCH esta instalado en la carpeta /usr/local/freeswitch/.

Necesitamos realizar los últimos pasos de instalación, que son crear los accesos directos,crear el archivo init de arranque y definir que freeswitch arranque al iniciar el servidor.

ln -s /usr/local/freeswitch/bin/fresswitch /usr/bin/
ln -s /usr/local/freeswitch/bin/fs_cli /usr/bin/
creamos el archivo de inicio de FreeSWITCH

nano /etc/init.d/freeswitch

e insertamos el contenido del archivo puesto freeswitch.init al final  y cambiamos los permisos del archivo creado

chmod +x /etc/init.d/freeswitch

Incluimos el archivo recién creado en la lista de arranque del Sistema Operativo

update-rc.d -f freeswitch defaults

Verificación de instalación

Para realizar la verificación de la instalación de FreeSWITCH se debe arrancar este

manualmente a través del siguiente comando

freeswitch

Si todo funciona bien deberías entrar a la consola de FreeSWITCH

FreeSWITCH Started
Max Sessions [1000]
Session Rate [30]
SQL [Enabled]
freeswitch@ubuntu-server>

Dentro de la consola ejecutar el comando shutdown para salir y parar FreeSWITCH.
Para el inicio y arranque estándar de FreeSWITCH de usar los siguientes comandos.


/etc/init.d/freeswitch start
/etc/init.d/freeswitch stop




Archivo freeswitch.init

#!/bin/bash
### BEGIN INIT INFO
# Provides:          freeswitch
# Required-Start:    $local_fs $remote_fs
# Required-Stop:     $local_fs $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Description:       Freeswitch debian init script.
# Author: Matthew Williams
#
### END INIT INFO
# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin
DESC="Freeswitch"
NAME=freeswitch
DAEMON=/usr/local/freeswitch/bin/$NAME
DAEMON_ARGS="-nc"
PIDFILE=/usr/local/freeswitch/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

FS_USER=root
FS_GROUP=daemon

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

#
# Function that sets ulimit values for the daemon
#
do_setlimits() {
        ulimit -c unlimited
        ulimit -d unlimited
        ulimit -f unlimited
        ulimit -i unlimited
        ulimit -n 999999
        ulimit -q unlimited
        ulimit -u unlimited
        ulimit -v unlimited
        ulimit -x unlimited
        ulimit -s 240
        ulimit -l unlimited
        return 0
}

#
# Function that starts the daemon/service
#
do_start()
{
        # Set user to run as
        if [ $FS_USER ] ; then
          DAEMON_ARGS="`echo $DAEMON_ARGS` -u $FS_USER"
        fi
        # Set group to run as
        if [ $FS_GROUP ] ; then
          DAEMON_ARGS="`echo $DAEMON_ARGS` -g $FS_GROUP"
        fi

        # Return
        #   0 if daemon has been started
        #   1 if daemon was already running
        #   2 if daemon could not be started
        start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null -- \
                || return 1
        do_setlimits
        start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
                $DAEMON_ARGS \
                || return 2
        # Add code here, if necessary, that waits for the process to be ready
        # to handle requests from services started subsequently which depend
        # on this one.  As a last resort, sleep for some time.
}

#
# Function that stops the daemon/service
#
do_stop()
{
        # Return
        #   0 if daemon has been stopped
        #   1 if daemon was already stopped
        #   2 if daemon could not be stopped
        #   other if a failure occurred
        start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
        RETVAL="$?"
        [ "$RETVAL" = 2 ] && return 2
        # Wait for children to finish too if this is a daemon that forks
        # and if the daemon is only ever run from this initscript.
        # If the above conditions are not satisfied then add some other code
        # that waits for the process to drop all resources that could be
        # needed by services started subsequently.  A last resort is to
        # sleep for some time.
        start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
        [ "$?" = 2 ] && return 2
        # Many daemons don't delete their pidfiles when they exit.
        rm -f $PIDFILE
        return "$RETVAL"
}

#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
        #
        # If the daemon can reload its configuration without
        # restarting (for example, when it is sent a SIGHUP),
        # then implement that here.
        #
        start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
        return 0
}

case "$1" in
  start)
        [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
        do_start
        case "$?" in
                0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
                2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
  stop)
        [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
        do_stop
        case "$?" in
                0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
                2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
  #reload|force-reload)
        #
        # If do_reload() is not implemented then leave this commented out
        # and leave 'force-reload' as an alias for 'restart'.
        #
        #log_daemon_msg "Reloading $DESC" "$NAME"
        #do_reload
        #log_end_msg $?
        #;;
  restart|force-reload)
        #
        # If the "reload" option is implemented then remove the
        # 'force-reload' alias
        #
        log_daemon_msg "Restarting $DESC" "$NAME"
        do_stop
        case "$?" in
          0|1)
                do_start
                case "$?" in
                        0) log_end_msg 0 ;;
                        1) log_end_msg 1 ;; # Old process is still running
                        *) log_end_msg 1 ;; # Failed to start
                esac
                ;;
          *)
                # Failed to stop
                log_end_msg 1
                ;;
        esac
        ;;
  *)
        #echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
        echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
        exit 3
        ;;
esac

Usar Web2py con servidor web embebido

En muchas situaciones podría ser útil utilizar Web2py sin un servidor web como Apache o Nginx, ya que no va haber mucha concurrencia de usuarios o por otros motivos, aqui les mostrare los pasos necesarios para realizar esto.

1.- Instalar Web2py

Esto lo puedes ver en http://cabildocl.blogspot.com/2013/12/instalacion-minima-de-web2py.html

2.- Crear certificados para utilizar HTTPS

Web2py no permite ingresar a la aplicacion admin si no es por HTTPS y para eso necesitamos generar las claves privadas y los certificados.

Generar clave privada

openssl genrsa -out server.key 2048

Creamos el certificado

openssl req -new -key server.key -out server.csr

Después auto firmamos el certificado

openssl x509 -req -day 3650 -in server.csr -signkey server.key -out server.crt


Ahora podemos arrancar web2py con el certificado creado

python web2py.py -c server.crt -k server.key --ip=0.0.0.0

Con esto podras entrar de manera remota a la administracion de web2py sin necesidad de servidor web externo.

Bonus

Como regalo les dejo un script simple que les permite controlar el arranque de web2py. Deben copiarlo en /etc/init.d/


 #! /bin/sh
# Script de inicio y arranque de web2py

case "$1" in
  start)
    echo "Starting web2py"
    # run application you want to start
    python /web2py/web2py.py -c server.crt -k server.key --ip=0.0.0.0 -a password &
    ;;
  stop)
    echo "Stopping web2py"
    # kill application you want to stop
    pkill -9 -f web2py
    ;;
  *)
    echo "Usage: /etc/init.d/web2py {start|stop}"
    exit 1
    ;;
esac

exit 0

Definir seleccion por defecto en Grub2

Hace poco estábamos en la instalación un FreeSWITCH y una tarjeta E1 Sangoma, nos sucedió el problema de que los dirver Sangoma no eran compatible con el kernel 3.8 de Ubuntu Server 12.04. Después de varias pruebas estos drivers si funcionaron con el kernel 3.5 pero teniamos la problemtica que el servidor arrancaba por defecto con el kernel 3.8, asi que dimos con esta solucion.  


Definir Kernel en Grub2 


El primer paso es ver el menu con el siguiente comando

fgrep menuentry /boot/grub/grub.cfg 

nos mostrara todas las entradas en el menu de grub como la siguiente imagen

Seleccionamos y copiamos una entrada con la que muestra el ejemplo: 'Ubuntu, with Linux 3.2.0-31-generic'

Despues necesitamos editar el siguiente archivo:  

nano /etc/default/grub 

Y editamos las siguiente linea

GRUB_DEFAULT=0

y la dejamos asi

GRUB_DEFAULT='2>Ubuntu, with Linux 3.2.0-31-generic'

Nota: la opcion 2> le dice a grub que utilice el submenu entras anteriores de linux


Realizado esto necesitamos actualizar el kernel y esto lo realizamos con  el comando

update-grub

Y ya podemos probar lo realizado reiniciando la maquina.

Alta disponibilidad y sincronizacion de configuraciones

Objetivos

En este documento se mostrara la forma de implementar un cluster Activo/Pasivo con replicacion de configuración, todo esto de manera simple, sin necesidad de particiones o características especiales del núcleo de Linux.

Escenario

El escenario se muestra en la figura siguiente:








Es necesario mantener una IP virtual activa, la 192.168.100.20, por la cual se prestaran los servicios, ademas es necesario mantener sincronizado ciertos archivos de configuración, esto se realizara usando ssh y unison.


IP Virtual

Para la creación y mantencion de la IP virtual, es necesario tener instalado el paquete ucarp:

sudo apt-get install ucarp

ucarp es una aplicación de espacio de usuario que controla una Ip virtual entre distintos nodos, es una variante de vrrp pero totalmente libre de patentes.

Configurar ucarp en el Servidor Primario

El primer paso es crear los scripts de inicio y parada de ucarp, o sea cuando un nodo ucarp pasa a estado máster se ejecuta el script de inicio y cuando el nodo pasa a estado backup se ejecuta el script de parada. Desde el script de inicio es necesario activar la IP virtual y ademas se pueden activar servicios necesarios para servir desde la IP virtual. Desde el script de parada es necesario desactivar la IP virtual y desactivar los servicios dados por la IP virtual.
El segundo paso es activar el ucarp desde la consola, esto también se puede hacer desde el inicio de Linux.

Paso 1

En el Servidor Primario y Secundario
sudo nano /etc/vip-up.sh
#!/bin/bash
/sbin/ifconfig eth0:1 192.168.100.20/24 up
/etc/init.d/asterisk start

sudo nano /etc/vip-down.sh
#!/bin/bash
/sbin/ifconfig eth0:1 down
/etc/init.d/asterisk stop

Paso 2

En el Servidor Secundario

ucarp -i eth0 -s 192.168.100.4 -v 10 -p secret -a 192.168.100.20 --upscript=/etc/vip-up.sh –downscript=/etc/vip-down.sh
[INFO] Local advertised ethernet address is [54:52:00:14:a6:80]
[WARNING] Switching to state: BACKUP
SIOCSIFFLAGS: Cannot assign requested address
[WARNING] Spawning [/etc/vip-down.sh eth0]

En el Servidor Primario

ucarp -i eth0 -s 192.168.100.3 -v 10 -p secret -a 192.168.100.20 --upscript=/etc/vip-up.sh --downscript=/etc/vip-down.sh -P
[INFO] Local advertised ethernet address is [54:52:00:14:a6:80]
[WARNING] Switching to state: MASTER
[WARNING] Spawning [/etc/vip-up.sh eth0]


Con esto el servidor Primario quedara con la IP Virtual activa y el Secundario queda como Backup.

Paso 3

Para que ucarp arranque al inicio del sistema operativo es necesario agregar el comando de ucarp al arranque:

sudo nano /etc/rc.local
ucarp -i eth0 -s 192.168.100.3 -v 10 -p secret -a 192.168.100.20 --upscript=/etc/vip-up.sh --downscript=/etc/vip-down.sh -P