El año pasado me tocó dar un par de asignaturas optativas de informática en cursos de 3º y 4º de ESO y, entre otras cosas, tuve que prepararme una serie de prácticas sencillitas pero didácticas y lo más atractivas posibles sobre tratamiento de audio, vídeo y fotografía. Para esto último escogí, lógicamente a GIMP y de entre las actividades que realicé con mis alumnos el otro día me tropecé con está que, creo, puede resultarle práctica a mucha gente que quiera ahorrarse unas pelas. Sobre todo ahora que se abre la apertura de solicitud de plazas de colegios y os harán falta fotos de vuestros hijos. Suerte y ya sabéis: apostad por la escuela pública.

ntop es la herramienta más popular y completa para monitorizar el tráfico de una red cuando nos interesa, no sólo conocer la magnitud del mismo sino su procedencia y características. Colocado en un punto estratégico de nuestra red nos sirve para detectar cualquier tipo de anomalía en la misma. Si lo instalamos en un servidor nos sirve para auditar el tipo de tráfico que este emite y recibe de forma gráfica y muy didáctica.

Como ocurre en algunas ocasiones la versión en la paquetería de debian (4.0.33 en la estable y 4.99.3 en testing y unstable) va bastante por detrás de la del producto (5.0.1) así que si te apetece jugar con lo último lo mejor es bajarte los fuentes y compilarlos en tu máquina. Pero ya sabes que, en este caso, tendrás que preocuparte de posibles actualizaciones de forma manual. ntop, en particular, no parece tener ningún aviso automático de la aparición de nuevas versiones. Vamos a ello.

Antes que nada, instalamos los paquetes necesarios para realizar la instalación, las dependencias y alguna otra cosa necesaria:

1

apt-get install build-essential libtool automake autoconf libpcap-dev libgdbm-dev zlib1g-dev rrdtool librrd-dev libssl-dev python-dev libgeoip-dev graphviz libgraphviz-dev subversion python-pip

A continuación nos descargamos de aquí la última versión estable de ntop, la copiamos en, por ejemplo, el directorio /tmp de nuestra máquina y la descomprimimimos

1
2

wget -c http://sourceforge.net/projects/ntop/files/ntop/Stable/ntop-5.0.1.tar.gz/download
tar xvfz download

Ahora entramos al directorio donde se han descomprimido los fuentes (ntop-5.0.1 en este caso) y generamos los binarios.

1
2
3
4
5

cd ntop-5.0.1/
./autogen.sh
make
make install
ldconfig

Y listo. Sólo nos quedan unos cuantos retoques. Los datos que ntop capture una vez esté en funcionamiento se guardarán en /usr/local/var/ntop. El daemon de ntop se ejecuta con el usuario nobody, así que debemos de hacerlo propietario de dicho directorio para que pueda escribir libremente en él:

1

chown -R nobody /usr/local/var/ntop

El binario de ntop ya está listo para ejecutarse y se encuentra en el directorio /usr/local/bin. Si escribes ntop -help tendrás una detallada lista de posibles opciones. Las mías son estas:

1

/usr/local/bin/ntop -i eth0 -w 3001 -L -d

De esta forma ntop monitorizará todo el tráfico enviado y recibido por el interfaz de red eth0 de nuestra máquina, el interface web de ntop escuchará peticiones en el puerto 3001 (por defecto lo haría en el 3000), guardará los mensajes de log en el syslog de la máquina (/var/log/syslog) y se ejecutará como daemon o servicio en segundo plano.

En la primera ejecución nos pedirá que introduzcamos la contraseña para el usuario admin necesaria para entrar a ciertas páginas restringidas del programa. Muy pocas, la verdad, pero luego veremos como solucionar esto. Para acceder a ntop ya sólo tenemos que ir a nuestro navegador y escribir lo siguiente sustituyendo ip-de-la-maquina por la dirección o nombre correcto donde hemos hecho la instalación y cambiando el puerto por el adecuado si lo hemos modificado en la orden de inicio anterior:

1

http://ip-de-la-maquina:3001

Para proteger el acceso a cualquier página de ntop (imprescindible sobre todo si es visible desde Internet) debemos de entrar en el menú superior (Admin -> Configure -> Protect URLs) y añadir una regla con un asterisco ‘*’ al limitado grupo de usuarios que deseemos (o al usuario admin si es una instalación de uso particular).

Ahora ya sólo nos quedan unos pequeños ajustes para disponer de algunos gráficos y diagramas adicionales que, por defecto, no vienen configurados. El plugin Round-Robin Database debería de estar activado para disponer de los gráficos de Network Load generales o por protocolo.

Para ello, además de activar el plugin (Plugins -> Round-Robin Database -> Activate), deberíamos de comprobar que en la pantalla de Preferencias (Admin -> Configure -> Preferences) la cadena rrd.rrdPath apunta a un directorio donde el usuario nobody tenga permisos de escritura (típicamente /usr/local/var/ntop/rrd), que en la configuración del plugin (Plugins -> Round-Robin Database -> Configure) las dos cadenas del bloque RRD Files Path apuntan al mismo directorio y que en el bloque Data to Dump de esta misma pantalla tenemos seleccionada, al menos, la opción de Interfaces. Si seleccionamos todas las opciones tendremos muchos más datos de captura pero a costa de cargar más la ejecución y el espacio ocupado por las capturas. Mucho cuidado con el espacio en disco, que podemos necesitar fácilmente 2 Gigas por día en un servidor con un tráfico corrientito.

Para ver los mapas por regiones tenemos que instalar las plantillas Mako para python. Como al principio de todo hemos instalado el paquete python-pip nos basta con salir a línea de comandos y ejecutar lo siguiente:

1

pip install Mako

Por último, aunque hemos instalado graphviz y Dot es uno de sus elementos integrantes, nos hace falta añadir un path en las Preferencias (Admin -> Configure -> Preferences) para disponer de los Mapas de Tráfico de Red Locales. Entramos en ellas y, al final de la tabla, añadimos la cadena dot.path con el valor /usr/bin/dot. Pulsamos Add, confirmamos y listo.

ntop tiene muchas otras gráficas y páginas de información útil e interesante además de estas que he mostrado y cuyo único motivo para aparecer aquí es que necesitan de algún retoque extra en la configuración para poder usarlas, así que lo mejor es que las explores una a una. La documentación para interpretarlas es escasa, todo hay que decirlo, pero últimamente se están poniendo las pilas en este sentido y han prometido, por fin, un manual de usuario en breve.

