Me han pedido que configure un "Agente Bacula" (bacula-df) en un windows 2008 (que dice que es un 2011) para que se conecte a un servidor bacula que está en "internet".
El diagrama es algo parecido a esto.
A vote pronto pense que con abrir los puertos, seria suficiente, pero me he encontrado con algunas cosas, que se que son de "cajón" pero que hasta que no te pones a ello, no ves la problematica.
Lo primero instalar el cliente adecuado para tu SO, en mi caso al ser un Windows server 2008, a 64Bits, pues me baje, el ultimo disponible de aqui.
En principio va todo menos "Bat", que no arranca ni para atras, no se si es por la "lejania" o porque siempre da problemas, y en esta ocasión los da todos. No es critico para el respaldo/recuperación, con "bconsole", puedo hacer lo que quiera, pero se le hecha de menos.
Hay otras pruebas que quiero hacer, porque el Bacula-Director es un 5.2.6 y he leido que lo optimo, es que tengan la misma versión, y mas en sistemas Windows. De momento hago mis pruebas y siempre podre meter la versión "pareja" del Director.
Como siempre, es configurar para que se conecte, como se ve en el diagrama, he puesto Ips publicas de "pega".
Abrimos puertos, lo primero el del Agente Bacula, (Bacula-FD lado cliente) en el equipo que corre con Windows 2008, abrimos el puerto en TCP 9102 que es el de por defecto, es el puerto al cual se conectara el Director, para darle instrucciones.
Despues tenemos que abrir en el lado del Director el 9101, (lado Servidor) tambien en TCP, para que Bconsole y Bat ( del lado del Cliente), puedan hablar con el Director, esto no es estricatamente necesario, puesto que tanto Bconsole como Bat, se pueden ejecutar en otro sitio, pero si muy recomendable.
Y finalmente el 9103, en el lado del Storage-Daemon (bacula-sd, lado servidor) que en mi caso al correr en el mismo equipo y con misma IP que el Director, pues es en el mismo lado fisico.
Tenemos que recordar que la conexión es desde el Director hacia el Cliente (Agente Bacula) para ejecutar los trabajos, y luego desde el Cliente (bacula-fd) al Storage Daemon, indicado por el Director para enviar los datos.
Bien, con estas premisas claras, decidi, crear en el Director un nuevo Storage realmente no es uno nuevo, mas bien, redefini otro con el mismo Device, y es en este nuevo Storage, donde me encontre el problema.
Copio y pego el Storage en cuestión ya con el problema solucionado.
#################### Publico Storage en Ofsite servidor Win2008 #####################
# Definition of file storage device
Storage {
Name = OfsitePublic
# Do not use "localhost" here
Address = bacula.localred.net # N.B. Use a fully qualified name here (resultado optimo)
SDPort = 9103
#Password = "ucGrwsztIii1gEBT_dAtOxRo-K0rt-Pr4"
Password = "bacula-director-local"
Device = StorageOfsite
Media Type = File
}
El problema biene ante la notificación por parte del Director de cual es la dirección del Storage, si se pone una IP interna, privada, (192.168.3.214) no tendremos problemas para funcionar con clientes en ese mismo segmento de red, incluso haciendo routing, pero si se hace NAT, que es nuestro caso, esa IP que Indica el Director al Cliente, a la cual se tiene que conectar, para negociar y enviar datos, no está disponible en el lado del cliente (obio es una IP privada). Si por el contrario ponemos la IP Publica del lado del servidor, que en este caso seria 20.20.20.21, el problema es que el Director no ve a este "Storage" e indica que no puede conectar. (normal, es la IP publica)
Una posible solución valida, seria crear un Tunel VPN entre los dos lados, y hacer routing, pero en nuestro caso, no esta disponible hacer esto.
La solución mas correcta, indicada ya por la nota en la definición # N.B. Use a fully qualified name here es hacer lo que nos indican, pero esto tiene sus problemas asociados.
1º- Tenemos que hacer que la maquina responda a un nombre de host, que de forma interna sea la IP del lado privado, en mi caso bacula.localred.net = 192.168.3.214. Esto es muy facil, solo tenemos que retocar el fichero /etc/hosts dejando algo parecido a esto:
127.0.0.1 localhost
#127.0.1.1 bacula.localred.net bacula
127.0.1.1 bacula
192.168.3.214 bacula.localred.net bacula
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
2º- Luego mediante DNS en mi caso el que me proporciona el ISP, añadir un registro A que indique que bacula.localred.net es la IP publica del lado servidor. (se ha de disponer un dominio en Internet y acceso al los registros DNS)
2º-a) Si no se disponen de DNS por no tener dominio propio, siempre se puede "inventar" uno, y añadirlo en el fichero hosts de la maquina (cliente) en windows normalmente está en C:/windows/system32/drivers/etc (sistema WindowsXP) y incorporando una linea que diga algo como esto: 20.20.20.21 bacula.localred.net # ha de ser igual a la definición del Storage De este modo ya no preguntara a ningún DNS, le saldra del "alma".
3º- Hay que esperar que los DNS actualicen. (de 4 a 12H)
En principio ya tendriamos el problema solucionado, cuando Bacula Director notifique al Cliente (bacula-fd) donde tiene que hacer la copia, indicara bacula.localred.net pero cuando resuelvan, el cliente por DNS y el otro por host, apuntaran a IPs distintas pero al mismo tiempo validas.
Estoy realizando algo similar.
tengo serve-bacula funcionando en una red de forma local.
y tengo una conexion por vpn hacia otro lugar, en client-status lo identifica sin problema, y me indica la version ...etc...etc, si lo reconoce.
pero el problema se presenta cuando se inicia el JOB.
NO indica error. y se queda solamente ahi .
En la configuracion de la vpn, siempre esta activa,
envio ping entre ambos y se responden.
Pero no se donde este mal.
Puedes ayudarme . ?