Issue #980: F19 to F20 upgrade fails - dogtagpki

dogtagpki

#980 F19 to F20 upgrade fails

Closed: Invalid Opened Apr 26, 2014 by krbvroc1.

Attempted 'fedup --network 20' upgrade from F19 10.0.5 to F20 10.1.1.

The upgrade does not work:
1) Attempt to start pki-tomcat server complains about
/usr/share/pki/scripts/operations: line 1394: /etc/sysconfig/pki/tomcat/pki-tomcat/pki-tomcat: Permission denied

2) After changing above ownership to pkiuser
Failed making '/var/lib/pki/pki-tomcat/alias' -> '/etc/pki//alias' since target '/etc/pki//alias' does NOT exist!

Notice that the instance name is missing. I believe 10.1 changed PKI_INSTANCE_ID to PKI_INSTANCE_NAME but that is not upgraded properly when going from 10.0 to 10.1 via fedup.
The /etc/sysconfig/pki/tomcat/pki-tomcat/pki-tomcat still contains the old PKI_INSTANCE_ID variable

I'm going to try an F20 ISO install (which should be 10.0.5) to see if that works.

krbvroc1 commented Apr 27, 2014

F20 ISO is also 10.1.0 so I am unable to test 10.0.5. Cannot even upgrade to ISO release due to perl dependencies issue with dogtag.

krbvroc1 commented Apr 27, 2014

I see https://fedorahosted.org/pki/ticket/805 fixes this. However after a fedup install, I verified
that /usr/share/pki/upgrade/10.0.99 is missing.

pki-base-10.1.1-1.fc20.noarch does NOT contain a 10.0.99 directory.

mharmsen commented May 1, 2014

Replying to [comment:2 krbvroc1]:

I see https://fedorahosted.org/pki/ticket/805 fixes this. However after a fedup install, I verified
that /usr/share/pki/upgrade/10.0.99 is missing.

pki-base-10.1.1-1.fc20.noarch does NOT contain a 10.0.99 directory.

pki-server-10.1.1-1.fc20.noarch contains the 10.0.99 directory:

# rpm -qlp pki-server-10.1.1-1.fc20.noarch.rpm | grep upgrade
/usr/lib/python2.7/site-packages/pki/server/upgrade.py
/usr/lib/python2.7/site-packages/pki/server/upgrade.pyc
/usr/lib/python2.7/site-packages/pki/server/upgrade.pyo
/usr/sbin/pki-server-upgrade
/usr/share/man/man8/pki-server-upgrade.8.gz
/usr/share/pki/server/upgrade
/usr/share/pki/server/upgrade/10.0.0
/usr/share/pki/server/upgrade/10.0.1
/usr/share/pki/server/upgrade/10.0.1/01-ReplaceRandomNumberGenerator
/usr/share/pki/server/upgrade/10.0.1/02-CloningInterfaceChanges
/usr/share/pki/server/upgrade/10.0.1/03-AddRestServlet
/usr/share/pki/server/upgrade/10.0.2
/usr/share/pki/server/upgrade/10.0.3
/usr/share/pki/server/upgrade/10.0.4
/usr/share/pki/server/upgrade/10.0.5
/usr/share/pki/server/upgrade/10.0.5/01-EnableSessionInAuthenticator
/usr/share/pki/server/upgrade/10.0.6
/usr/share/pki/server/upgrade/10.0.99
/usr/share/pki/server/upgrade/10.0.99/01-FixJavaOpts
/usr/share/pki/server/upgrade/10.0.99/02-RemoveAuthProperties
/usr/share/pki/server/upgrade/10.0.99/03-FixRegistryFile
/usr/share/pki/server/upgrade/10.0.99/04-FixLogFileOwnership

mharmsen commented May 1, 2014

On 04/25/14 14:35, krbvroc1 wrote:

On 04/25/2014 04:47 PM, krbvroc1 wrote:

I did 'tail -f' catalina.out on the f19 master and noticed right before the above failure:

SSLAuthenticatorWithFallback: Authenticating with BASIC authentication
SSLAuthenticatorWithFallback: Fallback auth header: WWW-Authenticate=Basic realm="Certificate Authority"
SSLAuthenticatorWithFallback: Fallback auth return code: 401
SSLAuthenticatorWithFallback: Result: false

This seems like an important clue. What is this authentication that is trying to happen and why might it be failing?

