But I simply get nothing, there is no notification so I can’t tell if it fails or succeeds ( but since I tell it to restore locally and my extensions aren’t there it’s a fail ).
I beleive when I ssh to the primary box from the secondary box is the problem.
if i ssh [email protected] it doesn’t automatically log me in. ( which defeats the keys purpose )
if I try asterisk@@primary.box.com thats a fail as well.
If anyone has some better documetation ( it looks pretty good to me ) or can point out where I’m going wrong I would appreciate it!!
*** In a note I think we should add to the documenation to whitelist the backup server IP on the primary server for fail2ban in order to insure it never gets rejected.
then I try to from the remote box
ssh [email protected] it asks for the password, but it does log me in.
Then tried from the remote box
ssh [email protected] won;t accept the password
Since the password is not kept in the settings for the remote backup, I know you have to be able to ssh with the key and thats where I’m at a standstill I beleive. ( I set this key method on my other linux servers not related to asterisk, so I am very familiar with this )
On the remote server the backup job I setup says:
Hostname = primary.box.com
remote ssh user = root
remote ssh key = /var/lib/asterisk/.ssh/id_rsa.pub
restore to this server is checked.
I never see anything happening, no files are generated on the REMOTE BACKUP box, I do see the files generated on the primary box.
It really looks to easy to setup, but something’s not working.
OK did that workaround, but still no config and your test command still is prompting for a password which I think is the problem.
Since there is no logging or notification, that I can tell, I cant see if it failed or passed. Since it’s local it shouldnt take more than 5 minutes for this to finish, but no matter what the config never comes over. I did this in the backup with the NOW option and not the every so many hours option.
ssh -v [email protected]
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to primary.box.com [primary.box.com] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
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 ‘primary.box.com’ 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,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
To make sure I’m correct, on the Remote/Backup Server you execute:
sudo -u asterisk ssh-keygen
sudo -u asterisk ssh-copy-id -i /var/lib/asterisk/.ssh/id_rsa.pub [email protected]
You go to the primary server and you check that in /root/.ssh in authorized_keys that it contains the key for the Remote/Backup server.
From the backup/secondary you execute:
sudo -u asterisk ssh -i /var/lib/asterisk/.ssh/id_rsa.pub [email protected]
and thats where I’m at…
I do this for my regular linux boxes so I’m very familiar with the whole process.
I appreciate you working with me on this… I really need to get it running because I have a client who has not so great internet access and that backup box needs to respond to the calls.
Yes that worked, I totally missed that as well. The backup works, I was trying to figure out if there was a simple method to get notification of the success or failure of the backup.
OK, I have the backup process working on a daily basis, I see it’s restoring itself as expected, but there are some things that are making the remote server fail during the auto switchover.
Scenario:
Primary box is behind a firewall and has nat enabled and lets say IP address 1.2.3.4. Backup server is IP address 2.3.4.5, it doesn’t need nat ( probably not an issue )
Primary server cant be communicated to from the sip trunk so it routes the call to the secondary/backup server where it should pick up.
Issues: after the restore fremo the backup job onto the secondary server the confiruation from the primary server overides the true outside IP number, nat and virtualization options.
The other thing is the IVR cant work because the g729 licenses wont work off the new mac addresses.
Even if I had seperate licenses they would be over written by the primary severs license.
Is there a way around this? I want to have it running as a failover, but don’t see any check boxes that say override this setting on restore or something of that nature.