vicidial.org

Hi everyone,

I need help with an install of Vicidial. I was instructed that to set up a backup server (In case of disasters), I would just need to install the same version of vicidial and backup the sql dump of "asterisk database onto the new server. I'm currently building the Disaster recovery server and testing it and coming up with the below issues.

So here are the steps I made.
1. First I installed Vicibox 8 on a new server (Exact same version as production).
2. After installation, I try running the Web UI. All seems fine. Agent login is fine as well.

3. I import the sql dump from old server
4. After import, I get this error


PS. The database is on local, not even on a remote server.
Am I missing anything? Please help.

1) Backup and restore with ANY web site software (arguably any softare at all) requires that the restore have the same exact version of the code that the original system had. Admin screens have this information in the bottom left corner.

2) The Red "wrong version" stems from the single expected code line entry in /etc/astguiclient.conf (however: Changing this value in no way invalidates #1 above!)

3) After you restore onto the Emergency server: You have to either cause it to have the same IP address as the original server (which requires taking the original server offline, they can't both have the same IP address) or running the IP Update script mentioned in the login splash screen using the OLD DB server's IP as OLD and the NEW DB server's IP as NEW. After running this script, you will need to reboot unless there are no services or screens running on either DB server (old or new).

4) If the new server will have a new IP, I hope it's obvious to you that all the other servers in the cluster must be informed of the new IP, and rebooted to take effect systemwide on each server.

5) You may also want to have a look at creating a Replication/Report server which can technically double as your emergency DB server (and should not incur much loss at all in case of failure, mere seconds in fact if properly built).

6) You must always post your Vicidial Version With Build when requesting support on this forum. You missed the Build and your version isn't searchable (so nobody with your exact system will land on your posts and possibly be helped by any bugs you uncover that are Version Related). It's a requirement to post this every time. It helps others, seriously. You should also include your installation method (which is more than just Vicibox 8, it would be 8.X.X with real numbers instead of Xs).

Hi Williamconley,

Sorry about the version. The Vicidial version and build is:

VERSION: 2.14-678a
BUILD: 180613-0943
Asterisk 11.25.1-vici

I also installed on the Disaster recovery server the same ISO and they have the same Version/Build. Pretty much identical which is why it was puzzling me.
I even ran update IP on the backup server"


I also tried to change the expected schema on the conf.



Rebooted the server and still have the same error accessing system settings on the UI (http://viciserver/vicidial/admin.php?AD ... 1111111111).

Code: Select all

 WARNING: Code expects different schema: 1549

This is the error I get on Apache error logs.

Code: Select all

PHP%20Warning:%20%20mysqli_fetch_row()%20expects%20parameter%201%20to%20be%20mysqli_result,%20boolean%20given%20in%20/srv/www/htdocs/vicidial/admin.php%20on%20line%2036364,%20referer:%20http://10.25.100.129/vicidial/admin.php?ADD=999998

4) If the new server will have a new IP, I hope it's obvious to you that all the other servers in the cluster must be informed of the new IP, and rebooted to take effect systemwide on each server.

I do have a new IP. Bit unsure how this is done though.

Am I missing something?

Normally at the beginning of the install process most admins would run "zyyper up" to update all opensuse modules and apps which would also trigger vicidial to pull the latest SVN version. In your case your backup server pulled SVN 3017.

Before restoring your backup try to get the SVN version from your current production dialer. Once you have this delete the contents of /usr/src/astguiclient/trunk after which on the /usr/src/astguiclient folder run this command.

svn checkout -r {version_number} svn://svn.eflo.net/agc_2-X/trunk

Make sure to change "{version_number}" using the SVN version of your production system.

You would then need to probably delete the contents of the following folders before re-installing. To make sure that no SVN version 3017 still exists.

/srv/www/htdocs/agc/
/srv/www/htdocs/vicidial/
/usr/share/astguiclient/

You may need to delete some more folders but I guess those would suffice. Check if your /etc/astguiclient.conf still has all the necessary details for your new box. After which run this command inside /usr/src/astguiclient/trunk/ folder.

perl install.pl --no-prompt

You would then need to reboot your machine and check if everything is in-order.

bourneshell wrote:...

Minor adjustments/suggestions:

During a full reinstall with perl install.pl, it's not necessary to delete any files. All necessary files will be overwritten.

We do not use the "no-prompt" option in favor of recording (for posterity) the final "continue?" summary in a ticket specific to the server in question. That Q/A has been known to save many technician from believing they are going insane (eg: someone DID change this after the fact, cuz there it is in the install script summary! I knew it!).

For most installs (not if Only DB, which seems likely the case here, but just in case ...) we recommend using the install sample configs option and editing the externip in sip.conf to be sure what just happened results in the proper Asterisk configuration files for the version of Vicidial which was just installed. A tiny change in a conf file can (once again) cause unneeded hair loss. It's entirely possible (ie: personal experience) to have hundreds of success stories before your first fail. But that first fail can be very time-consuming. If you have many edits to the stock configuration files, you should be looking at modifying your methods (there are various places in Vicidial where these customizations can be added using the GUI which transcends the physical files, and survives updates even if the standard conf files change A Lot).

Thanks for the help everyone!

I just had to run this apparently.

Code: Select all

mysql -u root -p asterisk < /usr/src/astguiclient/trunk/extras/upgrade_2.14.sql

That solved it for me.

hashtagjet wrote:Thanks for the help everyone!

I just had to run this apparently.

Code: Select all

mysql -u root -p asterisk < /usr/src/astguiclient/trunk/extras/upgrade_2.14.sql

That solved it for me.

This would cause your DB server to be running with the same code and DB schema. But the other servers in the cluster, when connected during/after failover, will still be running the previous code and that code will expect the older db schema.

Playing with fire.

williamconley wrote:

hashtagjet wrote:Thanks for the help everyone!

I just had to run this apparently.

Code: Select all

mysql -u root -p asterisk < /usr/src/astguiclient/trunk/extras/upgrade_2.14.sql

That solved it for me.

This would cause your DB server to be running with the same code and DB schema. But the other servers in the cluster, when connected during/after failover, will still be running the previous code and that code will expect the older db schema.

Playing with fire.

So to be safe, If I use this method, I should make sure all applications run on the same version and build then? Right?

Short answer: Yep.

Deeper ... It makes no difference which method you use: all scripts/code/vicidial pages must have the same version at all times across the entire system. The code is built for one specific DB schema, and any tiny difference can "work for a while" and then crash with some weirdness that can't be explained without pulling hair. Until you realize that some servers or some scripts are the wrong version, and that's NOT easy. Only the SVN folder has the SVN revision level. Only the admin pages have the "admin version" (which is then the same version for all files ...). Outside the SVN folder, each set of files may have different revisions based on the last time they were changed. Confusion ensues. Other pages and scripts are only updated when they change, thus the challenge. But an SVN reinstall will overwrite all of them and ensure you are (for want of a better term) "Synced".