Here's the deal:
dogtag 9 is based on tomcat6. It was delivered in f17, f16 etc. dogtag 10 is based on tomcat7 and was first delivered in f18.
When F18 came out, we modified tomcatjss so that it could work with both tomcat6 or tomcat7. That meant that users could update to f18 and update their dogtag packages to dogtag 10, and they could continue to use their old dogtag 9 instances.
For the purpose of terminology, I will define a tomcat-9-style instance as one which is based on tomcat 9 configuration. It is located at /var/lib/pki-ca, and may run using either dogtag 9 or dogtag 10 software, Keep in mind that d-9 instances cannot use any of the new functionality that is exposed through the REST interface, because all of that is based on tomcat 7 configuration.
Now comes F19. In F19, tomcat 6 is no longer delivered. This means dogtag 9 style instances (those installed prior to f18) will stop working. We had hoped to address this as follows:
Note, requiring folks to create a replica makes things much simpler because for one thing, it gets them to a known state. All d10 replicas will have combined directory instances for example.
Unfortunately, it appears that because of the use of anaconda/fedup, the pre-trans check we have in place will not work - and people could end up with broken installs if they upgrade.
I'll put more details in subsequent posts.
So, if someone has a broken install because of the upgrade, he should be able to get his system up as follows:
http://pki.fedoraproject.org/wiki/Migrating_Dogtag_9_Instances_to_Dogtag_10
Specifically, in the workaround section: 1. install tomcat 6 from f18 2. downgrade tomcatjss to the version from f18 3. Running pki-upgrade to run some d10 upgrade scripts.
He will then have a d9-style instance running on f19. Any functionality based on the restful interfaces will again not work. We added code to return 503 - not supported in case someone tries to access this code.
On the other hand, we need a plan to upgrade d9 style instances.
There are two possibilities.
User creates replica. This will be a true d10 instance. Then user can blow away old d9 instance and re-install from the replica.
We write some kind of migration script to create the new dogtag 10 instance and migrate the data. Or convert the existing instance to a d10 instance. I'll detail the steps in my next post.
So, as I see it, we are trying to migrate from dogtag 9 style instances which live in /var/lib/pki-ca and which have split databases - to dogtag 10 style instances with combined databases. If there are other combinations, then this needs to be discussed.
A migration procedure could be as follows: 1. shut down the existing d9 dogtag instance. 2. Back up the database using db2ldif or similar. 3. set up a new d10 dogtag instance using the same pkispawn parameters you would ordinarily have used to set up a D10 instance. This instance would point to the IPA database instance, rather than the old separated dogtag DS instance. Add the IPA profile and the IPA specific modifications to CS.cfg, any certmonger setup. 4. Shut down this instance and replace the certificate database with the certificate database from the old instance. 5. Replace the needed directives in CS.cfg with entries from the old CS.cfg. We'd have to get a list, but they are the entries having specific values related to the old system certs. 6. Import the saved data from step 2 into the database. 7. Restart the instance. IPA specific files (default.conf? ipa.conf? proxy config file?) may also need to be updated.
As part of step 4, the password for the cert database needs to be replaced in password.conf
After step 3, we need to do IPA specific setup for the dbuser (ie.modifying the certmap). Basically step 3 is running the IPA install process for a IPA D10 instance.
Working on this one. In FreeIPA devel meeting we agreed that the manual procedure is not really an option, we will stick to the migration procedure instead.
See:
On FreeIPA.org site, I updated affected release notes with a link to this migration page.
Would it be possible before upgrade to clone the dogtag instance 'on the same server', from the separate instance to the integrated IPA instance ? Would this make things easier ?
From a dogtag point of view, thats certainly possible. We regularly create clone instances on the same server when testing. My guess is that we would run into various port/settings issues with the ipa install scripts - for example, when referencing the default.conf.
Someone would have to try it and see how the install scripts can be modified to work. This would be easier than having to clone to a new server, and then cloned back. It may just be messier.
We do not have capacity to address this issue. It is already clearly documented.
This is really something we won't do now, closing as wontfix instead.
Metadata Update from @vakwetu: - Issue assigned to someone - Issue set to the milestone: Tickets Deferred
Login to comment on this ticket.