Bacula Windows Client
Hmm, apparently the bacula windows client is no longer provided for free. Fortunately the latest versions of the opensource (and free) windows client of sourceforge are still compatible with the latest linux bacula-director.
Installing it was a real pain. Not because of the bacula software but because of the damn windows7 insistance on prompting for administrator approval for everything which locks out synergy (in english I cannot use my desktop, but have to go to the physical machine every time that is required). I even had to be phyisically on the machine to edit the config file.
A task that should take 20mins including testing took almost 2 hours. But thats why I don’t use windows, except on that one dual boot laptop that I decided I should backup user files from the windows partion… would have been easier to mount the windows filesystem from linux and backup using the linux client.
And backup failed after 3mins anyway. A status client from the director now times out, as does a telnet to the port, even tho the win7 machine is listening on the port. But the client responded before the backup started !!!.
Dumping it, uninstalled the windows client again, a wasted 2 hours. Will go back to plan-B and just mount the windows partition under linix and backup the user directories that way.
It will be something to do with the windows7 firewalling. Not bothering to debug that.
Unrelated network stuff
Of course after booting the laptop under Linux to do the backup I discovered interesting things about the firewall rules there since I implemented bridged networking on it (i put some test vm’s on it so needed bridging).
The bridged address was associated with the cabled ethernet port, which was not plugged in. But that ipaddr could still be accessed even though only the wireless card was connected to the network. Now I think about it that is correct as the ipstack for 103 will get the ethernet broadcast traffic and anything else on the ipstack would also see/accept it, most of my iptables rules on VM (bridged) hosts are interface A can pass traffic to interface B and all else denied; I never really thought about what would happen if there were no specific deny rules in place.
As a lot of my external internet connections are forwarded to the appropriate VM via NAT’ing across bridging this could explain why I have been getting a lot of alerts lately for traffic being blocked on VMs not expecting it. Must look into that.
Synergy observation
I have my laptop configured under synergy as xxx.xxx.xxx.101. Haven’t had it plugged in for a while, lease expired, dhcp gave it xxx.xxx.xxx.103.
Yes I have checked the synergy configs, grep’ed for 103, it doesn’t exist. Checked the startup command, yup it is still using files expecting 101.
But the client on 103 will happily talk to the master. From the master I can drag the mouse across to the client screen with no problems… in earlier releases of synergy if you got the ip-addrs wrong it would complain, maybe now the client registers it’s name to the master (master ip-addr had not changed) somehow and overrides the master config ???. Anyway it should not work, but it does. Not sure its a good thing.
