Upgrading SipXcom from 19.04 to 25.01

[Massimo Vignone]

Hi everybody,

I'm attempting to upgrade SipXcom from version 19.04 to the latest release, 25.01. I backed up and restored from 19.04 to 21.04, then repeated the operation from 21.04 to 24.01, without any particular problems.
I'm repeating the operation on the VM with version 24.01: after performing the backup, I attempted to restore the VM with version 25.01 using the command "sipxconfig-archive --restore configuration.tar.gz", but I get the following output:

[root@sipx-mo-1 24.01]# ls
cdr.tar.gz  configuration.tar.gz  voicemail.tar.gz
[root@sipx-mo-1 24.01]# sipxconfig-archive --restore configuration.tar.gz
Restore uses /var/sipxdata/tmp as temporary dir.
version
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 6; 2615 2200 SCHEMA public postgres
pg_restore: error: could not execute query: ERROR:  schema "public" already exists
Command was: CREATE SCHEMA public;


pg_restore: warning: errors ignored on restore: 1
Failed to restore database from archive.
Create or restore configuration to/from an archive file.
        --backup <archive>           Restore the specified Configuration archive.

Backup options:
        --restore <archive>          Restore the specified Configuration archive.
        --verbose                    Restore the specified Configuration archive.

Restore options:
        --no-device-files            Do not include device uploaded files in backup.
        --tmp-dir <tmp-dir>          Temporary backup file location
        --ipaddress <address>        IP Address. Default 155.185.168.1.
        --domain <domain>            SIP domain for new system. i.e. example.org. Default is to keep domain from archive
        --fqdn <fqdn of primary machine>
                                     Set FQDN of this primary machine
        --dryrun                     Don't actually restore db, but test the db migration process.
        --reset-pin default-pin      Blindly reset all pins to given pin.
        --reset-password default-password
                                     Blindly reset all user portal passwords. Password is also used for IM and call center.
        --crack-pin default-pin      When changing the domain and when restoring from backups for versions 4.4.0, attempt to recover original Voicemail PIN by brute force. If unsuccessful, reset users pin. Also, if user does not have an IM password, this pin will be used for that as well.
        --crack-passwd default-passwd
                                     When changing the domain and when restoring from backups for versions 4.4.0, attempt to recover original user PIN by brute force. If unsuccessful, reset users pintoken. Also, if user does not have an IM password, this pin will be usedfor that as well.
        --crack-pin-len length       Maximum length of PIN to attempt. Default is 4. Higher values take exponentially more time.
        --no-restart                 Use this flag if sipxconfig is already stopped and you do not want this script to re-stop or start sipxconfig after it's done.
[root@sipx-mo-1 24.01]#

Where am I going wrong?

Massimo

--

Massimo Vignone

massimo...@gmail.com

[OnRelay Support]

That is quite the upgrade chain, and not a surprise if something goes awry along the way along the lines of e.g. SQL data table column changes, PostgreSQL version compatibility issues and / or OS changes to access right handling. 

However, as 24.01 was still on PostgreSQL 9.2, we will attempt to add more recent --clean --if-exists flags to all pg_restore command that have been available since v9.4. No guarantee it will solve it, but adding those flags are safe nevertheless, since pg_restore directly follows sipxconfig db drop createdb.

Provided no regression errors found the above restore flags will be included in update 10 shortly.

[Massimo Vignone]

I've submitted issue #69 with a possible workaround.

HTH,

Massimo

[OnRelay Support]

Thanks for raising the issue and adding all the work around info. 

We believe using the --clean flag in combination with the --if-exists flag is safe, it worked safely for a regression test, so we have added this to update 10 that is published as we speak.

We are however still keeping the issue open for now.