Upgrade 3.13 to 3.13.2. Db is not upgraded?

Question
1

I installed privacyidea 3.13 a few weeks ago following this procedure:

Today I ran an apt update and see that 3.13.2 is available for the privacyidea and privacyidea-nginx packages.

If I run apt upgrade and tell it to overwrite the ip file pi.cfg, the update fails (from the logs, I see that it fails when trying to create the new database and user because they already exist).

I updated by running “apt-get install --only-upgrade privacyidea-nginx privacyidea” without modifying pi.cfg, and then running an apt upgrade to update the other packages on the server.

The server is working, I can log in with OTPs, I can access the web page, and at the bottom left, I see “privacyIDEA 3.13.2”

In the file on GitHub READ_BEFORE_UPDATE.md I read “The rollout_state of fully enrolled tokens has changed… A database migration script updates all existing tokens with an empty or NULL rollout_state to enrolled”

In my server under “Token” > “All Tokens” the “Rollout Status” column is empty anyway

If I launch the “pi-manage db history” command, the lines for version 3.13 that I find are these:
06b105a4f941 → b1a2c3d4e5f6 (head), Create missing tokencredentialidhash_seq on existing installs
b637a1eeeeeb → 06b105a4f941, v3.13: Change the Audit id column type to BigInt
056b6642ff5d → b637a1eeeeeb, v3.13: Add S/MIME columns to smtpserver table
1c48d4ffb8c3 → 056b6642ff5d, v3.13: Increase audit signature column size to support 4096-bit RSA keys
52c494a115a9 → 1c48d4ffb8c3, v3.12: Add option column to radiusserver table

Did the procedure I followed to update the packages not update the database? How can I update it now?

2

Hi mengainside,

from what you describe, it looks like the pi.cfg file was overwritten during the package update.

Please note that this file is not just a simple configuration file. It contains important installation-specific settings and secrets such as:

  • the database password

  • PI_PEPPER

  • encryption and signing keys

  • other local privacyIDEA configuration parameters

During upgrades, it can occasionally happen that the package provides a newer version of pi.cfg. This is usually because new configuration variables, new features, or changed defaults have been introduced in a newer privacyIDEA release.

For this reason, overwriting pi.cfg should always be done with great care. Before accepting the package maintainer’s version, you need to review the differences and ensure that all existing installation-specific values from your current configuration are merged into the new file. Simply replacing the file with the package version can remove critical settings and secrets required to access existing token data.

Please check /etc/privacyidea/ for backup files of the previous configuration, for example:

ls -la /etc/privacyidea/

Debian/Ubuntu often keep files such as:

pi.cfg.dpkg-old
pi.cfg.dpkg-dist
pi.cfg.ucf-old

If no suitable backup is available there, please restore the original pi.cfg from a snapshot or system backup.

As long as the original configuration (especially PI_PEPPER and the encryption-related settings) is not restored, privacyIDEA may still start successfully and the web UI may be reachable, but existing tokens may not be displayed correctly in the Web UI and encrypted token data may not be accessible.

Best regards

Julio

4

One important note: At this point, this is only a hypothesis based on the symptoms you described.

To confirm the actual root cause, please check the privacyIDEA log file:

less /var/log/privacyidea/privacyidea.log
5

Thanks for the replies.

No, the pi.cfg file has NOT been overwritten.
I ran some tests, restoring the VM to snapshots prior to the update, and the pi.cfg file was saved before all these tests.

If, during the update of the two privacyidea packages, I allowed the pi.cfg file to be overwritten with the most recent one, the system would crash (in addition to losing the custom settings).
I was thinking of installing the new version of the pi.cfg file and then re-producing the custom options from the old one, but the upgrade procedure, if it copies the new pi.cfg, attempts to recreate the database and the primary user. This fails (it finds the database and user already created), and it doesn’t complete.

If I update the packages without overwriting the pi.cfg file, the update completes without problems. The web GUI tells me I have version 3.13.2, and everything seems to be working fine.
In the log you indicated, I don’t see any lines different from those of the previous few days, nor any errors.

My question is this:
In the file on GitHub READ_BEFORE_UPDATE.md I read “The rollout_state of fully enrolled tokens has changed… A database migration script updates all existing tokens with an empty or NULL rollout_state to enrolled”

In my server under “Token” > “All Tokens” the “Rollout Status” column is empty anyway
Shouldn’t I find a value like “enrolled” there?

If I launch the “pi-manage db history” command, the lines for version 3.13 that I find are these:
06b105a4f941 → b1a2c3d4e5f6 (head), Create missing tokencredentialidhash_seq on existing installs
b637a1eeeeeb → 06b105a4f941, v3.13: Change the Audit id column type to BigInt
056b6642ff5d → b637a1eeeeeb, v3.13: Add S/MIME columns to smtpserver table
1c48d4ffb8c3 → 056b6642ff5d, v3.13: Increase audit signature column size to support 4096-bit RSA keys
52c494a115a9 → 1c48d4ffb8c3, v3.12: Add option column to radiusserver table

Can you tell from this if the database schema has been updated?
If it has been updated, why is the “Rollout status” column blank?