SyntaxHighlighter

jueves, 3 de octubre de 2013

Load Testing Moodle con Jmeter

Jmeter es una herramienta muy útil para hacer test de carga de distintas aplicaciones. Es tan flexible puede servir para poner a prueba tanto una aplicación web, como un servidor de base de datos o incluso un servicio tipo SOAP.

La potencia de Jmeter radica en la capacidad para simular la actividad de usuarios o las peticiones a un determinado servicio o aplicación, de forma concurrente. Estas pruebas nos pueden ayudar en el dimensionamiento del servidor, posibles fallos o problemas derivados de la concurrencia, etc.

Otra característica muy interesante de la herramienta es que puede "grabar" la actividad del navegador para después lanzar una determinada cantidad de usuarios o "hebras" que ejecuten esta misma actividad. Esto se realiza creando un proxy en jmeter al que debemos apuntar nuestro navegador. Jmeter se encargará de ir almacenando todas las peticiones que se realicen. Para encontrar más información podéis buscar "jmeter proxy record" o términos similares.

Obviamente cualquier prueba de carga nunca debería ser ejecutada en un servicio/servidor de producción.

Para ponerse al día con la herramienta lo mejor es pasar por su documentación y buscar algún ejemplo en concreto e ir modificándolo para adaptarlo a nuestras necesidades. Esto mismo es lo que he hecho yo, basándome en un plan de pruebas existente en los foros de moodle.org (todos los agradecimientos a su autor). A partir de este plan de pruebas he ido parametrizando algunos procedimientos y adaptando su funcionamiento a los cambios de Moodle v2.5.

Las tareas que he incluido en el plan son:
  • Abrir la página principal de Moodle
  • Login en Moodle
  • Entrar en el curso
  • Acciones del usuario en orden aleatorio:
    • Actividad de texto
    • Mensaje en el chat
    • Mensaje en el foro y contestar a un mensaje en el foro
    • Subir un fichero a archivos privados
    • Enviar un fichero a una actividad (implica subir fichero)
  • Salir de Moodle

Peticiones y respuestas

La forma de proceder para cada una de las tareas de nuestro test será la siguiente:
  1. Realizar una petición al servidor web con una serie de parámetros
  2. Recibir la respuesta del servidor y comprobar que se ha realizado con éxito
  3. Capturar nuevos parámetros que nos serán útiles en peticiones posteriores
  4. Realizar una pausa aleatoria antes de llevar a cabo la siguiente petición y así adaptar el test a los tiempos que emplearía un operador humano.
Pero... ¿Cómo sabemos si una petición ha sido correcta? Lo más indicado es seguir los pasos "manualmente" en el navegador y así ver (directamente en pantalla o abriendo el código fuente devuelto) cual es la respuesta de la plataforma a cada clic. De esta manera podemos ir identificando los textos que se presentarán después de cada petición y utilizarlos en Jmeter.

Bien, ya hemos considerado dos de los elementos más importantes en el diálogo que se establece entre nosotros (o nuestro navegador) y el servidor web: peticiones y respuestas. Pero hay un elemento que aún falta y que es imprescindible si queremos simular ese diálogo: las cookies!! 

Como ya sabéis prácticamente todas las aplicaciones web utilizan cookies. Moodle también necesita crear una cookie en el navegador del usuario para mantener la sesión. En Jmeter dispondremos de un objeto que hará de gestor de cookies de manera que "cada usuario virtual" pueda mantener una sesión con el servidor.

El plan

Variables globales

Definir las "variables globales" del experimento. Como por ejemplo el host al que accederemos y el path dentro de ese host que aloja la plataforma. Esto no es obligatorio, pero siempre está bien para poder cambiar la máquina o la ruta de forma fácil. Si no parametrizamos estos datos tendremos que modificar cada petición cuando queramos probar contra otra máquina o si ha habido cambios en la ruta.
Estas variables no varían durante toda la ejecución del plan, por lo que podemos definirlas a nivel de "Test Plan".
Si llamamos a las variables host y path, cada vez que hagamos una petición podremos utilizar la ruta ${host}${path}. Supongo que queda claro que para hacer referencia al valor de una variable debemos utilizar la forma ${variable}.
Además de estas variables también he definido una ruta para el almacenamiento de los resultados de los tests, donde utilizo la expresión ${__time(yyyyMMdd_HHmm)} que devuelve la fecha y hora en la que se realizó el test.

