Upgrade Orion to Pollux

In this section is listed the manual steps to do when migrating from Orion to Pollux.

Warning

Upgrade to Pollux:

  • Postgres database will be updated from 15 to version 17 during upgrade.

Before Upgrade

On XiVO PBX

When upgrading from a Debian 11 (Bullseye) based version (Izar to Luna) you might need to manually remove the bullseye-backport repository before launching upgrade:

sed '/bullseye-backports/d' -i /etc/apt/sources.list

On XiVO CC

XIVOCC_TYPE Variable

  • Before starting the upgrade, you MUST define the variable XIVOCC_TYPE in the custom.env file.

    This variable indicates the installation type, allowing the installer to clean up and validate the environment accordingly.

    Accepted values:

    • full: Complete installation including all components (XUC, XUC management, reporting, recording, and NGINX).

    • app: Application-only installation including xuc, xucmgt, and nginx.

    • backend: Reporting and recording modules only.

    If the variable is missing, it will be set to full by default, and a warning will be displayed in the log file:

    WARN: XIVOCC_TYPE variable has been automatically set to 'full' (fully installed).

    Important

    You should explicitly set the correct value to avoid unnecessary configuration steps or invalid cleanup.

On MDS

When upgrading from a Debian 11 (Bullseye) based version (Izar to Luna) you might need to manually remove the bullseye-backport repository before launching upgrade:

sed '/bullseye-backports/d' -i /etc/apt/sources.list

On Edge

N.A

On Meeting Rooms

N.A

After Upgrade

On XiVO PBX

PostgreSQL upgrade

If the upgrade went well, it’s suggested to remove the old postgres log files:

rm -rf /var/log/postgresql/postgresql-15-main*.log
rm -rf /var/log/postgresql/postgresql-11-main*.log

High Availability

Important

When upgrading a High Availibility installation from an older LTS (like Maia) you MUST follow these additionnals steps. These steps deactivate and then reactivate the High Availability in order to ensure the new Resilience features are available.

Warning

Services will be restarted during this procedure.

  1. Disable XiVO Slave - see Disable node,

    Warning

    After this step services may need to be stopped on the slave in order to not disturb telephony operation on the Master.

  2. Disable XiVO Master - see Disable node,

  3. Ensure needed steps of Resilience Slave Stack Installation are followed depending on the deployment type. It consists mainly in configuring/re-configuring the CC associated to the XiVO Slave.

  4. And finally reconfigure the resilience as described in Resilience Configuration Details to ensure Pollux Resilience features are available

On XiVO CC

Variable Cleanup and Validation

  • The custom.env file is now automatically validated and cleaned depending on the value of XIVOCC_TYPE.

  • The script performs the following actions:

    • Only variables relevant to the selected type are retained.

    • Deprecated or unused variables are removed.

    • Required variables are added if missing (with default or empty values).

    • Some values are validated (e.g., IP format check for REPORTING_HOST).

  • Examples of automatic handling:

    WARN: 'RECORDING_SERVER_HOST' is not an IP address. Resetting its value in custom.env.
INFO: Setting 'REPORTING_HOST' from 'XUC_HOST=10.10.10.20' in custom.env.
INFO: custom.env cleaned and validated for type 'backend'.

  • If optional variables are missing, they are appended as empty keys.

Manual Review

Important

After the upgrade, you MUST review the custom.env file manually.

In particular:

  • Verify the value of XIVOCC_TYPE.

  • If the installer cleared or reset any variables, fill in the correct values.

  • Ensure required IP addresses or hostnames are properly defined.

Log Location

  • All operations performed on custom.env are logged in:

    /var/log/xivocc-installer.log

  • You should read this log file to confirm that the migration proceeded correctly and that no manual steps remain.

On MDS

PostgreSQL upgrade

If the upgrade went well, it’s suggested to remove the old postgres log files:

rm -rf /var/log/postgresql/postgresql-15-main*.log
rm -rf /var/log/postgresql/postgresql-11-main*.log

On Edge

Note

Specific steps to workaround changes from containerd.io 2.x

  1. Ensure containerd is pinned to the right version and configured with the new LimitNOFILE value:

    cat > /etc/apt/preferences.d/containerd <<EOF
Package: containerd.io*
Pin: version 2.*
Pin-Priority: 1000
EOF

mkdir -p /etc/systemd/system/containerd.service.d
cat > /etc/systemd/system/containerd.service.d/override.conf <<EOF
[Service]
LimitNOFILE=100000
EOF

systemctl daemon-reload
systemctl restart containerd.service

  2. Restart the containers to apply the services

    edge-dcomp up -d

On Meeting Rooms

Note

Specific steps to workaround changes from containerd.io 2.x

  1. Ensure containerd is pinned to the right version and configured with the new LimitNOFILE value:

    cat > /etc/apt/preferences.d/containerd <<EOF
Package: containerd.io*
Pin: version 2.*
Pin-Priority: 1000
EOF

mkdir -p /etc/systemd/system/containerd.service.d
cat > /etc/systemd/system/containerd.service.d/override.conf <<EOF
[Service]
LimitNOFILE=100000
EOF

systemctl daemon-reload
systemctl restart containerd.service

  2. Restart the containers to apply the services

    meetingrooms-dcomp up -d