#1348 Make it possible and easy to upgrade between various versions and OSes, regenerating config files where needed
Closed: migrated a year ago by dmoluguw. Opened 6 years ago by adelton.

With FreeIPA in a container (https://github.com/adelton/docker-freeipa), the configuration and data produced by the versions of IPA and its components during initial ipa-server-install are stored in a volume. Files and directories stored on the volume are listed at


and they are symlinked from the image (for example, /var/lib/pki -> /data/var/lib/pki).

It is then possible to use image built with different (newer) version of IPA or even built on different OS (Fedora -> CentOS) and start new container with this new image, giving it volume populated with configuration and data files produced by the old container. At that point, upgrade process needs to be run to make the data and configuration match the versions of the software being started in the container.

In normal installation, upgrades are often achieved at rpm upgrade time, in %post scriptlets. That seems to be the case for pki-server as well so in


in function upgrade_server we actually get the scriptlet from pki-server and run it verbatim. It merely seems to do

## NOTE:  At this time, NO attempt has been made to update ANY PKI subsystem
##        from EITHER 'sysVinit' OR previous 'systemd' processes to the new
##        PKI deployment process

echo "Upgrading server at `/bin/date`." >> /var/log/pki/pki-server-upgrade-10.2.1.log 2>&1
/sbin/pki-server-upgrade --silent >> /var/log/pki/pki-server-upgrade-10.2.1.log 2>&1
echo >> /var/log/pki/pki-server-upgrade-10.2.1.log 2>&1

systemctl daemon-reload

and it mostly works.

One issue we've hit is the difference in the packaging of resteasy. In /etc/sysconfig/pki-tomcat (which I'd consider part of instance configuration, so it lives in the volume (and it actually does not seem to exist before ipa-server-install is run, so it's not possible to just use the default value from the image)),


is used to match the installation.

However, when pki-server-upgrade is run this file is not upgraded. Maybe it's related to the comment at the start of the scriptlet, that updates from old systemd processes are not supported?

We've workarounded this particular issue in the docker-freeipa's upgrade script but it'd be nice if Dogtag could provide for IPA upgrader a single generic tool (maybe pki-server-upgrade is it) which would handle upgrades completely, for reasonable mix of old / new versions, taking into account that with containers, people are likely to try wilder combinations than when the classical "I have my rpm-based machine, I upgrade with yum" setup is used.

The simplified upgrade mechanism for IPA is tracked at https://fedorahosted.org/freeipa/ticket/4904.

The pki-server-upgrade is used to upgrade old Dogtag configuration into a new Dogtag configuration on the same platform. Switching between platforms (e.g. Tomcat 7 to Tomcat 8, Fedora to RHEL) on the same Dogtag version should be done using a separate pki-server-migrate command (will be added in #1264).

Will running the new pki-server-migrate do the right thing when run on the same platform, both migrating among Tomcat versions and running pki-server-upgrade?

With containers, we really do not know nor care what the old platform was. We know we have some configuration/data/content in the volume and we know that we want to use it with the current software version and that is it. So we are looking for a tool which will be idempotent and at the same time be able to take any (reasonable) original state and upgrade/migrate/migrate+upgrade it to state usable by the current version of the container software.

Per Dogtag 10.2.X TRIAGE meeting of 04/28/2015: 10.3

Metadata Update from @adelton:
- Issue set to the milestone: UNTRIAGED

4 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Metadata Update from @dmoluguw:
- Issue close_status updated to: migrated
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.