Y ya sólo nos queda un pequeño detalle para concluir. Si quieres que ntop se ejecute de forma automática como servicio cada vez que hagas un reinicio de la máquina donde la tienes instalada sólo tienes que crear un fichero .sh (por ejemplo ntop.sh) con la línea de ejecución que has usado antes para ponerlo en marcha, crear un enlace al mismo en el directorio init.d y ejecutar lo siguiente:

1
2

ln -s /opt/Scripts/ntop.sh /etc/init.d/ntop
update-rc.d ntop defaults 99

A la hora de plantearnos la instalación de una centralita VoIP con Asterisk y FreePBX, una de las primeras cosas que tenemos que decidir es, como en muchos otros casos, el hardware que vamos a necesitar. La respuesta no es única, sino bastante dependiente de nuestras necesidades, así que vamos a tratar de ver y analizar los distintos elementos que pueden hacernos falta y a dar unas breves notas para hacer la elección correcta.

UNA MÁQUINA PARA HACER LA INSTALACIÓN
El primer y único elemento indispensable es una máquina en la que instalar la centralita. Aunque tampoco tiene que ser muy grande o, siquiera, “real”. Asterisk es tan poco exigente que, incluso, existe una implementación denominada micro Elastix para la Raspberry Pi. Si no vamos a usar líneas telefónicas “convencionales” y sólo queremos utilizar proveedores de telefonía VoIP (aquí tienes una lista de las que operan en España) podemos recurrir a una máquina virtual o a un servidor VPS en un Hosting de nuestra elección. En la mayoría de las ocasiones, no obstante, no recurriremos a soluciones tan económicas. Por un lado, las comunicaciones telefónicas suelen ser un punto crítico en la mayoría de las instalaciones que querremos hacer, así que necesitaremos un hardware robusto y con redundancia en los puntos de fallo más críticos (discos en RAID por hardware, fuentes de alimentación redundantes, etc.). Por otro lado, si vamos a usar líneas de telefonía convencionales, una de las opciones más habituales es conectarlas a nuestra centralita mediante tarjetas especiales y estas suelen ser PCI o PCIe (aunque veremos que existen otras alternativas). No olvides, además, que necesitas que el hardware que elijas debe de funcionar correctamente con Linux. Todas las distribuciones que conozco que traen Asterisk preinstalado y listo para usar van sobre CentOS, así que si vas a coger una de estas opciones y aún tienes que comprar la máquina lo mejor es que te certifiquen que irá bien con CentOS o RedHat que, para el caso, son lo mismo. Y no, no se trata de una cuestión trivial. En un servidor con componentes muy específicos (como una tarjeta de RAID), por desgracia aún podemos tener sorpresas muy desagradables en este aspecto.

TARJETAS Y GATEWAYS
Si vamos a usar líneas de teléfono convencionales (analógicas o digitales) o queremos usar teléfonos analógicos con nuestra centralita, vamos a necesitar tarjetas especiales o gateways. Veamos ambas opciones.

Las tarjetas suelen ser, o bien PCI, o PCI express, así que si vamos a usarlas tenemos que tenerlo en cuenta cuando compremos el equipo. PCI, además, sólo admite dos tarjetas diferentes en el mismo equipo, así que si esta es nuestra elección mucho cuidado con las ampliaciones futuras. Además, si finalmente vamos a usar RAID por hardware posiblemente ya tendremos ocupada una de ellas.

Pero, empecemos por el principio ¿Que diferencia hay entre usar tarjetas o gateways? Desde el punto de vista operativo ninguna. Cualquiera de ambas opciones nos ofrecerá los mismos resultados. Las tarjetas se conectan a los buses internos del equipo y les conectamos directamente las líneas y/o teléfonos. Los gateways son dispositivos externos a los que conectamos las líneas y teléfonos y que, además, tienen una interfaz ethernet que irá conectada a nuestra red y que le permitirá comunicarse con la centralita a través del protocolo SIP. Las tarjetas no ocupan espacio, ni enchufes adicionales y sobrecargan menos la red de tráfico IP pero están más limitadas en cuanto al número y la variedad que podemos conectar a nuestra centralita. Además, no son un alternativa cuando vamos a hacer la instalación sobre una máquina virtual, una raspberry o algún otro equipo de bajo presupuesto.

En cualquiera de ambos casos, si vamos a conectar líneas digitales RDSI necesitaremos una tarjeta o gateway con conexión BRI/RDSI y si vamos a conectarle líneas analógicas convencionales necesitaremos que tenga puertos FXO. Si lo que queremos es conectarle teléfonos analógicos, deberá de contar con puertos FXS. Por cierto, ¿te lías con la diferencia entre FXO y FXS? Normal. Le pasa hasta a algún que otro teleco FXS es, hablando coloquialmente, el enchufe por donde viene nuestra línea de teléfono mientras que FXO sería el conector del aparato telefónico en si. Un FXS siempre va conectado a un FXO y viceversa. Si queremos conectar líneas analógicas a nuestra centralita necesitamos que esta cuente con puertos FXO (ya que las líneas son FXS). Si lo que queremos es pincharle teléfonos (FXO) necesitamos que cuente con puertos FXS.

Dentro de la amplia gama de tarjetas y gateways existentes hay una gran variedad de modelos que, incluso, admiten conexiones híbridas: líneas analógicas y digitales, puertos FXS y FXO combinados, etc. Para elegir, puedes echarle un vistazo, por ejemplo, al catálogo de Avanzada7, una de las mejores empresas que se dedican a estos menesteres en nuestro país.

Sólo un par de puntos adicionales: si finalmente vas a comprar tarjetas échale un vistazo a las de Digium antes que a ninguna. Tienen una buena relación calidad precio, todas las distribuciones de Asterisk vienen ya con los drivers necesarios (lo cual te ahorrará muchos problemas) y ayudarás a sostener el modelo de negocio de la empresa que, amablemente, nos regala un software tan fantástico (Digium es la empresa que desarrolla Asterisk). Y dos: las líneas digitales siempre dan más problemas que las analógicas. Más si te empeñas en usar “sucedaneos” como los que comercializa Jazztel. Pero esto es una historia que merece ser contada en otra ocasión…