I think this is something I changed on the master (last year) and forgot about! While tracking this error down, I noticed I had modified the web.xml.
I undid my change to web.xml and cloning complete. So sorry!

vakwetu commented May 1, 2014

Is this issue resolved?

Notice that the upgrade scripts are in pki-server - not pki-base, and have a different path. You should be looking in the /var/log/pki-server-upgrade.log to see if there are any hints as to why the upgrade script failed.

krbvroc1 commented May 1, 2014

Replying to [comment:4 mharmsen]:

On 04/25/14 14:35, krbvroc1 wrote:

On 04/25/2014 04:47 PM, krbvroc1 wrote:

I did 'tail -f' catalina.out on the f19 master and noticed right before the above failure:

SSLAuthenticatorWithFallback: Authenticating with BASIC authentication
SSLAuthenticatorWithFallback: Fallback auth header: WWW-Authenticate=Basic realm="Certificate Authority"
SSLAuthenticatorWithFallback: Fallback auth return code: 401
SSLAuthenticatorWithFallback: Result: false

This seems like an important clue. What is this authentication that is trying to happen and why might it be failing?

I think this is something I changed on the master (last year) and forgot about! While tracking this error down, I noticed I had modified the web.xml.
I undid my change to web.xml and cloning complete. So sorry!

I am fairly certain that I reverted my web.xml change before running fedup and filing this bug report (to be sure it was not the cause)

krbvroc1 commented May 1, 2014

Replying to [comment:5 vakwetu]:

Is this issue resolved?

Notice that the upgrade scripts are in pki-server - not pki-base, and have a different path. You should be looking in the /var/log/pki-server-upgrade.log to see if there are any hints as to why the upgrade script failed.

Sorry, I looked in the wrong package. There are really no hints as to what/why the upgrade did not run.

cat /var/log/pki/pki-server-upgrade-10.1.1.log

Upgrading server at Sat Apr 26 20:45:01 EDT 2014.
Upgrading from version 10.0.99 to 10.1.1:
1. Fix JAVA_OPTS in tomcat startup
2. Remove auth.properties
3. Replace PKI_INSTANCE_ID and fix registry file ownership
4. Fix log file ownership

pki-tomcat instance:
Configuration version: 10.0.7

pki-tomcat/ca subsystem:
Configuration version: 10.0.7

Upgrade incomplete.

AND

find /var/log/pki/server/upgrade/10.0.99/

/var/log/pki/server/upgrade/10.0.99/

/var/log/pki/server/upgrade/10.0.99/4

/var/log/pki/server/upgrade/10.0.99/3

/var/log/pki/server/upgrade/10.0.99/2

/var/log/pki/server/upgrade/10.0.99/1

All the above directories are empty - not sure if there are supposed to be log files for each of the stages or not.

mharmsen commented May 6, 2014

Per discussion with alee on IRC on 5/5/2014, the only thing left to do for this ticket is to attempt to replicate it.

However, it should be noted that IPA has accomplished upgrading its portion of Dogtag 10.0 (Fedora 19) --> Dogtag 10.1 (Fedora 20) on numerous occasions without any issues.

mharmsen commented May 20, 2014

krbvroc1,

Per the previous comment, no one else has encountered this issue, and unfortunately, no one has had the cycles to attempt to replicate this.

Were you able to work around this issue, or is it still a blocker for you?

krbvroc1 commented May 20, 2014

Replying to [comment:9 mharmsen]:

krbvroc1,

Per the previous comment, no one else has encountered this issue, and unfortunately, no one has had the cycles to attempt to replicate this.

Were you able to work around this issue, or is it still a blocker for you?

I worked around this with manual methods. I too haven't had the time to try to reproduce it.

mharmsen commented Dec 8, 2015

Per CS/DS Meeting of 12/07/2015: Closed Won't Fix

Metadata Update from @krbvroc1:
- Issue set to the milestone: 10.1.3

Feb 27, 2017

dmoluguw commented Oct 4, 2020

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:
https://github.com/dogtagpki/pki/issues/1546

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

Assignee

None

Tags

None

Blocking

None

Depending on

None

Priority

Normal

type

defect

component

Installation/Configuration

feature

None

origin

Community

proposedpriority

None

proposedmilestone

None

dogtagpki

#980 F19 to F20 upgrade fails Closed: Invalid Opened Apr 26, 2014 by krbvroc1.

Metadata

#980 F19 to F20 upgrade fails

Closed: Invalid Opened Apr 26, 2014 by krbvroc1.