Ayer fue el aniversario de la inauguración oficial de la web de CRySoL. Sin duda algunos de los que la pusimos en marcha, con más ganas que esperanzas, no creíamos que fuera a ir tan bien.
Por que no sólo de GNU/Linux vive el hombre, vamos a describir brevemente la instalación y el uso de un sistema operativo libre denominado TinyOS. Este sistema operativo esta destinado a redes inalámbricas de sensores por lo que necesitaremos para probarlo alguna de las plataformas soportadas por el sistema operativo o el simulador TOSSIM.
Instalación TinyOS 2.0
Vamos a aprender su instalación y dejaremos para más adelante la construcción de un pequeño hello world o incluso la instalación del propio simulador.
Se va a instalar todo en una debian con kernel 2.6.15.7
Instala Java 1.5 JDK. Se necesita para comunicarse con el nodo desde el PC.
Compilador cruzado
Esto va a depender del dispositivo para el cual quieras desarrollar una aplicación y concretamente del procesador con el que estén desarrollados. Por ejemplo, para la familia de las MICAs (dispositivos para redes de sensores) se necesita la toolchain AVR, ya que llevan unos procesadores ATMEL. En la receta supondremos que vamos a trabajar con estas motas, por lo que instalamos todo lo relativo a la citada toolchain. En debian esto implica, instalar los siguientes paquetes:
gcc-avr, el gcc para los atmel
gdb-avr, el gdb para los atmel
binutils-avr, utilidades binarias.
avr-libc, la librería estándar de C
avarice, para utilizar el gdb con JTAG (sistema para depuración típico de sistemas empotrados)
Si peiensas utilizar el apt-get para instalar todo eso será mejor que eches un vistazo a esta página de tinyOS. En resumen dice que no es buena idea, ya que necesitamos versiones muy concretas. Lo mejor es bajarse los rpm y pasar los paquetes a .deb con alien, para luego instalarlos. Un tema importante, primero desinstala todo lo que tengas de avr y no te olvides de bloquear todos los paquetes para que no se actulicen cuando hagas un “upgrade”.
Una vez que tengas los compiladores cruzados (necesarios para compilar el sistema operativo TinyOS) necesitas el compilador de nesC. nesC es el lenguaje en el que está escrito tiniyOS y que se usa también para escribir las aplicaciones. En la página web tienes paquetes rpm para el nesC (que usará los compiladores y para la toolchain de tinyOS por lo que, como esto en una debian tienes que tirar de alien para convertir los paquetes.
#alien tinyos-tools-1.2.2-1.i386.rpm
Warning: Skipping conversion of scripts in package tinyos-tools: postinst prerm
Warning: Use the --scripts parameter to include the scripts.
tinyos-tools_1.2.2-2_i386.deb generated
#dpkg --force-overwrite-i tinyos-tools_1.2.2-2_i386.deb
(Leyendo la base de datos ...
161803 ficheros y directorios instalados actualmente.)
Desempaquetando tinyos-tools (de tinyos-tools_1.2.2-2_i386.deb) ...
dpkg - aviso, no se tendrá en cuenta el problema por estar activa
una opción --force:
intentando sobreescribir `/usr/share/man/man1/uisp.1.gz', que está también en el paquete uisp
dpkg - aviso, no se tendrá en cuenta el problema por estar activa
una opción --force:
intentando sobreescribir `/usr/bin/uisp', que está también en el paquete uisp
Configurando tinyos-tools (1.2.2-2) ...
El sistema operativo
Un paso similar se realiza para instalar el sistema operativo propiamente dicho, es decir el tinyOS. Se coge el paquete .rpm se pasa a .deb con alien y se instala con el dpkg.
Configuración del entorno
Configurar las variables de entorno (mételo en un script para configurarlo de forma automática), por ejemplo en ~/bin/tinyos-setup.sh:
Y ejecuta lo siguiente cuando vayas a compilar para TinyOS:
$. ~/bin/tinyOS.sh
Cambia el propietario del directorio donde esta el tinyOS:
$chown-R felix /opt/tinyos-2.x
y no olvides cambiar los permisos del dispositivo (puerto serie, paralelo, USB) que uses para comunicarte con las motas.
chmod 666 /dev/<devicename>
graphviz
Instalar Graphviz desde su paquete debian correspondiente con
#apt-get install graphviz
Probando
Bueno, enhorabuena, si has hecho todos estos pasos, ya tienes el tinyOS instalado en tu ordenador, ahora necesitas probar todo esto que hemos hecho. No está de más echarle un vistazo a la estructura general del SO para entender como está estructurado y sus posibilidades.
La mejor forma de ver si todo esta correctamente instalado es tratar de compilar y probar algunas de las aplicaciones de ejemplo que vienen con el propio sistema operativo. Como ya habrás notado el sistema operativo se ha instalado por defecto en el directorio /opt/tinyos-2.x
Dentro de este directorio a su vez puedes encontrar los siguientes directorios:
apps: Aplicaciones de ejemplo del tinyOS
support: código fuente del toolchain
tos: el sistema operativo propiamente dicho.
Puedes probar que todo está correcto compilado una aplicación de prueba que viene con el sistema. Copia el directorio apps/Null a algún sitio de tu home. Este directorio es un esqueleto de aplicación para tinyOS, que si bien no hace nada útil, te permite comprobar que has realizado correctamente todos los pasos anteriores.
Dentro de ese directorio, ejecuta el siguiente comando:
$make <plataforma_destino>
donde plataforma_destino puede ser uno de los siguientes:
Supongamos que tenemos 60 archivos con nombres “ficheroXXX.JPEG” y queremos cambiarles el nombre a todos para que queden “ficheroXXX.jpg” (XXX quiere decir tres dígitos cualquiera; cualquier otro significado de XXX será pura coincidencia :-) Se puede escribir un comando shell que busque todos los archivos y les cambie el nombre uno a uno. Pero más fácil aún es usar el programa mmv que viene en el paquete mmv de Debian.
Tengo instalado el linux que venia con el dvd de la escula de este año y no se como darle los permisos necesarios para poder copiar y pegar en la carpetas, es decir para poder pasar el simpleScalar a usr/local. Muchas gracias por vuestra ayuda
Esta receta explica cómo instalar y preparar bacula para posteriormente montar un servicio completo de backup. Quizá lo que buscas es cómo configurar bacula para hacer backups.
Muchos de nosotros tenemos en nuestros discos duros información que valoramos de valiosa (otros sólo tienen fotos de choteras y cosas de esas :-P ). Aunque confiemos plenamente en nuestra ext3 y todas esas cosas puede ser que el día menos pensado nuestro HDD decida jubilarse sin consultarnos (¿Hace falta una receta sobre S.M.A.R.T. para conocer de antemano cuando va a decidir jubilarse un HDD?). En fin, me dejaré de tonterías y empezamos con el meollo.
Qué es bacula
Bacula es un programa para hacer copias de seguridad de una máquina... pues no del todo: bacula es una colección de demonios que cooperan entre sí para realizar copias de respaldo de los archivos necesarios, sean de la máquina que sea. Para interactuar con bacula se necesita un elemento más: la consola de bacula. Todos estos elementos son independientes entre sí y pueden estar en máquinas distintas, así pues el principal problema a la hora de configurar bacula consiste en hacer que todos estos elementos se comuniquen correctamente entre ellos.
Los elementos necesarios para que bacula funcione son:
bacula-dir (o bacula-director)
bacula-sd (o bacula-storage daemon)
bacula-fd (o bacula-file daemon)
Si, como es de suponer, queremos poder interactuar con el servicio de backup, necesitaremos:
bacula-console (disponible en varios sabores:gnome y wx)
bacula-director
Es el demonio que maneja al resto. El servidor de la base de datos MySQL debe estar accesible desde la máquina que ejecuta el director (o estar en ella misma y escuchar en localhost... como viene siendo habitual en Debian). Debe poder acceder tanto al bacula-sd como al bacula-fd para poder leer los archivos a guardar y para poder guardarlos en el soporte físico final.
En el archivo de configuración del director configuraremos dónde y cómo acceder al resto de demonios, la contraseña para el acceso mediante bacula-console y los trabajos o jobs.
bacula-storage daemon
Este demonio es el encargado de manejar el dispositivo de almacenamiento de los backups; esto exige que este demonio esté instalado en la máquina que contenga físicamente el dispositivo de almacenamiento, que puede ser: archivos en el disco local, grabadoras de CD o DVD y unidades de cinta.
Su archivo de configuración define el (o los) dispositivos de almacenamiento que maneja así como que directores pueden utilizarlo.
bacula-file daemon
Mediante este demonio bacula obtiene los ficheros que necesita respaldar, así pues éste es el componente que hay que instalar en las máquinas que necesiten respaldo.
El archivo de configuración es el más simple de todos, símplemente especifica qué directores pueden realizarle peticiones.
bacula-console
Una vez instalado y configurado bacula comenzará a realizar copias de seguridad el solito sin intervención nuestra, pero puede suceder que queramos forzar una copia cuando nosotros lo deseemos, o que tengamos que recuperar unos ficheros (protégenos Santa Tecla) o símplemente saber qué tal está nuestro bacula. Para ello necesitamos este componente, similar a una shell pero con pocos comandos (resulta hasta intuitivo... en serio...). Existen varios tipos de consolas: en modo texto, para gnome, con widgets wx, etc. Supongo que también existirán clientes gráficos que no tengan nada que ver con una consola y que harán lo mismo... yo por ahora no he buscado ninguno... :-P
Qué necesitamos
Bueno, bacula necesitará de una base de datos SQL para apuntar sus cosillas, así pues es necesario tener instalado y configurado MySQL.
No es obligatorio pero si muy recomendable que todas las máquinas que intervengan en el proceso sean accesibles por un nombre de dominio (o tengan IP estática).
Si tenemos nuestra base de datos lista ya podemos instalar en la máquina que realizará los backups los siguientes paquetes:
#apt-get install bacula-director-mysql
Bueno, hay que decir que exiten más versiones del director: pqsql (para postgress SQL, sqlite y sqlite3 (imaginad...). En la instalación del director os pedirán los datos necesarios para configurar la base de datos que necesitará bacula. Es muy sencillo y si os equivocáis simplemente haced:
#dpkg-reconfigure bacula-director-mysql
Y arregláis el fallo... zoquetes! :-P
Ahora, en la máquina que tenga nuestra unidad de almacenamiento (una cinta, por ejemplo) y que puede ser la misma o no que la anterior, instalamos lo siguiente:
#apt-get install bacula-sd bacula-sd-tools
Al igual que el director, este componente también tiene más alternativas: mysql, pgsql, sqlite y sqlite3. Usaremos el simple porque nuestro director ya se encargará de crear catálogos y todo eso, no es necesario que nos los cree también el storage daemon.
Finalmente, instalaremos lo siguiente en la máquina que queramos respaldar:
#apt-get install bacula-fd
Ahora sólo nos faltará configurar todo esto para que se comuniquen entre sí... vamos a ello!
Atención: Debian unstable instala la versión 1.38.11-7 (a fecha de 6 de feb, 2007) y el paquete no consigue configurar correctamente su base de datos. Pasa lo mismo con los paquetes 2.0.1 de la página de bácula. Consulta los apéndices de la receta para más información.
Configurando bacula-fd
Por ser más simple será el primero que configuremos, echemos un vistazo a su archivo de configuración (/etc/bacula/bacula-fd.conf):
Director {
Name = director_admitido1
Password = "password_chorrotronica_para_el_director_admitido1"
}
Director {
Name = backup-mon
Password = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Monitor = yes
}
FileDaemon {
Name = nombre_del_file-daemon
FDport = 9102
WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run/bacula
Maximum Concurrent Jobs = 20
FDAddress = maquina.dominio # O si tiene IP estatica pues X.X.X.X
}
# Esto es nuevo en bacula 2.0.0
Messages {
Name = Standard
director = director_admitido1 = all, !skipped, !restored
}
Vemos que los archivos de configuración tienen una estructura que se repite:
nombre_resource {
opcion = valor
...
}
Es lo que en bacula llaman resources. Un resource define un elemento de bacula, hay muchos tipos de resources diferentes, cada uno con sus propias opciones. El manual describe detalladamente todos ellos... ;-)
En este archivo hemos definido tres tipos de resources distintos:
Director: Identifica qué director puede conectarse con este file daemon; como veis se definen dos: director_admitido1 y backup-mon. El segundo es un director especial que actúa de monitor... se configura automáticamente. El primero es el que hemos añadido/modificado nosotros. El nombre que especificamos es el nombre que hemos dado a nuestro director (lo veremos más adelante) y la password es la que se espera que dé cuando se autentifique.
FileDaemon: Define los parámetros del propio file daemon, parámetros como el puerto de escucha o la IP a la que debe asociarse (recordad que si esa IP es 127.0.0.1 el demonio sólo aceptará conexiones de la propia máquina local). Como véis también especifica el nombre que se da a nuestro file daemon, es importante que coincida con el nombre que luego introduciremos en el director.
Messages: Indica qué mensajes podemos enviar a cada director.
Una vez modificado el archivo reiniciaremos el demonio y lo tendremos listo para funcionar con bacula, ahora vayamos con el siguiente.
Configuración de bacula-sd
Abramos su archivo de configuración (/etc/bacula/bacula-sd.conf) y veamos sus resources (este es una modificación del "original", para utilizar como almacenamiento un carrusel automático de cintas con seis slots):
Storage {
Name = nombre_del_storage-daemon
SDPort = 9103
WorkingDirectory = "/var/lib/bacula"
Pid Directory = "/var/run/bacula"
Maximum Concurrent Jobs = 20
SDAddress = maquina.dominio
}
Director {
Name = director_admitido1
Password = "password_chorrotronica_para_el_director_admitido1"
}
Director {
Name = backup-mon
Password = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Monitor = yes
}
Device {
Name = FileStorage
Media Type = File
Archive Device = /tmp
LabelMedia = yes; # lets Bacula label unlabeled media
Random Access = Yes;
AutomaticMount = yes; # when device opened, read it
RemovableMedia = no;
AlwaysOpen = no;
}
Autochanger {
Name = Autochanger
Device = Tape1, Tape2, Tape3, Tape4, Tape5, Tape6
Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"
Changer Device = /dev/sg2
}
Device {
Name = Tape1
Drive Index = 0
Autochanger = yes
Media Type = DDS-4
Archive Device = /dev/nst0
AutomaticMount = yes
RemovableMedia = yes
RandomAccess = no
AutoChanger = yes
LabelMedia = yes
}
...
Device {
Name = Tape6
Drive Index = 0
Autochanger = yes
Media Type = DDS-4
Archive Device = /dev/nst0
AutomaticMount = yes
RemovableMedia = yes
RandomAccess = no
AutoChanger = yes
LabelMedia = yes
}
Messages {
Name = Standard
director = director_admitido1 = all
}
Storage: Como antes, se define así mismo y qué parámetros usar.
Director: Igual que en el file daemon.
Device: Especifica un dispositivo de almacenamiento manejado por el storage daemon. El nombre que se le da aquí y el tipo de medio es el que luego necesitaremos usar en el director. Es importante aclarar que si tenemos un dispositivo de cintas con una sola unidad no será necesario definir tantos "devices" como cintas tengas, ya que todas serán cargadas por el autochanger
Autochanger: Es un Device especial que define un cargador automático de cintas. Se debe indicar el comando a emplear para usar el cargador.
Existen muchísimos parámetros para los resources de tipo device pero no es objetivo de la receta crear un manual de bácula en castellano... así que... al manual... :-P
Configurando bacula-director
Este es el archivo más complicado... pero que sólo veremos "a medias", la "otra mitad" se queda para una próxima receta.
Veamos la parte que nos interesa ahora, tenemos esto en el fichero /etc/bacula/bacula-dir.conf:
Director {
Name = director_admitido1
DIRport = 9101
QueryFile = "/etc/bacula/scripts/query.sql"
WorkingDirectory = "/var/lib/bacula"
PidDirectory = "/var/run/bacula"
Maximum Concurrent Jobs = 1
Password = "password_chorrotronica_para_las_consolas" # Console password
Messages = Daemon
DirAddress = 127.0.0.1 # Esto sólo vale para las consolas
}
[... cosas interesantísimas que ahora no vienen a cuento ...]
Client {
Name = nombre_del_file-daemon
Address = maquina.dominio
FDPort = 9102
Catalog = MyCatalog
Password = "password_chorrotronica_para_el_director_admitido1" # pwd for FD
File Retention = 30 days # 30 days
Job Retention = 6 months # six months
AutoPrune = yes # Prune expired Jobs/Files
}
Storage {
Name = File
Address = maquina.dominio
SDPort = 9103
Password = "password_chorrotronica_para_el_director_admitido1"
Device = FileStorage
Media Type = File
}
Storage {
Name = nombre_del_almacenamiento
Address = maquina.dominio
SDPort = 9103
Password = "password_chorrotronica_para_el_director_admitido1"
Device = Autochanger
Media Type = DDS-4
Autochanger = yes
}
Catalog {
Name = MyCatalog
dbname = bacula; DB Address = "" ; user = bacula; password = "XXXXX"
}
[...cosas tremendamente interesantes que ahora tampoco explicaremos...]
Como este tiene más chica, explicaremos resource a resource más despacito.
Director
Igual que en los casos anteriores, se define a sí mismo, los campos habituales son:
Name: Nombre que damos al director. Es el mismo nombre que hemos permitido en los otros demonios.
DIRport: Puerto de escucha para las consolas.
QueryFile: Archivo con las consultas a la bbdd.
WorkingDirectory: Directorio de trabajo (no cambiar).
PidDirectory: Directorio donde crear los archivos con pid.
Maximum Concurrent Jobs: Número máximo de trabajos concurrentes que acepta. En los casos anteriores teníamos un valor mayor a 1, esto permitirá que varios directores utilicen esos demonios a la vez. Establecer aquí este valor a 1 implica que el director sólo hará un trabajo cada vez, que es el valor por defecto.
Password: Contraseña que se pedirá al programa de consola. Esta contraseña no se pide por teclado sino que también se almacena en el archivo de configuración del programa de consola.
Messages: Donde se enviarán los mensajes no asociados a un trabajo concreto.
DirAddress: Dirección donde escuchará el director. Indicar 127.0.0.1 implicará que no podrán abrirse consolas bacula en máquinas remotas, pero no causa problemas si tenemos los demás demonios en otras máquinas puesto que es el director el que abre las conexiones con los otros demonios.
Client
Aquí especificaremos los datos del bacula file daemon con el que necesitamos conectar para leer los ficheros necesarios. Para ello especificaremos lo siguiente:
Name: Nombre del file daemon. Este nombre no tiene porqué coincidir con el que dimos a nuestro file daemon, es para nombralo dentro de bacula. Mi recomendación es que coincida, más que nada para entendernos mejor.
Address: IP o hostname de la máquina que tiene nuestro file daemon.
FDPort: Puerto donde escucha el file daemon.
Catalog: Qué catálogo usa nuestro file daemon. Un catálogo es algo así como un listado de los ficheros que se están respaldando.
Password: Contraseña que enviará el director al file daemon para autentificarse.
File Retention: Este parámetro indica cuanto tiempo deben permanecer los archivos en el catálogo. Pasado este tiempo se eliminan del catálogo (pero esto no influye en que se haga o no backups de estos ficheros).
Job Retention: Indica cuanto tiempo como máximo estará un trabajo esperando.
AutoPrune: Si está a yes, una vez pasados los periodos File Retention y/o Job Retention se eliminan del catálogo y/o cola los ficheros/trabajos.
Storage
Ahora especificaremos los dispositivos que podrá emplear bacula para hacer las copias de respaldo, pueden existir varios (que se diferenciarán por el nombre). Debemos indicar los siguientes campos:
Name: Nombre del medio de backup. No es el nombre del storage daemon sino del medio, por ejemplo: Carrusel_cintas o Fichero_local, etc.
Address: Máquina donde está el storage daemon que maneja el medio de almacenamiento.
SDPort: Puerto de escucha.
Password: Contraseña que enviará el director para autentificarse contra el storage daemon.
Device: Nombre del medio configurado en el storage daemon que debemos usar. Como dijimos, el storage daemon configura uno o varios dispositivos de almacenamiento, nombrándolos de alguna manera. Pues ese nombre es el que usamos aquí.
Media Type: Cuando se configura el medio se especifica que tipo de medio es, aquí también tenemos que indicarlo (y debe coincidir). Bacula lo usa para "hacer sus cuentas".
Autochanger: Parámetro opcional, indica si es o no un autocargador.
Catalog
Name: Nombre del catálogo (que usamos en el resource del file daemon).
dbname: Nombre de la base de datos.
DB Address: Máquina donde tenemos nuestro servidor MySQL.
user: Usuario con privilegios en la base de datos especificada anteriormente suficientes como para crear y modificar datos.
password: Password de dicho usuario en esa base de datos.
Bien, con todo esto ya tenemos un sistema bacula distribuido funcionando a las mil maravillas... para comprobarlo podemos hacer lo siguiente:
#apt-get install bacula-console
Y lo configuramos para conectarse a nuestro director modificando /etc/bacula/bconsole.conf:
Director {
Name = nombre_director-dir
DIRport = 9101
address = maquina_director.dominio
Password = "passwordchorrotronicaparalasconsolas"
}
Si todo ha ido bien podremos ejecutar bconsole como root o como un usuario que pertenezca al grupo bacula y teclear lo siguiente:
*status
El asterisco es el prompt de la consola de bacula, ejecutamos status y le decimos que all cuando nos pregunte de qué queremos el estado. Si algún componente no puede contactarse, se notificará con el error correspondiente. Si no obtenemos ninguno de esos errores tenemos el bácula funcionando. Ahora sólo nos queda indicarle qué archivos hay que respaldar y cuando.
Existe un problema que no puede detectarse así y que es muy peligroso: puede suceder que el director pueda comunicarse con el storage daemon y con el file daemon, por tanto dirá que todo esta funcionando; sin embargo, el storage daemon y el file daemon no puedan conectarse entre sí; esto provocará que los backups darán siempre error y no se realizarán. Esto sucede porque cuando el director va a hacer una copia, conecta al file daemon con el storage daemon directamente y ellos dos realizan las transferencias de datos. Debéis tener esto en cuenta cuando pongáis vuestro bacula a funcionar.
Apéndice A: Preparar la base de datos bacula en MySQL
Bueno, como dijimos antes, la instalación de bacula por paquetes no crea la base de datos que utiliza para realizar los backups, así que nosotros haremos ese trabajo "a mano". Vamos a asumir que tenemos correctamente instalado y funcionando MySQL Server y phpmyadmin (tal y como se quedan después de una instalación con apt-get).
La base de datos que debemos crear es la que se especificó en el resourceCatalog que vimos anteriormente, por ejemplo una base de datos llamada bacula (que es la usada por defecto). La creamos con phpmyadmin, también podemos crear el usuario (que por defecto también debe ser uno llamado bacula) con la contraseña que hayamos especificado. Lo único que debemos hacer ahora es crear unas tablillas y listo, la siguiente porción de código SQL (que se puede pegar directamente en phpmyadmin y listo) lo debería resolver (por cierto que está sacado de un script que viene en los paquetes de bacula pero que a mi no me funcionaba):
Ejecutáis eso (como administradores de MySQL si queréis), dáis permisos al usuario bácula en todas esas tablas creadas y ya tenéis la base de datos lista para su uso por parte del director. :-)
Apéndice B: Archivos de configuración de ejemplo
Por último, pondré unos archivos que uso yo y están funcionando, para que veáis unos ya configurados y tal. Las contraseñas debéis cambiarlas (es un consejo). El escenario es el siguiente: tenemos un equipo con cargador de cintas (de tres slots) que hace backup de un segundo equipo. Para no instalar muchas cosas en el segundo equipo (no interferir en su funcionanmiento) lo único que instalaremos en ese equipo es el file daemon. El equipo con el cargador va a tener por tanto el director y el storage daemon. La máquina con el director se llamará respaldadora (192.168.0.2) y de la que queremos hacer backup se llamará importante (192.168.0.1).
Primero instalamos bacula-fd en importante y lo configuramos con este fichero (/etc/bacula/bacula-fd.conf):
Director {
Name = backup-mon
Password = "password_para_backup-mon"
Monitor = yes
}
FileDaemon {
Name = importante-fd # Podria ser cualquier otro nombre
FDport = 9102
WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run/bacula
Maximum Concurrent Jobs = 20
FDAddress = 192.168.0.1
}
Messages {
Name = Standard
director = respaldadora-dir = all, !skipped, !restored
}
Reinciamos el demonio y ya podemos olvidarnos de esta máquina ;-).
Ahora vamos con respaldadora, primero instalamos el storage daemon y lo configuramos con el siguiente arhivo (/etc/bacula/bacula-sd.conf):
Storage {
Name = respaldadora-sd
SDPort = 9103
WorkingDirectory = "/var/lib/bacula"
Pid Directory = "/var/run/bacula"
Maximum Concurrent Jobs = 20
SDAddress = 192.168.0.2
}
Director {
Name = respaldadora-dir
Password = "password_para_respaldadora-dir"
}
Director {
Name = respaldadora-mon
Password = "password_para_respaldadora-mon"
Monitor = yes
}
Device {
Name = FileStorage
Media Type = File
Archive Device = /tmp
LabelMedia = yes;
Random Access = Yes;
AutomaticMount = yes;
RemovableMedia = no;
AlwaysOpen = no;
}
Autochanger {
Name = Autochanger
Device = Tape1, Tape2, Tape3
Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"
Changer Device = /dev/sg2
}
Device {
Name = Tape1
Drive Index = 0
Autochanger = yes
Media Type = DDS-4
Archive Device = /dev/nst0
AutomaticMount = yes
RemovableMedia = yes
RandomAccess = no
AutoChanger = yes
LabelMedia = yes
}
Device {
Name = Tape2
Drive Index = 0
Autochanger = yes
Media Type = DDS-4
Archive Device = /dev/nst0
AutomaticMount = yes
RemovableMedia = yes
RandomAccess = no
AutoChanger = yes
LabelMedia = yes
}
Device {
Name = Tape3
Drive Index = 0
Autochanger = yes
Media Type = DDS-4
Archive Device = /dev/nst0
AutomaticMount = yes
RemovableMedia = yes
RandomAccess = no
AutoChanger = yes
LabelMedia = yes
}
Messages {
Name = Standard
director = respaldadora-dir = all
}
Y finalmente instalamos el bacula director y lo configuramos, muy importante: este archivo no está completo, falta la definicion de trabajos que se explicará en una próxima receta. El archivo es el siguiente (/etc/bacula/bacula-dir.conf):
Director {
Name = respaldadora-dir
DIRport = 9101
QueryFile = "/etc/bacula/scripts/query.sql"
WorkingDirectory = "/var/lib/bacula"
PidDirectory = "/var/run/bacula"
Maximum Concurrent Jobs = 1
Password = "password_para_respaldadora-dir"
Messages = Daemon
DirAddress = 127.0.0.1 # Esto obliga a que las consolas bacula solo se puedan ejecutar desde localhost
}
Client {
Name = importante-fd
Address = 192.168.0.1
FDPort = 9102
Catalog = MyCatalog
Password = "password_para_respaldadora-dir"
File Retention = 30 days
Job Retention = 6 months
AutoPrune = yes
}
Storage {
Name = File
Address = 192.168.0.2
SDPort = 9103
Password = "password_para_respaldadora-dir"
Device = FileStorage
Media Type = File
}
Storage {
Name = respaldadora-sd
Address = 192.168.0.2
SDPort = 9103
Password = "password_para_respaldadora-dir"
Device = Autochanger
Media Type = DDS-4
Autochanger = yes
}
Catalog {
Name = MyCatalog
dbname = bacula; DB Address = "" ; user = bacula; password = "password_de_bbdd"
}
Messages {
Name = Standard
mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) %r\" -s \"Bacula: %t %e of %c %l\" %r"
operatorcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) %r\" -s \"Bacula: Intervention needed for %j\" %r"
mail = root@localhost = all, !skipped
operator = root@localhost = mount
console = all, !skipped, !saved
append = "/var/lib/bacula/log" = all, !skipped
}
Messages {
Name = Daemon
mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) %r\" -s \"Bacula daemon message\" %r"
mail = root@localhost = all, !skipped
console = all, !skipped, !saved
append = "/var/lib/bacula/log" = all, !skipped
}
Pool {
Name = Default
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 365 days
}
Console {
Name = respaldadora-mon
Password = "password_para_respaldadora-mon"
CommandACL = status, .status
}
Enlaces
El maravilloso manual de bacula: http://www.bacula.org/en/?page=documentation.
Venga... en breve tendréis la segunda y última receta de bacula, con ella ya podréis montar vuestros propios servicios de backup distribuidos con bacula.
Sí te aburre el tradicional color en blanco y negro que aparece en tu cargador de arranque de GRUB, En esta receta verás como colocar una imagen de fondo.
Utilizar Gimp
Una imagen de arranque de GRUB puede tener una resolución máxima de 640X480 píxeles y un máximo de 14 colores.Para conseguir tal resolución ejecute el programa Gimp y realiza los siguientes pasos con el puntero del ratón:
Archvivo->Abrir->Selecciona la imagen que quieras colocar de fondo en el gestor de arranque GRUB
imagen->escalar imagen->y aquí pon la resolución 640X480
imagen->modo->indexado(y aquí pon el número máximo de colores a 14)
guarda la imagen en modo RGB
ya puedes cerrar el Gimp
ahora accede a donde hayas guardado la imagen y ponle el nombre nombre_que_tú_quieras.xpm (es fundamental que no se te olvide la terminación .xpm)
Comprimir la imagen
Aunque no es estrictamente necesario comprimir la imagen, reducirá el tiempo necesario para cargarla. Por lo que harás lo siguiente desde línea de comandos(accede al directorio en donde guardaste la imagen):
$gzip nombre_que_hayas_elegido.xpm
esta instrucción creará un archivo de la forma nombre_que_hayas_elegido.xpm.gz
Copiar en el directorio /boot/grub
Ahora copia el fichero nombre_que_hayas_elegido.xpm.gz en el directorio /boot/grub, para ello teclea en línea de comandos:
si fuera necesario, se sustituye (hd0,1) con la notación Grub para el disco duro y la partición en la que está almacenada tu distribución GNU/Linux.Esto lo podrás comprobar en el mismo archivo menu.lst, por ejemplo, en mi archivo menu.lst sale entre otras cosas:
Si posees un iBook o PowerBook comprado a mediados de 2005, tu ordenador tiene SMS (Suddent Motion Sensor) para proteger tu disco duro de caídas estrepitosas. Con esta receta lo harás funcionar en tu GNU/Linux y, si quieres, comenzar el desarrollo de aplicaciones para él. Este procedimiento está probado en un iBook G4 con Ubuntu Edgy.