LÍNEAS GSM
Si queremos usar líneas móviles tenemos dos alternativas: usar un gateway analógico con salida FXS (como el EasyGate 2N del que ya hemos hablado aquí en alguna ocasión) y conectarlo a nuestra centralita como si se tratase de una línea telefónica analógica convencional, o usar un gateway como el Mobilink Topex SIP que nos permite conectarlo directamente a nuestra red local y comunicar mediante SIP con nuestra centralita. Cualquiera de ambos se vende en dos configuraciones diferentes con espacio para una o dos tarjetas SIM.

TELÉFONOS DIGITALES Y VIDEOTELÉFONOS
No hacen falta teléfonos para usar una centralita Asterisk. Existen una gran variedad de softphones (muchos de ellos libres y gratuitos) que puedes utilizar desde tu PC con cualquier sistema operativo y sin mas requisitos que disponer de altavoces y micrófono. No obstante, si por comodidad o necesidad necesitas un teléfono mas convencional, dispones de una gran cantidad de modelos que se pueden conectar directamente a tu red local y que usan SIP para conectar con Asterisk (alguno por poco más de 30 euros), videoteléfonos, y puedes conectar cualquier teléfono analógico a través de un gateway o tarjeta que disponga de puertos FXS.

Como ya habíamos hablado por aquí, uno de los parámetros críticos en un servidor Apache es MaxClients, el número máximo de conexiones que es capaz de manejar simultaneamente. Es crítico porque cada tarea de Apache consume una determinada cantidad de memoria y si la suma de la memoria que consumen todos de forma simultanea es mayor que la memoria RAM que la máquina tiene libre comenzará a hacer swapping a disco y, si esta situación se mantiene, corremos un riesgo importante de que se nos quede virtualmente congelada. Una instalación de Apache por defecto toma un valor de 150 para este parámetro y esto es una verdadera burrada para casi cualquier servidor web con menos de 1 Gbytes (o incluso con bastante mas) que use contenidos dinámicos medianamente pesados.

Hace bien poco, buscando por ahí algún enlace para profundizar un poco más en estos temas, me encontré con este artículo de una empresa de hosting donde te proponen un script para ajustar el valor más adecuado a tus necesidades. Había dos cosas que no me gustaban en él script propuesto. Por un lado, tomaban el valor más conservador, es decir, el resultante de dividir la memoria libre entre lo que ocupa el proceso de Apache mayor. En segundo lugar, hacen el cálculo de la memoria libre sin tener en cuenta la que está ocupada por cache o buffers y que podría liberarse en caso de necesidad. Yo le he hecho algunos cambios para salvar ambos puntos y dejarlo un poco más bonito e informativo y me ha salido esto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

#!/bin/bash
clear
 
# Primero analizamos los procesos de apache funcionando actualmente
LISTA=`ps -aylC apache2 |grep apache2 |awk '{print $8'} |sort -n`
 
echo "Lista ordenada de la memoria, en bytes, ocupada por los procesos de Apache corriendo en este momento:"
COUNT=0
SUMA=0
for ITEM in $LISTA
do
        COUNT=`expr $COUNT + 1`
        SUMA=`expr $SUMA + $ITEM`
        echo "$COUNT -> $ITEM"
        if [ $COUNT -eq 1 ]
        then
                MENOR=$ITEM
        fi
done
 
MAYOR=$ITEM
MEDIA=`expr $SUMA / $COUNT`
 
# Pasamos las cantidades a Kbytes
MENOR=`expr $MENOR / 1024`
MAYOR=`expr $MAYOR / 1024`
MEDIA=`expr $MEDIA / 1024`
 
echo "El proceso de Apache más grande ocupa" $MAYOR "Kbytes y el menor" $MENOR "Kbytes"
echo "La media de la memoria ocupada por un proceso es de $MEDIA Kbytes"
 
echo "Detenemos Apache..."
apache2ctl graceful-stop > /dev/null
 
# Limpiamos los caches y buffers del servidor
sync
echo 3 > /proc/sys/vm/drop_caches
 
# Calculamos la memoria libre del sistema
FREEMEM=`free -m |head -n 2 |tail -n 1 |awk '{free=($4); print free}'`
echo "La memoria libre del servidor, después de liberar cache y buffers, es de $FREEMEM Kbytes"
 
echo "Arrancamos Apache de nuevo..."
apache2ctl start > /dev/null
 
echo "MaxClients debería de estar entre" `expr $FREEMEM / $MAYOR` "y" `expr $FREEMEM / $MENOR`
echo "Usando el valor medio de la memoria ocupada, un valor recomendable de MaxClients sería de" `expr $FREEMEM / $MEDIA`

El script de aquí arriba imprime una lista de la memoria ocupada por todos procesos de Apache activos en el momento de ejecutarlo. Luego toma el mayor, el menor y la media de todos ellos y calcula la memoria libre del sistema. Para ello, antes detiene Apache (con un graceful-stop para no fastidiar a nadie que esté viendo nuestra web en ese momento) y libera los buffers y caches de memoria. Por último, arranca de nuevo Apache y nos da como salida dos valores: una horquilla entre el valor que debería de tomar MaxClient usando el menor y el mayor valor de los procesos tomados en la instantánea anterior y un valor recomendado que sale de usar el valor medio de todos ellos.

Evidentemente no se trata de algo matemático. Como es lógico, ejecutado en diferentes momentos obtendremos valores distintos ya que ni la RAM que usa nuestro servidor es inmutable ni el tamaño de los procesos de Apache es siempre el mismo ni siguen la misma distribución. Pero para darnos una primera idea del valor con el que tenemos que empezar a jugar creo que es bastante válido. Ya me contáis.

NOTA: En algunas instantáneas el valor de memoria ocupado por el proceso más pequeño de Apache puede ser cero, seguramente porque o está creándose o está destruyéndose en ese momento. En ese caso el valor de la horquilla pierde uno de sus extremos. Sería muy fácil modificar el script para que en ese caso tome el segundo valor y divida por un elemento menos, pero ocurre en tan pocas ocasiones que no creo que merezca la pena hacerlo. Al menos no hoy

La instalación más sencilla (y, me atrevería a decir, más frecuente que he tenido que realizar) que suele hacerse con Cacti es aquella que se se usa para monitorizar los recursos de un único host (típicamente un servidor dedicado o VPS en una empresa de hosting) en el que el propio Cacti se encuentra instalado de forma local.

