V15 Warm Spare truncated key gql 500 Internal Server Error


#1

I can’t get warm spare backup working on one of my v15 PBXs. It’s working fine on another so I’ve been through it before. Errors during backup (below) indicate a problem with ssh. I confirmed the primary PBX’s IP is whitelisted on both PBX’s firewalls per the notes in the Sangoma spec (https://wiki.freepbx.org/pages/viewpage.action?pageId=185631299). I also confirmed I can log in to the warm spare with ssh -i /home/asterisk/.ssh/id_rsa root@SecondaryServerIP. I also confirmed the permissions for the key are correct (chmod 600 /home/asterisk/.ssh/id_rsa). I’m out of ideas.

Here’s the error:

Could not login with username: root

In RequestException.php line 113:

Server error: POST https://mypbx'sdomain/admin/api/api/g ql resulted in a 500 Internal Server Error response:
{“error”:{“type”:“Whoops\Exception\ErrorException”,“message”:"Key file "
file:///etc/asterisk/keys/api_oauth_pub (truncated…)


#2

Bump…

I recently upgraded another primary and warm spare to v15. Warm spare backups fail on this pair as well. The backup is successfully saved on the warm spare, but the API to restore the backup fails with a 401 Unauthorized response. The Primary and Warm Spare IPs are added as trusted networks on both machines.

Client error: POST https://xxxxxxx.com/admin/api/api/gql resulte
d in a 401 Unauthorized response:
{“error”:“access_denied”,“message”:“The resource owner or authorization ser
ver denied the request.”,“hint”:"Access token (truncated…)

I can get a Warm Spare Token on the primary pbx from the warm spare, so I don’t understand why the API would fail. I tried creating a a new machine to machine application on the warm spare and entered the new credentials on the primary, but I get the same failure.


#3

Well I got past the “Could not login with username: root” error by using the warm spare’s IP address instead of the FQDN in the ssh filestore on the primary pbx. My warm spare FQDN is on the longer side and has a sub-domain, but DNS on the machine returns the correct IP, so I think there is a bug. I opened a bug: https://issues.freepbx.org/browse/FREEPBX-21848

I’m still getting a 500 internal server error though when the backup attempts to import the backup. I am at a total loss as to why - there doesn’t appear to be any logging. I made sure the warm spare and parimary IPs are whitelisted on the primary per the documentation (https://wiki.freepbx.org/pages/viewpage.action?pageId=185631299), and I can get a warm spare token from the warm spare on the primary. Something is wrong and there is no insight that I can find as to what it is.


#4

Also of note: both the primary and warm spare were upgraded from v14. They are not clean installs.