I want to upgrade my cluster from 4.3 to 4.4, beginning with the spare for live testing. But since there is a change to the trusted table (which we don't use, only address) this isn't possible without some tricks. There is no override for skipping the version check on any permissions table.
I need to share the subscriber/location/address/usr_preferences and db_aliases tables between the 4.3 and 4.4 machines. The only thing I can think of is: -patch the permissions module to accept the old version of trusted -create a 4.4 database and use federated tables to access the 4.3 data
Not hard to implement any of these 2, but some other modules have the option to skip these checks, eg: http://www.kamailio.org/docs/modules/4.4.x/modules/auth_db.html#auth_db.p.ve...
Is there a reason not all modules have this flag (which you could use at your own risk)? Or am I missing something here?
On donderdag 18 augustus 2016 12:29:25 CEST Daniel Tryba wrote:
I want to upgrade my cluster from 4.3 to 4.4, beginning with the spare for live testing. But since there is a change to the trusted table (which we don't use, only address) this isn't possible without some tricks. There is no override for skipping the version check on any permissions table.
The changes are backwards compatible with the old version. You can just use another "version" table on the new instance.
http://sip-router.org/wiki/cookbooks/core-cookbook/devel#version_table
Seems docs haven't made it to kamailio.org.
I need to share the subscriber/location/address/usr_preferences and db_aliases tables between the 4.3 and 4.4 machines. The only thing I can think of is: -patch the permissions module to accept the old version of trusted -create a 4.4 database and use federated tables to access the 4.3 data
Not hard to implement any of these 2, but some other modules have the option to skip these checks, eg: http://www.kamailio.org/docs/modules/4.4.x/modules/auth_db.html#auth_db.p.ve rsion_table
IMHO that option needs to be removed.
On Thu, Aug 18, 2016 at 03:50:53PM +0200, Alex Hermann wrote:
I want to upgrade my cluster from 4.3 to 4.4, beginning with the spare for live testing. But since there is a change to the trusted table (which we don't use, only address) this isn't possible without some tricks. There is no override for skipping the version check on any permissions table.
The changes are backwards compatible with the old version. You can just use another "version" table on the new instance.
http://sip-router.org/wiki/cookbooks/core-cookbook/devel#version_table
Seems docs haven't made it to kamailio.org.
Perfect. Just what is needed in this kind of scenario. But before this goes to kamailio.org:
version_table
Set the name of the table holding the table version. Usefull if the proxy is sharing a database within a project and during upgrades. Default value is "version".
Example of usage:
table_version=sr_table_version
This example isn't correct, it's version_table not table_version according to 4.4.x cfg.lex
On 18/08/16 17:19, Daniel Tryba wrote:
On Thu, Aug 18, 2016 at 03:50:53PM +0200, Alex Hermann wrote:
I want to upgrade my cluster from 4.3 to 4.4, beginning with the spare for live testing. But since there is a change to the trusted table (which we don't use, only address) this isn't possible without some tricks. There is no override for skipping the version check on any permissions table.
The changes are backwards compatible with the old version. You can just use another "version" table on the new instance.
http://sip-router.org/wiki/cookbooks/core-cookbook/devel#version_table
Seems docs haven't made it to kamailio.org.
Perfect. Just what is needed in this kind of scenario.
Just to add a note for a kind of alternative -- for more complex cases, when tables are no longer backward compatible, the solution can be using table views within a different database. Of course, provided that you use a sql server that has support for views (e.g., mysql).
Cheers, Daniel
On 18/08/16 15:50, Alex Hermann wrote:
On donderdag 18 augustus 2016 12:29:25 CEST Daniel Tryba wrote: [...]
I need to share the subscriber/location/address/usr_preferences and db_aliases tables between the 4.3 and 4.4 machines. The only thing I can think of is: -patch the permissions module to accept the old version of trusted -create a 4.4 database and use federated tables to access the 4.3 data
Not hard to implement any of these 2, but some other modules have the option to skip these checks, eg: http://www.kamailio.org/docs/modules/4.4.x/modules/auth_db.html#auth_db.p.ve rsion_table
IMHO that option needs to be removed.
It is actually useful, especially for auth, when having constraints of access to a custom database for fetching username/password -- table name and columns can be changed to map on the custom database, creation of a new table not being allowed.
Cheers, Daniel
-
Alex Hermann -
Daniel Tryba -
Daniel-Constantin Mierla