Cacti necesita para funcionar un servidor web (apache2, por ejemplo) con php, una base de datos de mysql-server, las rrdtools y snmp (cliente y agente). Seguramente tendremos ya instalados apache2 y mysql-server y, si no, añade los paquetes apache2, php5 y mysql-server al comando siguiente:

1

sudo apt-get install cacti snmp snmpd rrdtool

Durante la instalación se nos pedirá si queremos configurar de forma automática la base de datos que necesita cacti (en caso afirmativo, se nos pedirá la contraseña de root de mysql-server para crear dicha base de datos y un usuario de acceso a la misma) y el servidor web que usaremos (apache2 en nuestro caso).

Una vez concluida la instalación podremos acceder a Cacti con la URL http://ip_o_nombre_del_servidor/cacti. En el primer acceso se ejecutará un asistente en el que se nos pedirá aceptar la licencia de uso, decidiremos el tipo de instalación (nueva o actualización de una versión anterior) y se realizará un chequeo de dependencias:

Una vez cumplimentado esto se nos redirecciona a la ventana de login. El usuario inicial es admin y su password la misma. Inmediatamente después de realizar el primer login se nos forzará a cambiar esta password, así que tenla pensada de antemano

Cacti está ya funcionando y recogiendo datos de forma automática del servidor en el que se encuentra instalado. Si lo dejamos unos minutos para que le de tiempo a recoger algunos y pulsamos sobre la solapa de gráficos (arriba a la izquierda) veremos que ya tenemos gráficas (no tan completas como estas que llevan ya más de 24 horas, claro) de carga de la CPU, ocupación de memoria, número de procesos y número de usuarios conectados.

Para monitorizar el tráfico de red es preciso “tirar” de snmp. Lo primero que tenemos que hacer es configurar el daemon de snmp para que Cacti pueda leer de él. Para ello editamos el fichero /etc/snmp/snmpd.conf y quitamos el comentario que deshabilita la siguiente línea:

1

rocommunity public localhost

Reiniciamos el servicio (sudo service snmpd restart) y volvemos a Cacti para configurar la nueva gráfica. Para ello entramos en la opción Devices del menú de la izquierda, pulsamos sobre la entrada de localhost (la única que tendremos) y, en la ficha resultante, editamos el campo destacado en la imagen de aquí abajo (el correspondiente a la versión de SNMP que aparecerá como Not in Use) y luego pulsamos el botón de Save. Si todo ha salido bien y Cacti es capaz de contactar con el demonio SNMP de nuestro equipo, arriba a la izquierda aparecerán las líneas de información que también puedes ver resaltadas en este gráfico:

En la parte inferior de esta misma ficha de datos, en el bloque de “Associated Data Queries” debería de aparecer ahora una línea etiquetada como “SNMP – Interface Statistics” (a la derecha de “Add Data Query”). La seleccionamos, pulsamos el botón de Add y, a continuación, el de Save.

Bien, ahora volvemos a la parte superior de la página y pulsamos en el enlace de “Create Graphs for this Host”. En la página que nos aparece marcamos los interfaces de red cuyo tráfico queremos monitorizar y, ya que estamos, las unidades de disco cuya ocupación queremos controlar (eth0 y sda1, respectivamente, en el ejemplo aquí abajo). Bajo las líneas correspondientes a los interfaces de red tenemos, como puedes ver, un selector que nos permite elegir entre diferentes tipos de gráficos. A mi particularmente la que aparece por defecto (In/Out bits) es la que me parece más cómoda pero, ya sabéis, para gustos…

Pulsamos Create y listo. Los datos se empezarán a tomar inmediatamente y, a los pocos minutos, si volvemos a entrar en la solapa de Gráficos tendremos ya las primeras muestras disponibles. Después de 24 horas tus nuevas gráficas de tráfico de red y de ocupación de disco lucirán como estas:

El siguiente gráfico que añadiremos será el de activida de lectura y escritura en discos, muy interesante sobre todo para monitorizar la actividad de nuestro disco de swap y detectar si la máquina está corta de memoria. También es el que más “trabajo” nos va a dar para ponerlo en marcha, así que atención.

Lo primero que necesitas es descargarte y descomprimir este fichero (extraído de este hilo del foro de Cacti que es de donde he sacado las instrucciones que te voy a contar) donde encontraras dos archivos con extensión XML. El que se llama net-snmp_devio.xml tienes que copiarlo al directorio /usr/share/cacti/site/resource/snmp_queries/ de la máquina. El otro, llamado cacti_data_query_ucdnet_device_io.xml, tienes que importarlo desde la opción “Import Template” que aparece en el menú de la izquierda.

Si el resultado es correcto veremos algo como esto:

Ahora volvemos a la opción de Devices, volvemos a seleccionar localhost y en la parte inferior, en el mismo bloque de “Associated Data Queries”. ahora nos aparecerá una nueva línea etiquetada como “ucd/net – Device I/O” que debemos de seleccionar y, luego, pulsar el botón de Add y salvar los cambios.

Volvemos a pulsar ahora en el enlace de “Create Graphs for this Host” y en el nuevo bloque que nos aparece seleccionamos las líneas correspondientes a los discos cuya actividad queremos seguir. En el ejemplo de aquí abajo se han seleccionado sda1 (la partición donde reside el sistema) y sdb (el disco de swap).

Cambiamos al pie del bloque el tipo de gráfico si así lo deseamos y pulsamos el botón de Create. Listo:

Y para terminar, un pantallazo con todos los gráficos de monitorización que tenemos ahora en nuestro servidor tras configurar sus dimensiones para que puedan verse cómodamente con un sólo vistazo (pulsa sobre él para verlo ampliado):

Si queremos instalar xampp en Chakra Linux nos encontramos con que esta distribución sólo está disponible ya para 64 bits mientras que xampp se distribuye en forma de script sólo para sistemas de 32 bits. La solución pasa, sencillamente, por instalar unas librerías de compatibilidad y listo. Manos a la obra, pues. En un primer paso sustituimos las gcc-libs por las gcc-libs-multilib:

1

sudo pacman -S gcc-libs-multilib

Luego, tenemos dos opciones, descargar e instalar xampp siguiendo sus instrucciones como haríamos normalmente o usar el paquete ccr disponible (aunque ligeramente desactualizado):

1

ccr -S xampp

