search

pki-bot / pki-issues-final

0 stars 0 forks source link

F19 to F20 upgrade fails #973

Closed pki-bot closed 3 years ago

pki-bot commented 3 years ago

This issue was migrated from Pagure Issue #980. Originally filed by krbvroc1 on 2014-04-26 18:34:51:

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.

pki-bot commented 3 years ago

Comment from krbvroc1 at 2014-04-26 20:27:53

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.

pki-bot commented 3 years ago

Comment from krbvroc1 at 2014-04-27 02:57:18

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-bot commented 3 years ago

Comment from mharmsen (@mharmsen) at 2014-04-30 20:16:01

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
pki-bot commented 3 years ago

Comment from mharmsen (@mharmsen) at 2014-04-30 20:30:28

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!

pki-bot commented 3 years ago

Comment from vakwetu (@vakwetu) at 2014-04-30 20:41:10

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.

pki-bot commented 3 years ago

Comment from krbvroc1 at 2014-04-30 22:46:41

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)

pki-bot commented 3 years ago

Comment from krbvroc1 at 2014-04-30 22:56:34

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.

pki-bot commented 3 years ago

Comment from mharmsen (@mharmsen) at 2014-05-06 00:41:28

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.

pki-bot commented 3 years ago

Comment from mharmsen (@mharmsen) at 2014-05-19 20:41:12

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?

pki-bot commented 3 years ago

Comment from krbvroc1 at 2014-05-19 20:54:39

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.

pki-bot commented 3 years ago

Comment from mharmsen (@mharmsen) at 2015-12-07 21:08:14

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

pki-bot commented 3 years ago

Comment from krbvroc1 at 2017-02-27 14:04:17

Metadata Update from @krbvroc1: