The new v.5.0 Beta copies are up here:
http://download.vicidial.com/iso/vicibox/server/beta/I need people to test installing them on whatever hardware you want. If some of the more advanced users want to test things like the new vicibox-upgrade or the --restore option in vicibox-install please give me feedback.
You can also make these ISO's into USB variants using the instructions here:
http://en.opensuse.org/SDB:Live_USB_sti ... _.28GUI.29Some noteworthy changes made in v.5.0 are:
- Finally added the --restore flag to vicibox-install to allow an easier way to replace or upgrade old servers
- Added vicibox-upgrade to allow you to upgrade the DB Schema and local SVN versions, does not modify crontab or configuration files (too many unknowns there)
- Asterisk v.1.8.22
- DAHDI v.2.6.1 (Maintains v.1.4 compatibility)
- LibPRI v.1.4.14
- OpenR2 v.1.3.2
- VoiceSync v.1.3.2
- MariaDB v.5.5.29
- Apache v.2.2.22
- ViciDial SVN 1983 v.2.8-403a build 130510-1350 (needs updating but I was lazy, its a beta for a reason, just tell the installer to update)
- Sangoma Wanpipe is broken, call them and tell them to add Kernel 3.7+ support (we just recommend digium anymore)
- Sangoma VoiceTime is *STILL* broken, call them and tell them to add DAHDI v.2.6+ support
The --restore option of vicibox-install.pl will allow you to take a new server and replace an old one without re-creating all the vicidial and vicibox entries in the database. It will also attempt to install the same SVN version as what is in the vicibox table or prompt you for the version to use. It is not a replacement for adequate back-ups or disaster recovery procedures. You will still need to back-up voicemails, recordings, and anything custom in your configuration files or crontab. It merely allows you to quickly replace a machine in a cluster with a spare with minimal downtime and re-configuration. This will NOT, I repeat NOT, help you with a primary database failure and/or promoting the slave. That will still require a good sysadmin to accomplish and some sort of establish emergency plan. The --restore is designed to help expedite the replacement of the non-database servers in a ViciDial Cluster such as the Telephony and Web servers.
The new vicibox-upgrade program is designed to accomplish three things:
1) Upgrading the database schema on the primary database and updating the vicibox table with the new SVN revision
2) Synchronizing the telephony and web servers to the SVN revision on the database preventing a schema/code mismatch
3) Creating and maintaining a vicibox table on older legacy installs (requires user-input initially on each server)
You will STILL need to read through the UPGRADE document to see if there are any new changes, additions, or subtractions to the the crontab or other configuration files like /etc/asterisk/extensions.conf. The purpose of the upgrade is to synchronize the SVN code updates on all the various servers with the DB Schema revision. It became apparent that the vicibox table was lacking a mechanism to track future SVN upgrades which resulted in server additions being installed with an incorrect SVN codebase. This will also allow you to copy the upgrade program located at /usr/local/bin/vicibox-upgrade.pl to older servers in order to update them as well. It is not version specific to ViciBox v.5.0. There is no down-grade functionality for the database so make sure you have back-up's and procedures in place to go downgrade if the upgrade goes wrong. Other then that, the upgrade program is very straight forward.
Things we specifically need help testing and debugging (you can even write code patches), in order of importance, are as follows:
1) Some moderate load testing with the new MariaDB Engine in a cluster configuration (Dialer separate from DB/Web)
2) The --restore option
3) Testing the upgrade option
4) Asterisk v.1.8 feedback (Audio good/bad? Does it crash more/less? Is your load higher/lower? etc)
We might be interested in offering free support to a business who is willing to help us test MariaDB under some load. We would require you to have two machines, one as a DB/Web and second as Telephony, with 10 or more agents on it for testing purposes. We would then need to schedule a time so that we can watch your crew run on the dialer while we monitor the back-end and look for any bugs. Due to the issues of MySQL v.5.5 and ViciDial we are trying to evaluate if the same occurrences happen with MariaDB. You need to be an established call center that already knows how to use ViciDial for us to be interested. We are not offering this for someone who wants to start a call center or get started with ViciDial. We want to spend our time squashing bug not training people.
Anyways, enjoy. Please give me feedback when you can. Thanks.