Grupo de hilos

El siguiente elemento a definir es nuestro grupo de hilos (cuantos hilos y cuantas veces queremos repetir cada hilo). Este elemento será el que contendrá el resto de objetos de nuestro plan. Dentro de este objeto definimos elementos para cada una de las hebras (usuarios) que lanzamos. Esto queda claro si nos detenemos en el elemento UserParameters que contiene una serie de variables que distintas para cada hebra. Por ejemplo, cada hebra accederá con un usuario/contraseña distintos, para ello se sortea  un número del 1 al 10 con la función __Random y se añade al prefijo de usuario y al prefijo de contraseña (UsernameHead y PasswordHead respectivamente). También se tienen los nombres de los objetos de Moodle a los que accederemos: jmeter course, jmeter text assignment, jmeter forum, etc. Estos objetos, así como los usuarios deben estar creados previamente en la instalación de Moodle sobre la que estamos trabajando.

Interacciones con la plataforma

Analizaremos sólo una de las peticiones/respuestas, por ejemplo, la de login. El resto de peticiones son muy similares. Como se ve en la imagen, definimos las variables de la petición en el espacio Parameters. Estos parámetros construyen usando las variables que hemos definido en el grupo de hilos. En la parte superior de la ventana se da el host y el path completo de la petición.



Y ahora podemos comprobar si es usuario se ha identificado correctamente en la plataforma buscando la cadena "you are logged in as", que aparece en cualquier página de Moodle una vez que el usuario se ha identificado. Para ello añadimos un elemento del tipo Response Assertion y la configuramos para que busque la cadena en la respuesta del servidor.


De la respuesta que nos da el servidor también debemos extraer más cosas. Moodle necesita en muchas de las llamadas un id de session sesskey y además nosotros necesitamos el id del curso al que queremos acceder para realizar la próxima llamada que será del tipo

${host}${path}/course/view.php?id=${courseid}

Para obtener el id del curso, por ejemplo, configuramos un elemento de tipo Xpath Extractor que revisará la respuesta del servidor y buscará el id del curso. La expresión que se ha usado es:

