Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 989094
Description of problem: Upgrading from Fedora18 and FreeIPA server 3.1.5-1 to Fedora 19 and FreeIPA server 3.2.2-1 fails while upgrading directory server. The work around of running ipa-ldap-updater and ipa-upgradeconfig following the failure is successful.
Steps proposed on a meeting:
When RPM upgrade succeeds, it writes the upstream version ID to system (/var/lib/ipa/sysupgrade/sysupgrade.state). When it fails, version is not written
Next time, when ipa service starts and detects that upgrade was not performed (comparing it's version with stored one), it would execute the upgrade before IPA starts
3.4 development was shifted for one month, moving tickets to reflect reality better.
Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.
Moving stabilization tickets that do not affect FreeIPA 4.0 release usability in any significant way to 4.0.1 stabilization milestone.
FreeIPA 4.0.1 was released, moving to next bugfixing release milestone.
Alternatively, instead of running the upgrade automatically (may be quite intrusive change), we could at least:
Given that we plan to potentially convert to systemd native services (#4552), ipactl would be removed and the upgrade check mechanism would need to be completely different than what was proposed.
ipactl
We should thus only stay with documentation approach present in our release notes and defer the real solution.
See #4800 for a scenario that needs to be covered.
Fixed in 9f049ca .
IPA will not start if upgrade is required.
Manual steps on upgrade is prone to mistakes. I'd like to reopen this ticket and propose an alternative solution:
Add the following to the freeipa.service systemd unit:
ExecStartPre=/usr/bin/ipa-server-upgrade
Modify {{{ipa-server-upgrade}}} to check the current and target versions of FreeIPA on the system and short-circuit to quick success to avoid slowing down the start-up of a fully-upgraded system.
This should still work with the upgrade environments because the freeipa.service unit should not be started at all, unless something in the system-upgrade.target {{{Requires=}}} or {{{Wants=}}} freeipa.service, which it never should. So what will happen is that the packages would be updated in the system-upgrade environment and then on the first "real" boot of the upgraded system, freeipa.service would be started and then run {{{ipa-server-upgrade}}} first.
freeipa server upgrade may take several minutes,
I'm afraid that user may not expect this delay and try to restart services manually, which may break upgrade.
Opened a new ticket, this milestone has been closed.
https://fedorahosted.org/freeipa/ticket/5373
Metadata Update from @mkosek: - Issue assigned to mbasti - Issue set to the milestone: FreeIPA 4.2
Login to comment on this ticket.