En cualquiera de ambos casos, xampp se instalará en el directorio acostumbrado (/opt/lampp) y responderá a los comandos y opciones habituales.

NOTA: Siempre que he realizado operaciones de este tipo y he instalado versiones de librerías de 32 bits en distribuciones de 64 (concretamente en Ubuntu y Fedora) luego, en algún momento, he tenido problemas de dependencias no resueltas a la hora de realizar alguna instalación y/o actualización. Aunque de momento no he tenido ningún problema similar con Chakra no llevo suficiente tiempo con esta distribucion como para asegurar que esto esté mejor resuelto.

memcached es uno de los sistemas de caché para servidores web más usado. Usa una zona de la memoria RAM del servidor web de tamaño configurable como caché y funciona bien tanto en sitios pequeños y discretos como en grandes sistemas con múltiples servidores. Facebook, Twitter o Youtube, por ejemplo, usan este sistema de cacheado. El 85% de los 20 sitios con más tráfico de Internet lo usan, en realidad. Nada mejor, pues, para estrenar una pequeña sección acerca de sistemas y extensiones de cacheado para apache ¿no?

Partimos para la instalación de una Debian en la que ya tenemos un servidor web apache y la versión 5 de php (paquetes apache2 y php5). Para instalar memcached en una Debian he tenido que recurrir a usar “paquetería” de wheezy (testing) porque parece que hay algún problema de dependencias en la versión estable (squeeze) y la librería de extensión para trabajar con PHP no compilaba correctamente. Así que manos a la obra. El primer paso es instalar el servidor de memcached:

1

apt-get install memcached

El servicio se instala, como es habitual, en el directorio /etc/init.d y responde a los argumentos start, stop, restart, force-reload y status. En el directorio /usr/share/memcached/scripts existe un script llamado start-memcached que es el encargado de realizar el inicio automático y que toma la configuración del archivo memcached.conf en el directorio /etc. Dentro de este fichero de configuración una de las opciones más interesantes es la que dice a memcached cuanta RAM va a usar como caché. Por defecto son 64M, pero en sistemas con muy poca RAM tal vez nos convenga bajarlo. Mi VPS tiene sólo 512M de RAM y yo he bajado esos 64M a la mitad. Para ello basta con cambiar la línea -m 64 por -m 32 y reiniciar el servicio.

Otra de las opciones interesantes en ese archivo de configuración es la posibilidad de habilitar un archivo de logs que, por defecto, viene deshabilitado. Para ello basta con quitar el comentario a una de las dos opciones que aparecen el el fichero según el nivel de detalle que queramos: -v o -vv. El log se grabará en el fichero /var/log/memcached.log. Esto también es configurable modificando la línea que aparece en el mismo fichero. Y no olvides que para que la opción tome efecto haz de reiniciar de nuevo el servicio de memcached.

El segundo paso sería instalar la extensión de memcached para PHP. Para ello tenemos que instalar los siguientes paquetes:

1

apt-get install php-pear php5-dev php5-memcached libmemcached10 libmemcached-dev libmemcachedutil2 libhashkit2 libhashkit-dev

Y, a continuación, ejecutar lo siguiente:

1

pecl install memcached

Si todo sale bien, al final del proceso se nos mostrará un mensaje similar a este:

La librería debería de haberse creado en el directorio de extensiones de php que se indica al final del proceso y que puedes ver en la imagen anterior (/usr/lib/php5/20100525+lfs) y ya sólo nos resta hacerle caso al mensaje final y añadir la línea extension=memcached.so al final de nuestro fichero php.ini que debería de estar en el directorio /etc/php5/apache2. Reiniciamos apache y, si ejecutamos la función phpinfo veremos una nueva sección:

Para ver información acerca de como está funcionando nuestra cache tenemos un par de opciones más atractivas que inspeccionar el fichero de log que hemos mencionado antes. Una de ellas es usar el script memcached-tools que encontraremos en el directorio /usr/share/memcached/scripts/.

1

/usr/share/memcached/scripts/memcached-tool 127.0.0.1:11211

El comando anterior muestra información sobre el estado del servicio memcached que hemos instalado en nuestra máquina. Añadiendo al final el argumento stats nos mostrará estadísticas de uso y con el argumento dump realizará un volcado del contenido de la caché por pantalla.

La segunda opción que tenemos es bajarnos de aquí un script hecho en perl y llamado memcache-top. Tienes distintos argumentos para modificar la salida que puedes consultar en la web desde la que te has bajado el script. En la imagen siguiente se muestra con las opciones --cumulative y --commands

Y ya sólo nos queda habilitar el uso de memcached desde wordpress. Para ello usaremos Memcached Object Cache que, aunque aparece como cualquier otro en el repositorio de plugins de wordpress, en realidad precisa de una sencilla instalación manual para que funcione. Bajamos el archivo, lo descomprimimos y copiamos el archivo object-cache.php en el directorio wp-content de nuestra instancia de wordpress.

Hace algo más de dos años que la gente de KDE anunció un proyecto llamado ownCloud, un sistema de copia y sincronización de archivos “en la nube” basado en un servicio LAMP en la parte del servidor y el uso de csync en la parte del cliente. El resultado es que cualquiera pueda montarse su propio servicio de sincronización de ficheros similar a Dropbox o SugarSync, pero sin restricciones de espacio y/o tráfico (más allá de lo que le permita su propio servidor o su servicio de hosting) y sin plantearse dilemas de privacidad. El desarrollo ha sido muy rápido (hace dos meses que vió la luz la versión 3 del servidor y la 1 del principal cliente) y realmente, merece la pena probarlo y echarle un vistazo.

El aspecto realmente “potente” de ownCloud es montar tu propio servicio, pero si no tienes medios o prefieres empezar por evaluar si te gusta de forma sencilla, puedes hacerlo a través de algún proveedor externo, que ya los hay. Existen servicios de pago y otros que, al igual que Dropbox y similares, ofrecen una modalidad de entrada gratuita y opciones adicionales por las que hay que pagar (freemiun que lo llaman por ahí). Owncube ofrece cinco Gbytes de espacio gratuito y GetFreeCloud, ofrece seis. Yo te aconsejo que empieces por Owncube puesto que ha actualizado ya su versión a la 3.0.2 y hasta la anterior, la 3.0.1 que es la usada en GetFreeCloud, existen un par de vulnerabilidades que pueden aprovecharse fácilmente a través de Metasploit. (Ver ACTUALIZACIÓN (y II))

Crear una cuenta en cualquiera de ambos servicios es fácil: nombre, contraseña, correo electrónico y listo. Sólo con eso ya tienes un servicio de almacenamiento con un cómodo interfaz web.

Pero si realmente le quieres sacar partido a la sincronización automática de archivos entre tu equipo y el servidor y/o entre distintos equipos, necesitas instalarte un software cliente. En el anterior enlace tienes los binarios disponibles para Windows y las principales distribuciones de Linux. Los de Mac y Android (Ver ACTUALIZACIÓN) aún están en fase de desarrollo y no están disponibles. Para distribuciones “marginales” de Linux tienes los fuentes y detalladas instrucciones de compilación, aunque imagino que la mayoría de ellas tendrán ya listos paquetes más o menos oficiales. Yo estoy usando Chakra en estos momentos (y muy contento, ya os hablaré de ello en otra ocasión) y el pkgbuild correspondiente está disponible aquí.

Una vez instalado tenemos un icono disponible en la bandeja del sistema con un menú contextual bien sencillo: La opción de Configurar nos permite cambiar los datos de conexión con el servidor de sincronización y la opción de Add Folder nos permite añadir un nuevo directorio al servicio. Luego tenemos una entrada por cada directorio que se está sincronizando que nos abre directamente el administrador de archivos por defecto en dicho directorio local y la opción de cerrar el servicio (Quit). Si pulsamos con el botón izquierdo sobre el icono, en lugar de este menú se nos abrirá una ventana con información sobre el estado de sincronización de los directorios y la posibilidad de elmininarlos (del servicio, no de borrarlos), añadir nuevos, parar temporalmente el servicio en uno de ellos o volver a reanudarlo, etc.

En la funcionalidad de “añadir directorios” es donde, quizás, se aprecia mejor la diferencia en la filosofía de uso frente a Dropbox que, tal vez, es su competidor más popular. Aquí no existe un único directorio de sincronización sino que los añadimos de forma individual aunque estos se encuentre en diferentes sitios de nuestro sistema de archivos. En Dropbox solemos resolver este asunto (al menos desde Linux) mediante enlaces simbólicos pero este método es bastante más flexible y cómodo. Además, podemos realizar la sincronización de un directorio en particular no sólo contra el servidor que hemos configurado “en la nube” sino contra otro directorio local o contra cualquier otra URL donde, lógicamente, debemos de tener acceso de escritura. Esto nos abre 1001 posibilidades de salvaguarda de nuestros datos.

Volviendo al interfaz web, este tiene algunos “complementos” bastante útiles que podemos apreciar en el menú de enlaces a la izquierda: bookmarks, calendarios, contactos y dos entradas llamadas Música y Galería donde, automáticamente y de forma similar a como hace Android, se recopilan entradas a este tipo de archivos independientemente del directorio donde se encuentren. Ah, y en la opción de música tenemos un reproductor y todo

No he encontrado forma de sincronizar el calendario o los bookmarks con otros servicios externos y los contactos deberían de poder sincronizarse con los de GMail a través de una opción existente en el menú de Ajustes (la rueda dentada que aparece en la parte inferior izquierda) pero no he logrado hacer que funcione.

Para los amigos de la línea de comando, existe un cliente de administración opcional para la consola llamado owncloud-admin. Los ficheros de configuración, al menos en mi distribución, se guardan en el directorio $HOME/.local/share/data/ownCloud/ Allí nos llevaremos la desagradable sorpresa de que el usuario y la contraseña de nuestro servidor de sincronización se guardan en claro dentro del fichero owncloud.cfg. En la instalación del cliente se nos pregunta si queremos que esta no se guarde y se nos pregunte en cada arranque pero, vaya, sería deseable una mayor integración con kwallet, el servicio de gestión de contraseñas propio de KDE.

Está claro que el desarrollo tiene aún muchos detalles por pulir y mejorar. He tenido problemas durante las pruebas con supuestos desajustes horarios entre cliente y servidor (que se han solucionado eliminando el servicio de sincronización y volviéndolo a crear, luego se trata de otra cosa…) y echo de menos que sincronice el contenido de enlaces simbólicos en el equipo local (cosa que no hace). Se echan de menos, además, opciones disponibles en Dropbox desde hace tiempo (como, por ejemplo, la recuperación de versiones anteriores de un archivo). También sería deseable que, ya puestos, pudiéramos sincronizar distintas carpetas contra diferentes servidores de owncloud. Y, desde luego, los clientes móviles deberían de estar disponibles pronto si quieren que el servicio entre a competir con los grandes. Pero de entrada, y a mi juicio, tiene muchas posibilidades y se trata del primer servicio de este tipo verdaderamente libre (y no como Ubuntu One). OpenSuse está particularmente involucrado en sacarlo adelante, asi que esperemos que seguirá evolucionando de forma rápida.

Pronto y en otra entrada, contaremos como puedes montarte tu propio servicio servidor de owncloud.

Instalar un servidor Apache en un entorno Linux debe de ser lo más fácil del mundo. Configurarlo para que funcione de forma aceptable sirviendo una o dos instancias web también es sencillo. Ajustarlo para que funcione de forma eficiente en entornos escasos de recursos o para que escale bien ante grandes cargas ya es algo en lo que muy pocos se meten. Si siempre has trabajado con servidores compartidos no te habrás dado cuenta de esto último porque alguien te lo ha dado ya hecho. Pero tanto si has tenido que gestionar servidores propios y/o dedicados o pequeños VPS posiblemente hayas tenido algún problema en este sentido. Y si no, creeme: los vas a tener…

La forma en que Apache gestiona la multitarea a la hora de atender a los clientes del servidor web se configura mediante los módulos MPM. Los dos más comúnmente usados son Prefork y Worker pero existe por ahí alguno más. Al instalar apache2 en Debian (y en todas las distribuciones, me atrevería a decir) se instala por defecto el paquete apache2-mpm-prefork y este es el módulo MPM que funcionará por defecto. Para probar con worker basta con instalarlo (apt-get install apache2-mpm-worker en una Debian) y automáticamente desinstalará el otro mpm (sólo puede haber uno en cada momento) y reiniciará el servicio de apache para que los cambios tomen efecto.

