- July 17, 2018 at 3:07 pm
- July 17, 2018 at 3:36 pm
- July 17, 2018 at 3:39 pm
I found the issue. It is the DB or the UI one. All of my inbound routes have had their destinations cleared in the UI. I am going back through now and setting them back to the correct locations. As soon as I fix one then the calls start working again.
No idea what would have caused all of the destinations to get cleared though and with all of my direct dials it is taking forever to put them back in.0
- July 17, 2018 at 3:51 pm
- July 17, 2018 at 3:53 pm
- July 17, 2018 at 3:56 pm
I don’t. I literally just set that up yesterday, so the first one happened last night.
Here is the grep from the yum log
[root@vitalpbx ~]# grep vitalpbx /var/log/yum.log
Apr 11 13:25:50 Installed: vitalpbx-custom_contexts-1.0.0-1.x86_64
Apr 11 13:26:44 Installed: vitalpbx-phone-books-1.0.0-2.x86_64
Jun 26 09:10:47 Updated: vitalpbx-asterisk-configs-2.0.3-3.x86_64
Jun 26 09:10:50 Updated: vitalpbx-sounds-2.0.3-3.x86_64
Jun 26 09:10:55 Updated: vitalpbx-sounds-es-2.0.3-3.x86_64
Jun 26 09:11:00 Updated: vitalpbx-monitor-2.0.3-3.x86_64
Jun 26 09:11:00 Updated: vitalpbx-themes-2.0.3-3.x86_64
Jun 26 09:11:24 Updated: vitalpbx-2.0.3-3.x86_64
Jun 27 13:16:29 Installed: vitalpbx-bulk-extensions-1.0.0-1.x86_64
Jun 27 13:56:04 Installed: vitalpbx-task-manager-1.0.0-1.x86_64
Jun 27 13:56:33 Updated: vitalpbx-phone-books-1.0.0-5.x86_64
Jul 16 13:19:57 Updated: vitalpbx-sounds-es-2.0.4-1.x86_64
Jul 16 13:20:00 Updated: vitalpbx-asterisk-configs-2.0.4-1.x86_64
Jul 16 13:20:01 Updated: vitalpbx-sounds-2.0.4-1.x86_64
Jul 16 13:20:01 Updated: vitalpbx-themes-2.0.4-1.x86_64
Jul 16 13:20:04 Updated: vitalpbx-monitor-2.0.4-1.x86_64
Jul 16 13:20:12 Updated: vitalpbx-2.0.4-1.x86_64
Jul 16 13:20:13 Updated: vitalpbx-custom_contexts-1.0.1-1.x86_64
- July 17, 2018 at 4:03 pm
Just got this when I tried to update my IVRs with the destination after it had been blanked:
SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘5e9fd4dce07ec548f7ec66e66264d4aa.’ in ‘where clause’ With Query: select `5e9fd4dce07ec548f7ec66e66264d4aa`.`ivr_id` as `ivr_id`,`5e9fd4dce07ec548f7ec66e66264d4aa`.`option` as `option`,`5e9fd4dce07ec548f7ec66e66264d4aa`.`destination_id` as `destination_id`,`5e9fd4dce07ec548f7ec66e66264d4aa`.`enabled` as `enabled`,`5e9fd4dce07ec548f7ec66e66264d4aa`.`sort` as `sort` from `ombutel`.`ombu_ivr_entries` as `5e9fd4dce07ec548f7ec66e66264d4aa` where `5e9fd4dce07ec548f7ec66e66264d4aa`.“ = ? at file /usr/share/ombutel/www/includes/db.php on line 00
- July 17, 2018 at 4:41 pm
- July 17, 2018 at 5:43 pm
The problem looks to be due to using the mysql service with no password.
It seems that if you changed the mysql password to an exact password to allow communication between the SwitchBoard and other programs that use the the db. The script was not trying to use a password which means that in order for the patches to be applied the mysql root password needs to be set back to blank.
Tried looking at the script to see if it was possible to use the password, but the file is encrypted with ioncube.
If anyone is still having the same issue then it looks like resetting the mysql root password back to blank or none fixes this issue.0
- July 17, 2018 at 5:49 pm
- July 17, 2018 at 8:40 pm
- You must be logged in to reply to this topic.