substring-after(//*/a[text()='${course_name}']/@href,'=')

Explicación breve:

La función substring-after busca un carácter dentro de una cadena y devuelve la subcadena que hay después de ese carácter.

Lo que hay dentro de la función es una expresión xpath. Estamos diciendo que busque un enlace (tag "a" de HTML) en cualquier parte del documento que tenga como texto el nombre del curso (recordad que lo tenemos definido en las variables) y devuelva el valor de su atributo href. Si el enlace en cuestión es

<a class="" href="http://host/path/course/view.php?id=33">jmeter course</a>

La función devolverá lo que hay después del "=", dentro del atributo href, es decir, 33.



Después se incluyen dos elementos, en elemento de retardo para simular la interacción humana y otro que irá construyendo un gráfico con todas los valores obtenidos en cuando los usuarios ejecuten la tarea en cuestión.

Controladores lógicos

Después de entrar a la plataforma programaremos una serie de tareas que deberán realizar todos los usuarios. Para ello vamos a incluir un controlador lógico de orden aleatorio... ¿Qué quiere decir esto? Las tareas que se incluyen dentro de este controlador serán ejecutadas por las hebras de forma desordenada. Unas hebras entregarán la actividad primero, otras postearán en el foro, etc. Todo para intentar que la actividad sea todo lo "caótica" que podría ser en un periodo de alta actividad en el servidor web.

Subida de ficheros

Además de los parámetros típicos, ya sean vía metodos GET o POST del servidor podemos utilizar ficheros para que sean subidos a la plataforma. En un objeto Request se pueden incluir ficheros dando la ruta al fichero en la sección Send files with the request. Además del MIME/Type y el nombre del parámetro con que se enviará el mismo.



Esto es muy útil cuando estamos probando aplicaciones que previsiblemente recibirán ficheros de cierto tamaño mientras siguen respondiendo a peticiones de otros usuarios.

Depurado

Para intentar detectar fallos en nuestro plan o fallos en nuestra aplicación tenemos dos herramientas básicas que nos ayudarán: El debug sampler y el objeto View Result Tree. Con el primero tendremos acceso a todas las variables y parámetros que hemos definido en el plan. Con el segundo podremos ver el diálogo entre el cliente y el servidor a bajo nivel, es decir, las cabeceras de la petición HTTP, los parámetros que se han enviado y la respuesta del servidor en HTML, los mensajes de error del servidor en caso de que los hubiera, etc. Como vemos en la figura muestra las el resultado de las assertions que hemos definido, para que detectemos fácilmente errores en el script. Si alguna respuesta del servidor no verifica la condición que hemos establecido, en lugar del triángulo verde mostraría un símbolo rojo informando del fallo.


Resultados

Los datos que genera Jmeter serán normalmente el tiempo que ha llevado cada petición contando desde que se ha enviado la misma hasta que se ha recibido la respuesta al completo. Para visualizar estos datos tenemos muchas opciones aunque las más interesantes son el simple data writer que generará un archivo con los datos en crudo para poder ser procesados posteriormente con otra herramienta o cualquiera de las opciones gráficas o de resumen que dan algunas medidas estadísticas. Todas estas opciones pueden ser utilizadas simultáneamente añadiéndolas desde la sección Listeners. Además cualquiera de estos informes pueden ser salvados a fichero para un posterior análisis en un fichero en disco.
En un post siguiente mostraré los resultados de una ejecución contra varias instalaciones de Moodle y lo más interesante y complejo: cómo interpretar los resultados... Pero para eso aún me faltan conos y bastones que quemar.

Descargar fichero de test

lunes, 9 de septiembre de 2013

Amanda Backup II: Órdenes útiles

Más en la página oficial de Amanda.

Información

Ver las información sobre las copias existentes para un determinado recurso, en este caso /var. Podemos ver la fecha del dump, la cinta y el nivel (0=full 1=diff >1=inc).

[amandabackup@host root]$ amadmin DailySet1 find host.domain /var

date                host        disk         lv tape or file     file part status
2013-03-11 13:58:04 host.domain /var/backups  0 DailySet1-01    1  1/1 OK
2013-03-12 07:05:02 host.domain /var/backups  0 DailySet1-02    1  1/1 OK
2013-03-13 07:05:02 host.domain /var/backups  1 DailySet1-03    1  1/1 OK

Determinar cual es la próxima cinta en el programa.
[amandabackup@host root]$ amadmin DailySet1 tape
The next Amanda run should go onto 1 new tape.
The next new tape already labelled is: DailySet1-04.

Estado de las últimas copias. Fecha y nivel de backup usado.
[amandabackup@host root]$ amoverview DailySet1 

         date                 03 03 03
host     disk                 11 12 13

host /etc                  0  1  1
host /var/backups          0  0  1


Backup

Forzar copia completa. Se deben especificar al final qué "discos" se respaldarán.
amadmin DailySet1 force host.domain /var/backups /etc
Realizar Dump (usando su para no tener que cambiar de usuario)
su -c "amdump DAilySet1" amandabackup

Recuperación

amrecover

Lo mejor es usar la herramienta amrecover, que funciona de forma similar a un ftp interactivo: tienes órdenes para moverte por las copias de seguridad y órdenes con prefijo "l" para moverte los por directorios de la máquina local desde la que se ejecuta la herramienta. 
Órdenes dentro de recover:
  • listdisk: lista los discos (directorios respaldados) en el host activo.
  • setdisk: Establece el disco (directorio respaldado) sobre el que vamos a trabajar.
  • history: Muestra el histórico de las copias que se han hecho sobre ese disco, incluyendo la fecha, el nivel de respaldo (0-full) y la cinta en la que se encuentra.
  • setdate: Establece la fecha sobre la que trabajaremos, de manera que la copia que se recupere será la última que había en esa fecha. Si no se establece una distinta se tiene en cuenta la fecha actual, recuperándose la última copia.
  • add [fichero o path]: Admite comodines. Añade ficheros o directorios a la lista de extracción.
  • lcd: Similar al de cualquier ftp. Establece el directorio local. Cuando se haga un extract se recuperará a ese directorio.
  • extract: Extrae la lista de extracción al directorio local.
  • help: Muestra la ayuda.
  • quit: Salir.

Esta herramienta debe ejecutarse con el usuario root. Ejemplo de uso: OJO!! A veces extract no funciona directamente porque no reconoce el dispositivo. Para solucionarlo hay que ejecutar la orden setdevice /dev/nst0 (ver el ejemplo).

amrestore

No hace falta acceder al índice de Amanda. Lee directamente de la cinta y extrae los archivos que encuentra.
Orden para extraer todos los archivos que hay en una cinta al directorio actual:
amrestore /dev/nst0 host.domain
Esta orden extraerá los archivos encontrados en la cinta e informará del formato en el que se encuentran para poder descomprimirlos ya que por defecto no anexa la extensión del tipo de archivo al nombre del fichero sino un número que indica el nivel de backup (0=full 1=diff >1=inc). Formato para el nombre de los ficheros recuperados con amrestore:
hostname.diskname.datestamp.dumplevel
Después debemos descomprimir el archivo (normalmente será tar: tar xvf <archivo>). Si en la cinta sólo hay copias diferenciales/incrementales en los archivos solo encontraremos los ficheros que han cambiado desde la última copia aunque la estructura de directorios sí estará completa.

viernes, 2 de agosto de 2013

Amanda Backup I: Instalación y Configuración

Amanda es una de las soluciones OpenSource (BSD License) de tipo empresarial que puedes utilizar para realizar copias de seguridad de tus servidores.

Una de las características que me hicieron elegir este software frente a otros a la hora de hacer backup de los datos más importantes de mi empresa es que no utilizar ningún tipo de formato propio para almacenar esas copias, es decir, puedes recuperar las copias de seguridad desde otra máquina sin la necesidad de tener instalado/configurado el software, puedes manejar todo el proceso con órdenes estándar del sistema operativo, como tar, mt, cron, etc.
Es un software muy potente comparable a Bacula, por ejemplo, y que tiene una estructura similar: habrá una máquina que hará de servidor de copias de seguridad que atenderá a varios clientes siguiendo una agenda determinada. La instalación y configuración es bastante sencilla, quizás más que la de Bacula, la herramienta

En esta entrada haré un repaso de la instalación y configuración del software en un equipo HP Proliant con una unidad de cinta Ultrium 232 (LTO1) algo antigua, en la que se ejecuta un sistema CentOS 6.

Backup en cintas

Para ejecutar Amanda usando la unidad Ultrium como dispositivo de copia de seguridad  debemos tener instaladas todas las herramientas de sistema que trabajarán de forma subyacente, especialmente mt-st:
yum install mt-st

Comprobamos la unidad de cinta:

[root@host ~]# cat /proc/scsi/scsi 
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: HL-DT-ST Model: CD-ROM GCR-8486B Rev: 2.00
  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi3 Channel: 00 Id: 03 Lun: 00
  Vendor: HP       Model: Ultrium 1-SCSI   Rev: P61D
  Type:   Sequential-Access                ANSI  SCSI revision: 03
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: BENQ     Model: DVD DD EW162I    Rev: 47F9
  Type:   CD-ROM 
[root@host ~]# dmesg | grep -i tape
st 3:0:3:0: Attached scsi tape st0
osst :I: Tape driver with OnStream support version 0.99.4


Tenemos la unidad ultrium en st0. Aquí tenemos una de las primeras curiosidades con respecto a la gestión de dispositivos secuenciales: las interfaces /dev/st0 y /dev/nst0 ser refieren al mismo dispositivo, la diferencia es que si usamos st0 el sistema considerará el dispositivo como "rebobinable" en cambio si usamos nst0 accederemos a un dispositivo "no rebobinable". La diferencia es que después de cualquier operación sobre st0 la cinta se rebobinará, por lo tanto toda operación sobre la cinta comenzará en el bloque 0 lista para una operación de "rewrite". En el dispositivo nst0, después de una operación la cinta estará lista para una operación de "append" sin destruir los datos grabados hasta el momento.

Comprobaré que la cinta funciona correctamente, por ejemplo, extrayendo información sobre la misma o extrayendo la unidad:

mt -f /dev/nst0 offline # Extrae la cinta

[amandabackup@host root]$ mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=1, partition=0.
Tape block size 0 bytes. Density code 0x40 (DLT1 40 GB, or Ultrium).
Soft error count since last status=0
General status bits on (1010000):
 ONLINE IM_REP_EN


Al intentar ejecutar otras órdenes en las que si se accede a la cinta como mt -f /dev/nst0 tell, que dice el bloque en que se encuentra la cinta, da un error de entrada salida. Para solucionarlo se han de ejecutar estas dos órdenes: Más información sobre la configuración de las cintas Ultrium en los manuales de HP.

mt -f /dev/nst0 stsetoptions scsi2logical # Hace que el driver st use direccionamiento lógico
mt -f /dev/nst0 setblk 0                  # Establece la lectura de bloques de tamaño variable. Ver enlace de Info anterior.

Instalación y configuración de Amanda

Server: Instalación


Una vez comprobado el funcionamiento de la unidad de cinta continuamos con la instalación y configuración de Amanda en CentOS. Vamos a configurar Amanda para que realice copias de seguridad del mismo servidor (local), así que necesitamos instalar el software de cliente y de servidor. 

yum install amanda amanda-server amanda-client

La instalación en CentOS crea el usuario amandabackup que será desde el que realizaremos la mayoría de las interacciones con Amanda. También crea los grupos disk y tape en los que incluirá al usuario amandabackup, estos grupos tendrán permisos para acceder a varios directorios, dispositivos y ficheros de configuración necesarios. También crea archivos de configuración que tendremos que modificar. En el directorio /etc/amanda y /etc/amanda/DailySet1 tenemos también plantillas de archivos de configuración.
Amanda se ejecuta vía xinetd, así que tendremos que configurar el servicio. Aunque la instalación ha creado el archivo en /etc/xinetd.d/amanda sustituimos por el archivo xinetd.amandaserver que encontramos en el directorio /etc/amanda/DailySet1/. Este archivo define los servicios de Amanda que estarán activos en el servidor, estos servicios vienen determinados por el parámetro server_args.

  • amdump. Es el servicio (máquina cliente y servidor) que se encarga de realizar las copias de seguridad.
  • amindexd. Es el servicio (servidor) que mantiene el catálogo de Amanda. Muchas herramientas de Amanda se comunican con este servicio. Es necesario para ejecutar amrecover, la herramienta interactiva de recuperación de datos, es muy similar a un servicio de FTP que es accedido por la herramienta amrecover.
  • amidxtaped. Servicio (servidor) que se comunica con la unidad de cinta.
Archivo /etc/xinetd.d/amanda

# default: on
#
# description: Amanda services for Amanda server and client.
#
service amanda
{
        disable         = no
        flags           = IPv6
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = amandabackup
        group           = disk
        groups          = yes
        server          = /usr/lib64/amanda/amandad
        server_args     = -auth=bsdtcp amdump amindexd amidxtaped
}

Siempre que hagamos algún cambio en este archivo debemos recargar xinetd con la orden service xinetd reload.

Server: Configuración de los trabajos de copia

La configuración de los trabajos de copia de seguridad se hace desde los subdirectorios dentro de /etc/amanda. Por ejemplo, hemos copiado la configuración por defecto que incluye la instalación al directorio DailySet1. Dentro de este directorio establecemos todos los parámetros para realizar las copias de seguridad. Hay que tener en cuenta que para casi cualquier operación que hagamos con Amanda tendremos que especificar este identificador.
El fichero principal es el fichero amanda.conf dentro del directorio de configuración. Los cambios más importantes son:
mailto= "admin@email.es"     # Email que recibirá las notificaciones. Hay que modificar .mailrc en /var/lib/amanda/ para que funcione. Después se explica.
dumpuser="amandabackup"     # Usuario que se utiliza para ejecutar dump en el cliente.

dumpcycle 1 weeks           # Asegura al menos haya una copia completa cada 1 semana
runspercycle 4              # Cuantas veces se lanza el dump cada dumpcycle
tapecycle 4 tapes           # Número de cintas que se conservan antes de empezar a reciclar.

runtapes 1                  # Número de cintas que se permiten para un trabajo de copia. Si una copia no cabe en una cinta debemos subirlo. Sólo se usan las necesarias.
#tpchanger "scrtip"         # Script que se encarga de cambiar cintas. Como cambiaremos las cintas manualmente comentamos.
tapedev "tape:/dev/nts0"    # Dispositivo que se usa para realizar las copias.
tapetype HP-ULTRIUM-LTO1    # Tipo de cinta. HP-ULTRIUM-LTO1 debe estar definido como tipo de cinta en la sección ''define tapetype''. Ver más adelante.
labelstr "^DailySet1-[0-9][0-9]*$"     # Expresión regular que restringe la etiqueta de las cintas que se aceptan. Todas las cintas ser etiquetadas según este patrón.

#holdingdisk  hd1 {         # Discos buffer en los que se hará un dump previo, después se copiará a la cinta. Desactivado (comentado) por problemas de espacio en el servidor.
#...
#}

infofile "/etc/amanda/DailySet1/curinfo"    # database DIRECTORY
logdir   "/etc/amanda/DailySet1"            # log directory
indexdir "/etc/amanda/DailySet1/index"              # index directory
tapelist "/etc/amanda/DailySet1/tapelist"   # list of used tapes

define tapetype HP-ULTRIUM-LTO1 {          # Definición de la cinta. Extraída del enlace http://tirpitz.iat.sfu.ca/wiki/index.php?title=Backups_with_AMANDA
    comment "LTO-1. Añadido por Emilio"    # Amanda puede examinar la cinta para obtener su definición usando la orden 'amtapetype -f /dev/nst0'
    length 96512 mbytes
    filemark 0 kbytes
    speed 13611 kps
}

# A continuación vienen las definiciones de los tipos de dumps estándares. En el fichero se comentan todas las opciones posibles y se pueden crear nuevos o modificar existentes, 
# que después habrá que especificar en el fichero disklist. Estas definiciones se pueden anidar, como se ve en el ejemplo. Estamos usando comp-user-tar, cuya definición es:
define dumptype global {
    comment "Global definitions"
    # This is quite useful for setting global parameters, so you don't have
    # to type them everywhere.  All dumptype definitions in this sample file
    # do include these definitions, either directly or indirectly.
    # There's nothing special about the name `global'; if you create any
    # dumptype that does not contain the word `global' or the name of any
    # other dumptype that contains it, these definitions won't apply.
    # Note that these definitions may be overridden in other
    # dumptypes, if the redefinitions appear *after* the `global'
    # dumptype name.
    # You may want to use this for globally enabling or disabling
    # indexing, recording, etc.  Some examples:
    # index yes
    # record no
    # split_diskbuffer "/raid/amanda"
    # fallback_splitsize 64m
    auth "bsdtcp" # Añadido para forzar la autenticación bsdtcp
}


define dumptype root-tar {
    global
    program "GNUTAR"
    comment "root partitions dumped with tar"
    compress none
    index
#   exclude list "/etc/amanda/exclude.gtar"
    priority low
}
define dumptype user-tar {
    root-tar
    comment "user partitions dumped with tar"
    priority medium
}
define dumptype comp-user-tar {
    user-tar
    compress client fast
}

...
...
Puede que al hacer un amcheck <ID> no se pueda conectar al cliente dando este error:

[amandabackup@host root]$ amcheck DailySet1
Amanda Tape Server Host Check
-----------------------------
read label `DailySet1-04', date `20130314070502'.
Tape with label DailySet1-04 is still active and cannot be overwritten.
       (expecting tape DailySet1-01 or a new tape)
Server check took 0.096 seconds

Amanda Backup Client Hosts Check
--------------------------------
WARNING: host: selfcheck request failed: timeout waiting for ACK
Client check: 1 host checked in 30.036 seconds.  1 problem found.

(brought to you by Amanda 2.6.1p2)
Se soluciona especificando en amanda.conf el tipo de autenticación en la definición dumptype. Yo lo he añadido en la definición de dumptype global, como aparece en el enlace.

Ahora debemos indicar a Amanda las máquinas a las que tendrá que acceder, los datos que deberá respaldar y el tipo de dump que realizará para cada uno. Esto se hace mediante el archivo disklist dentro del directorio /etc/amanda/DailySet1:

host  /var/backups comp-user-tar
host  /etc   comp-user-tar

Antes de poder hacer copias de seguridad debemos etiquetar las cintas para que sean reconocidas por amanda. Para ello introducimos una por una las cintas y las etiquetamos de la siguiente forma, donde XX es el número de cinta:
amlabel DailySet1 DailySet1-XX

Cada vez que etiquetemos una cinta se añadirá al archivo /etc/amanda/[id]/tapelist. Se puede listar este fichero para ver las cintas.
Para comprobar que funciona podemos ejecutar:
[amandabackup@host root]$ amcheck DailySet1
Amanda Tape Server Host Check
-----------------------------
read label `DailySet1-02', date `20130312070502'.
Tape with label DailySet1-02 is still active and cannot be overwritten.
       (expecting a new tape)
WARNING: tapecycle (4) <= runspercycle (4).
Server check took 0.097 seconds

Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 2.135 seconds.  0 problems found.

OJO! Esta salida se obtiene una vez configurado todo, la salida real en esta etapa de configuración debería ser similar, lo importante es que no aparezcan problemas en el resultado.

Server: Cron

En el directorio /etc/amanda/ hay un ejemplo de cron. Se puede modificar el cron del usuario amandabackup para programar las copias. Cambiarse al usuario amandabackup y hacer un crontab -e. El contenido actual (pruebas) es el siguiente:

#Amanda Backup
00 07 * * 1-5    /usr/sbin/amcheck -m DailySet1
05 07 * * 1-4    /usr/sbin/amdump DailySet1

Server: Notificaciones por email

Para que funcionen las notificaciones de las copias de seguridad hay que configurar los parámetros de envío creando el archivo /var/lib/amanda/.mailrc:

set smtp=[smtp server]
set from=[admin@email.es]

Client

Primero debemos configurar el servicio amanda en xinetd. Esto ya lo hemos hecho ya que el servidor también es el cliente. Permitir al servidor que acceda al servicio amanda. Para esto se modifica el fichero /var/lib/amanda/.amandahosts:

# host user services. 
# root en el cliente accederá a los servicios amindexdx y amidxtaped para recuperar ficheros.
# amandabackup accederá al servicio amdump
server1 root amindexd amidxtaped
server1 amandabackup amdump

En un segundo post haré un repaso por las órdenes más útiles para hacer copias de seguridad, restauraciones, extraer información del catálogo... Además del manejo de las copias realizadas con herramientas del sistema como mt o tar.

martes, 9 de abril de 2013

Revisión de opciones para el uso de la plataforma Moodle en dispositivos Móviles

Aceptado el artículo que hemos escrito Vanesa Gámiz Sánchez y yo en la revista RED donde hablamos de las distintas alternativas para acceder a Moodle con dispositivos móviles.

Abstract.

Los espacios y modelos de aprendizaje se han visto modificados radicalmente en los últimos tiempos gracias al avance de las tecnologías de la comunicación que han hecho posible el acceso y la producción de grandes cantidades de información; el desarrollo de aplicaciones y herramientas para mejorar la interacción entre las personas; y la extensión de dispositivos que han permitido el aumento de la movilidad de los usuarios. En este artículo analizamos cuáles son las circunstancias que están permitiendo el desarrollo y la expansión del uso de los dispositivos móviles en los procesos de aprendizaje en lo que se conoce como mobile learning o m-learning. En especial, nos interesa su implementación a través del entorno de enseñanza virtual Moodle. Para su estudio revisamos brevemente las opciones móviles más usadas para acceder a la plataforma Moodle ya sean aplicaciones nativas o plantillas/temas optimizados para dispositivos móviles. Por último, proponemos una de las metodologías más usadas para analizar la usabilidad de soluciones móviles, adaptándola al ámbito del estudio.

Enlace al texto completo.

miércoles, 13 de marzo de 2013

Fuentes de ancho fijo en GMAIL

Algo muy molesto para los que normalmente recibimos notificaciones automáticas mediante correo electrónico en texto plano de aplicaciones, servidores, etc., es que gmail no utiliza fuentes de ancho fijo. Muchos de los servicios que instalamos en una máquina envían notificaciones simulando tablas y gmail nos destroza las tabulaciones. Mejor verlo: este es un ejemplo de informe de una herramienta de copia de seguridad (Amanda).

Para solucionar esto podéis instalar el complemento de Chrome Fixed Width Text for Gmail, el resultado será mucho más cómodo de leer:


La extensión sólo modificará los correos que reconozca como texto plano, por lo que el resto de correos electrónicos más "complejos" se verán como siempre.

Mejor no??