La primera pregunta que se nos plantea es, lógicamente, cual elegir. A grandes rasgos la principal diferencia entre ambos es que Prefork crea siempre nuevos procesos para gestionar las conexiones entrantes mientras que con Worker los procesos hijos, a su vez, crean múltiples hebras cada uno de ellos para esta tarea. Tienes información más precisa de como funcionan en los enlaces de hace unas líneas. Prefork tiene a gala ser más estable y funcionar mejor en máquinas escasas de recursos, mientras que Worker presume de ser más escalable y eficiente para servidores más ambiciosos. Para novatos o instalaciones sin necesidades especiales es mejor quedarse con la opción por defecto (Prefork) puesto que, además, incluso algo tan simple como instalar PHP es trivial y habitual con este módulo mientras que hay que “enredar” bastante más para hacerlo funcionar con Worker.

Si el servidor no lo hemos instalado nosotros y queremos saber que MPM está activo basta con recordar que sólo puede haber uno, así que podemos mirar que paquete está instalado (aptitude search apache2-mpm-* en Debian, de nuevo) o interrogar directamente a apache con la opción -l:

1
2
3
4
5
6
7
8

root@invernalia:/etc/apache2# apache2 -l
Compiled in modules:
  core.c
  mod_log_config.c
  mod_logio.c
  prefork.c
  http_core.c
  mod_so.c

Pero independientemente del módulo que escojamos, el comportamiento final del servidor web será muy parecido. Pensemos que se trata de un servicio diseñado para atender múltiples peticiones simultaneas de decenas (o centenares, si tenemos una web con éxito) de clientes y hacerlo de forma eficiente y en el menor tiempo posible. Nuestro servidor permanecerá a la espera de estas peticiones y, cuando vayan llegando, destinará a un proceso (o a una hebra de un proceso) a atenderlas. Cuantos más peticiones se cursen de forma simultanea, más procesos/hebras necesitaremos y consumiremos más recursos de la máquina. Sobre todo memoria. Un servidor web se comporta como un insaciable devorador de RAM. Este va a ser el recurso que debemos de aprender a gestionar: la RAM que no se usa cuando se necesita se desperdicia y nos hace perder visitantes o que estos sean atendidos más lentamente. Pero si no controlamos el consumo y el servidor la agota comenzará a hacer swapping a disco y evitar esto es la regla de oro: Si llegamos a este punto lo habremos perdido y, posiblemente, tendrás que reiniciar el servicio (o la máquina, si no tienes tiempo o paciencia) para volver a tomar el control.

Los principales ajustes que necesitamos hacer se encuentran en nueve líneas del archivo /etc/apache2/apache2.conf. A continuación tienes los valores por defecto en una instalación básica de Debian 6: Ten cuidado porque las cinco últimas se encontraran duplicadas en el interior de sentencias condicionales segun el módulo MPM que estemos usando. Las que nos interesan hoy son las que están tras la sentencia <IfModule mpm_prefork_module>.

1
2
3
4
5
6
7
8
9

Timeout 		300
KeepAlive 		On
MaxKeepAliveRequests	100
KeepAliveTimeout   	15
StartServers        	5
MinSpareServers     	5
MaxSpareServers     	10
MaxClients		150
MaxRequestsPerChild	0

Timeout, el primero de ellos, define el tiempo en segundos que Apache esperará a determinados eventos antes de cerrar o abortar una conexión. En servidores con pocos recursos 300 segundos puede ser una cantidad bastante elevada. Reducir ese tiempo sustancialmente ayudará a gestionar mejor la memoria del servidor. Valores de 30 o 40 son adecuados en servidores con pocos recursos. Un valor de 10, incluso, podría mejorar el rendimiento en determinados entornos.

Los tres parámetros siguientes (KeepAlive, MaxKeepAliveRequest y KeepAliveTimeout) definen la posibilidad de usar conexiones persistentes y la forma de tratarlas. En concreto, el número de peticiones que se permitirán sobre cada conexión (MaxKeepAliveRequest) y el tiempo de espera sin peticiones antes de abortarlas. Tener habilitadas este tipo de conexiones reduce sustancialmente la carga del servidor y los tiempos de respuesta y el número de peticiones se puede mantener en torno a 100 en casi cualquier entorno. Es, de nuevo, el Timeout por defecto de 15 segundos el que puede resultar demasiado elevado en servidores con poca RAM y podríamos reducirlo a un valor de 5 segundos o incluso menos.

Los cinco parámetros restantes son los que definen el comportamiento del módulo Prefork. StartServers, MinSpareServers y MaxSpareServers ajustan, respectivamente, el número de procesos apache que se crearan inicialmente, y el mínimo y máximo de estos que mantendremos inactivos a la espera de que lleguen peticiones de posibles clientes. Los procesos inactivos definidos por estos parámetros estarán consumiendo memoria pero nos permitirán dar una respuesta más rápida a los clientes (los procesos están ya listos para usarse cuando llegan peticiones y no hay que perder tiempo en crearlos), así que en un servidor con grandes recursos y que espera cargas elevadas querríamos tener valores más elevados de los que vienen por defecto mientras que en un servidor pequeño podríamos reducirlos todos a, por ejemplo, 3 o 4.

MaxClients es, posiblemente, el parámetro más importante. Define el máximo número de procesos simultaneos que nuestro servidor podrá crear para atender peticiones. Un número más pequeño del que podemos permitirnos desperdiciará memoria y ralentizará las peticiones de muchos clientes (que permanecerán a la espera de que uno de estos procesos se libere para atenderle) mientras que un número demasiado elevado agotará la memoria del servidor y lo obligará a hacer swapping a disco. Y aquí no hay fórmulas mágicas. Lo primero que se nos puede ocurrir es que dividiendo la memoria que tenemos disponible entre lo que ocupa cada proceso de Apache obtendríamos el número que necesitamos, pero el problema es que la memoria disponible es difícil de calcular de forma exacta (ya que, posiblemente, tendremos también un servidor mysql, servicios de correo, etc). Además, los procesos de apache no consumen todos la misma cantidad de memoria. Si tenemos distintas instancias de apache con características muy diferentes la diversidad será aún mayor. Podemos verlo en el siguiente pantallazo de htop tomado de un servidor apache funcionando con varias instancias web diferentes:

