Asterisell-5.10.2-test

Various improvements and bug-fixes respect v5.10-dev. In particular:

• importing of CDRS on remote MySQL databases
• generation of reports without wasting RAM
• improvements to the manual
• minor improvements to the user interface
• bug fixes

It is used in production, but it is still considered "test" because there are a lot of changes respect last stable version, and not all features are covered by regression tests.

Upgrading from v5.10-dev

If you installed the previous dev version, you can not upgrade it, but you had to reinstall this version from scratch. In case you have data to preserve, you can backup the DB and restore it in the new version, because there are no changes in the DB schema. You can use php asterisell.php data backup.

In case you are installing on the same VM, you had to delete the Asterisell tag files, for forcing a reinstallation from scratch: rm /var/opt/asterisell/SUCCESSFUL_*

Migrating from v5.9 (last stable) to v5.10.2-test

This version changed a lot of things respect last stable version v5.9. In particular the instances are now installed directly on the host/VM, and not anymore inside a Docker container. The management tool is installed on a Docker container.

There is no automatic upgrade like in case of previous release changes. It is more a migration than an upgrade, also if in the end all the data can be transferred.

These are notes on how performing the upgrade, but for understanding them you had to install at least a DEMO version of Asterisell-5.10, otherwise some notes can be too much obscure.

Terms:

• source-host: the host containing the instance to migrate
• source-instance: the instance to migrate
• host: the target host on which install the instance
• instance: the target instance
• management-host: the host containing the Asterisell management tool (it can be also on host)
• asterisell-deploy: the directory of Asterisell management tool (source and dest)

Configure in asterisell_instances.py the host/instance and make sure to not execute cron_job on host/instance, adding this setting in the instance class

    install_cron_job = False

Then install using fab install:host/instance.

Now we can start migration, because we have both source and dest-instance.

# Copy the migration scripts on source-instance
ssh some-user@host
cd scripts/migration_to_v10
scp pass-01-export.sql some-user@source-host:.

# Extract the data from source-instance and send to host 
ssh some-user@source-host
cd asterisell-deploy
docker cp ../pass-01-export.sql source-instance:.
fab connect:source-instance
php asterisell.php cron disable
rm -f /var/tmp/*.csv

cat config/databases.yml
# for findng access passwords

mysql -usource-instance -ppassword source-instance < /pass-01-export.sql 
cd /
tar cfvz db-instance.tar.gz /var/tmp/*.csv
rm -f /var/tmp/*.csv
scp db-instance.tar.gz some-user@host:.
rm db-instance.tar.gz
exit

# Go to management-host.

fab connect:asterisell/instance
cd /var/tmp
rm -f *.csv
tar xfvz /home/some-user/db-instance.tar.gz
mv var/tmp/*.csv .
rm /home/some-user/db-instance.tar.gz 

cd /var/www/instance/admin/scripts/migration_to_v10/

# check access params with
cat ../../config/databases.yml

mysql -uinstance -ppassoword instance < pass-02-import.sql
rm -f /var/tmp/*.csv

cd ..
cd ..
php asterisell.php data update-cached-cdrs

exit

# Now we are again in managemnt-host
# and we enable again triggers,
# that were deleted by pass-02-import.sql
fab upgrade_conf:asterisell/instance

If source-instance has custom holidays set, you had to specify them also in the destination instance, because they are not ported automatically.

If source-instance uses bundle-rates, you had to modify them, removing lines like set-bundle-min-cost: 0.

You had to copy the LOGO of the source-instance, and upload it again in the instance: * using the Web UI * copying the file into directory /var/www/instance/admin/web/uploads/assets

Now you can activate again cron-jobs, removing the install_cron_job in the Instance configuration file, and then

` fab upgrade_conf:asterisell/instance

VoIP extension codes

Asterisell 5.11.1 uses simpler extension codes. It is unlikely, but there can be incompatibilities, and some extensions had to be converted to the new format. In this case it is likely that the application will not recognize these old extensions any more, and it will signal the problem during the rating process.

The new extension format is simpler: "X" and "*" can be used only at the end of extensions and not any more in the middle. So:

• in "12XX" the last "X" stays for "match any character"
• in "1X2" the "X" is not a special symbol, and it matches exactly the "X"
• "12*" matches any extension starting with "12"
• "12" is exactly the "12" extension

The version with "X" and "*" in the middle were not used in practice, and now we can use faster data structures in the code, during rating.

Importing CDRS from remote DBMS

The previous method was based on configuration of connections on asterisell_instances.py file, and custom PHP Jobs retrieving data.

Now remote DBMS are directly supported by the Haskell rating engine, and all params are specified directly in connection params of asterisell_instances.py, and there are no any more custom PHP jobs.

The new method is more robust and DBMS friendly, because it exploits the properties of auto increment field, and do not use transactions on remote databases, but only on local database.