Upgrading

Upgrading a XiVO is done by executing commands through a terminal on the server. You can connect to the server either through SSH or with a physical console.

To upgrade your XiVO to the latest version, you must use the xivo-upgrade script. You can start an upgrade with the command:

xivo-upgrade

Note

  • You can’t use xivo-upgrade if you have not run the wizard yet
  • Upgrading from a version prior to XiVO 1.2 is not supported.
  • When upgrading XiVO, you must also upgrade all associated XiVO Clients. There is currently no retro-compatibility on older XiVO Client versions.

This script will update XiVO and restart all services.

There are 2 options you can pass to xivo-upgrade:

  • -d to only download packages without installing them. This will still upgrade the package containing xivo-upgrade and xivo-service.
  • -f to force upgrade, without asking for user confirmation

Warning

If xivo-upgrade fails or aborts in mid-process, the system might end up in a faulty condition. If in doubt, run the following command to check the current state of xivo’s firewall rules:

iptables -nvL

If, among others, it displays something like the following line (notice the DROP and 5060)

0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:5060

Then your XiVO will not be able to register any SIP phones. In this case, you must delete the DROP rules with the following command:

iptables -D INPUT -p udp --dport 5060 -j DROP

Repeat this command until no more unwanted rules are left.

Preparing for an Upgrade

  • Consult the roadmaps starting from your current version to the current prod version.
  • Read all existing Upgrade Notes (see below) starting from your version to the current prod version.
  • For custom setups, follow the required procedures described below (example : cluster).
  • To download the packages beforehand, run xivo-upgrade -d. This is not necessary, but useful for upgrading more quickly prior to stopping telephone services.
  • When ready, run xivo-upgrade which will start the upgrade process. Telephone services will be stopped during the process
  • When finished, check that the services are running :
  • with xivo-service status command,
  • and with actual checks like SIP registration, ISDN links status, internal/incoming/outgoing calls, XiVO Client connections etc.

Upgrading from XiVO 14.01, 14.02, 14.03, 14.04 installed from the ISO

In those versions, xivo-upgrade keeps XiVO on the same version. You must do the following, before the normal upgrade:

echo "deb http://mirror.xivo.io/debian/ xivo-five main" > /etc/apt/sources.list.d/xivo-upgrade.list \
&& apt-get update \
&& apt-get install xivo-fai \
&& rm /etc/apt/sources.list.d/xivo-upgrade.list \
&& apt-get update

Upgrading from XiVO 13.03 and before

When upgrading from XiVO 13.03 or earlier, you must do the following, before the normal upgrade:

wget http://mirror.xivo.io/xivo_current.key -O - | apt-key add -

Upgrading from XiVO 12.13 and before

When upgrading from XiVO 12.13 or earlier, you must do the following, before the normal upgrade:

apt-get update
apt-get install debian-archive-keyring

Upgrading from XiVO 1.2.1 and before

Upgrading from 1.2.0 or 1.2.1 requires a special procedure before executing xivo-upgrade:

apt-get update
apt-get install xivo-upgrade
/usr/bin/xivo-upgrade

Upgrading a Cluster

Here are the steps for upgrading a cluster:

  1. On the master : deactivate the database replication by commenting the cron in /etc/cron.d/xivo-ha-master

  2. On the slave, deactivate the xivo-check-master-status script cronjob by commenting the line in /etc/cron.d/xivo-ha-slave

  3. On the slave, start the upgrade:

    xivo-slave:~$ xivo-upgrade
    
  4. When the slave has finished, start the upgrade on the master:

    xivo-master:~$ xivo-upgrade
    
  5. When done, launch the database replication manually:

    xivo-master:~$ xivo-master-slave-db-replication <slave ip>
    
  6. Reactivate the cronjobs (see steps 1 and 2)

Upgrading to/from an archive version

Upgrade Notes

15.12

  • Consult the 15.12 Roadmap
  • The certificate used for HTTPS in the web interface will be regenerated if the default certificate was used. Your browser will complain about the new certificate, and it is safe to accept it (see #3656). See also HTTPS certificate.
  • If you have an HA configuration, then you should run xivo-sync -i on the master node to setup file synchronization between the master and the slave. File synchronization will then be done automatically every hour via rsync and ssh.
  • xivo-auth and xivo-dird now use HTTPS, if you have custom development using these services, update your configuration accordingly.

15.11

  • Consult the 15.11 Roadmap
  • The call records older than 365 days will be periodically removed. The first automatic purge will occur in the night after the upgrade. See Purge Logs for more details.

15.10

15.09

15.08

  • Consult the 15.08 Roadmap
  • The Dialer Xlet has been integrated in Identity Xlet.

15.07

15.06

  • Consult the 15.06 Roadmap
  • The provd client has been moved into a new python package, xivo_provd_client. If you have custom scripts using this client, you’ll need to update them. See http://projects.xivo.io/issues/5469 for more information.
  • The provd_pycli command name has been deprecated in favor of xivo-provd-cli. These 2 commands do the same thing, the only difference being the name of the command. The provd_pycli command name will be removed in 15.10, so if you have custom scripts referencing provd_pycli, you’ll need to update them.
  • The xivo-agentctl command name has been deprecated in favor of xivo-agentd-cli. These 2 commands do the same thing, the only difference being the name of the command. The xivo-agentctl command name will be removed in 15.10, so if you have custom scripts referencing xivo-agentctl, you’ll need to update them.

15.05

  • Consult the 15.05 Roadmap
  • The Xlet identity has been modified to follow the new XiVO Client design which implies the removal of some details.

15.04

15.03

15.02

15.01

  • Consult the 15.01 Roadmap
  • The confd REST API is now more restrictive on HTTP headers. Particularly, the headers Accept and Content-Type must be set to (typically) application/json.
  • The following configuration files have been created:
    • /etc/xivo-agid/config.yml
    • /etc/xivo-call-logd/config.yml
    • /etc/xivo-amid/config.yml
    • /etc/xivo-agentd/config.yml