La columna MEM% nos da el porcentaje de memoria que está ocupando el proceso de apache y, como vemos, tenemos cifras entre 0.5% y 4.2%, es decir, entre 4 y 32 Mbytes (la máquina es un VPS con 768Mbytes). Si aproximamos que disponemos de 600Mbytes disponibles para que apache los use nos saldrían cifras de entre 150 y 18 procesos simultaneos. Una horquilla demasiado grande. Si somos muy, muy conservadores podemos irnos al borde inferior de la horquilla y asegurar que nunca entraremos en zona de riesgo. Podemos también dedicarle tiempo a estudiar el comportamiento medio de nuestros clientes y hacer medias de la utilización de memoria por los procesos de Apache. Lo más rápido para empezar es tomar un valor medio, por ejemplo de un 2.5% o un 3% y ajustar por ahí el número máximo de procesos. Entre 25 y 40 en este caso. El hecho de que hayamos bajado mucho los Timeouts ayudará a que los procesos se liberen rápidamente y se turnen atendiendo a los clientes que están a la espera con lo que no deberíamos de notar demasiado la espera.

Tenemos aún otro parámetro más. MaxRequestsPerChild marca el número de peticiones que atenderá cada proceso antes de reciclarse. El valor por defecto es cero que indica un número indefinido. Poner un número elevado pero no ilimitado ayudará también a que nuestro servidor libere y sanee su memoria de forma regular. Un valor de entre 500 o 1000 podría ser adecuado para nuestra pequeña máquina. Nuestra configuración final podría quedar así:

1
2
3
4
5
6
7
8
9

Timeout 		10
KeepAlive 		On
MaxKeepAliveRequests	100
KeepAliveTimeout   	5
StartServers        	3
MinSpareServers     	3
MaxSpareServers     	4
MaxClients		30
MaxRequestsPerChild	600

No olvides que hay que reiniciar el servicio de apache (service apache2 restart) después de realizar cualquier modificación en este fichero de configuración para que los cambios tomen efecto.

Vamos a seguir sacándole partido a la configuración de AWStats que empezamos el otro día. Una de las opciones que tenemos disponible y que lo pone también por delante de los gestores de estadísticas que no leen directamente los ficheros de log del servidor es la posibilidad de generar informes de nuestros servidores de FTP y de correo. Hace tiempo que no uso servidores de FTP en mis servidores (prefiero la transferencia por SFTP que sólo requiere tener instalado el servicio de SSH) pero la posibilidad de tener datos estadísticos de mi servidor de correos si que me resulta interesante. Este sería el aspecto de las estadísticas recogidas:

La instalación, si seguiste el paso a paso del otro día, es inmediata. Si no lo hiciste ve echándole un vistazo al mismo tiempo que lees esto porque no vamos a repetir lo que ya está allí.

La configuración del virtual host de Apache es ideńtica, así que nada que añadir a ese punto. Para crear el fichero de configuración de awstats procederemos igual (usando como base el modelo del fichero /usr/local/awstats/wwwroot/cgi-bin/awstats.model.conf) pero en este caso las directivas a tocar serán las siguientes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

LogFile="perl /usr/local/awstats/tools/maillogconvert.pl standard < /var/log/mail.log |"
LogType=M
LogFormat="%time2 %email %email_r %host %host_r %method %url %code %bytesd"
SiteDomain="mail.morales-vazquez.com"
HostAliases="mail.morales-vazquez.es"
DNSLookup=1
DirData="/var/lib/awstats"
DirCgi="/awstats"
DirIcons="/awstatsicons"
AllowFullYearView=3
LevelForBrowsersDetection=0
LevelForOSDetection=0
LevelForRefererAnalyze=0
LevelForRobotsDetection=0
LevelForWormsDetection=0
LevelForSearchEnginesDetection=0
LevelForFileTypesDetection=0
ShowMenu=1
ShowSummary=HB
ShowMonthStats=HB
ShowDaysOfMonthStats=HB
ShowDaysOfWeekStats=HB
ShowHoursStats=HB
ShowDomainsStats=0
ShowHostsStats=HBL
ShowAuthenticatedUsers=0
ShowRobotsStats=0
ShowEMailSenders=HBML
ShowEMailReceivers=HBML
ShowSessionsStats=0
ShowPagesStats=0
ShowFileTypesStats=0
ShowFileSizesStats=0
ShowBrowsersStats=0
ShowOSStats=0
ShowOriginStats=0
ShowKeyphrasesStats=0
ShowKeywordsStats=0
ShowMiscStats=0
ShowHTTPErrorsStats=0
ShowSMTPErrorsStats=1

Las tres primeras líneas son las más importantes. En la primera preprocesamos el fichero de log de nuestro servidor de correo (/var/log/mail.log) mediante el programa maillogconvert.pl. En la segunda línea indicamos que se trata de un log de correo y en la tercera especificamos el formato del mismo. Las líneas entre la 4 y la 10 son las mismas que ya vimos el otro día y a partir de la 11 desactivamos algunas directrices que no tienen sentido más que en servidores web y activamos otras propias de la información que queremos recoger en un servidor de correo.

La programación a intervalos de la lectura de logs mediante cron es también idéntica a la vista en el anterior artículo, pero en este caso crearemos un fichero sh independiente del que ya teníamos para luego usarlo también en la rotación de logs del servidor de correo. En mi caso lo he llamado /etc/awstats/cron-awstats-mail.sh y contiene las siguientes líneas:

1
2
3

#!/bin/sh
perl /usr/local/awstats/wwwroot/cgi-bin/awstats.pl -config=mail -update
perl /usr/local/awstats/wwwroot/cgi-bin/awstats.pl -config=mail -databasebreak=day -update

Añadimos otra línea como esta en nuestro fichero de crontab:

1

*/15 * * * * root /etc/awstats/cron-awstats-mail.sh > /dev/null

Tenemos aún que apañar el tema de la rotación de logs. Los logs del servidor de correo se “limpian” semanalmente y la configuración de este proceso la encontramos en el fichero /etc/logrotate.d/rsyslog. Editamos este fichero y, casi al final del mismo y antes de la directiva postrotate, incluimos las siguientes dos líneas:

1
2

prerotate
      /etc/awstats/cron-awstats-mail.sh > /dev/null

Y esto es todo. La extensión Day by Day de la que hablábamos el otro día funciona perfectamente también con las estadísticas del servidor de correo y para añadirlas el procedimiento es el mimo que ya habíamos visto. Suerte con ello.