I'm trying to follow that article, but my server won't let me get past the test to see if rsync is working. I think the problem is that my server1 has SSH already set to use public/private keys to connect using putty. Is there a way for me to get around this? I tried to input this on server2(mirror): Code: rsync -avz --delete --exclude=**/stats --exclude=**/error --exclude=**/files/pictures -e "ssh -v -i /root/rsync/mirror-rsync-key" [email protected]:/var/www/ /var/www/ and got this: Code: root@server2:~# rsync -avz --delete --exclude=**/stats --exclude=**/error --exclude=**/files/pictures -e "ssh -v -i /root/rsync/mirror-rsync-key" [email protected]:/var/www/ /var/www/ OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.31.200 [192.168.31.200] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/rsync/mirror-rsync-key type 2 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu1.2 debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '192.168.31.200' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: /root/rsync/mirror-rsync-key debug1: Authentications that can continue: publickey debug1: No more authentication methods to try. Permission denied (publickey). rsync: connection unexpectedly closed (0 bytes received so far) [receiver] rsync error: unexplained error (code 255) at io.c(454) [receiver=2.6.9] Sorry for the long code, but I hoped that would help.
I might have fixed this myself by manually copying the public key over to the primary server. It seemed to work once I got to the end of the article, and ran: rsync -avz --delete --exclude=**/stats --exclude=**/error --exclude=**/files/pictures -e "ssh -i /root/rsync/mirror-rsync-key" [email protected]:/var/www/ /var/www/ It copied over the files, but it said some couldn't be copied. I still can't figure which files it didn't copy.
Yes, I ran myself as root, except where I was the someuser. I checked the logs last night, and it seems to be running ok. I set it at 30 minutes, and I was hoping I could see somefiles missing, but so far I still can't. I wish some log would track what was copied and what wasn't.
I also have another related question. If you set up to do Mysql sync as well, which I will need to, how do you get around copying the ISPConfig database? The backup server has a different IP address set from the primary server, so if I copy the db, it will mess up the setup on the backup server. I'm also running a nameserver on both, with server1 set as ns1(master) and server2 set as ns2(slave). The DNS files are transferring just fine.
You could try to replace someuser with root. The best solution would be to transfer the IP to the backup server if the main server fails.
Thanks Falko I plan to do just that using my monowall router/firewall. My worry is that server1 has ISPConfig set up with the local and public IP addresses. Server2 is also set up with ISPConfig with a different local and public IP addresses. I'm running name servers on both servers as ns1 and ns2(server2), with ns2 acting as a slave server. What I'm confused about is when I do MySql copies of the ISPConfig db from server1 to server2, won't it also copy server1's IP address and replace server2's addresses with them?
If you replicate the database from server1 to server2, the ISPConfig database on server2 will contain the IP addresses from server1. That's why the best solution would be to transfer the IP to the backup server if the main server fails.
I can see that working, I think. The DNS files only care about the public IP address, so that shouldn't mess up it acting as a slave server normally. The db would have server1's local IP address in it, and if I'm picturing how that will work, that shouldn't matter as long as I don't use ISPConfig to set up sites on server2, which I wouldn't anyway. I believe ISPConfig only re-writes the DNS files if I use it to set up a site. What I want to do is use my monowall router to switch the local IP addresses if I ever have to switch to the backup.
Hi Falko I don't know if you'll see this now, but a possible flaw in this plan comes to mind. The servers use local IP addresses to connect to the router/firewall. Server1(master name server and primary web server) uses 192.168.31.200, and server2(slave name server and backup web server) is set to 192.168.31.210. They are connected to the router/firewall(monowall) using a 5 port network switch. I set the monowall system to have the two servers on aliases for the two IP's. That way, if the main server goes down, all I need to do is switch the two aliased addresses around in the monowall interface, and all the traffic will be routed to the backup server2. Like I said before, I see that as long as I don't edit any DNS setups using ISPConfig on my server2, then then server1's IP address being stored there wouldn't make any difference. then I remembered the /etc/network/interfaces file. It has the 192.168.31.210 address set for that server, and I can't change that as easy. If I see this correctly I'm going to need to edit that file as well, or the server will never allow the connection if I make the switch. Sorry if this sound confusing, it makes sense in my head.
