Bug 1315964 - unable to upgrade 5.6.0@externalOracle to 5.7.0@externalPostgreSQL (IMO would be same for all PostgreSQL variants)
Summary: unable to upgrade 5.6.0@externalOracle to 5.7.0@externalPostgreSQL (IMO would...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Upgrades
Version: 570
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Tomáš Kašpárek
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-09 07:20 UTC by Jan Hutař
Modified: 2018-04-09 14:56 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-09 14:56:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jan Hutař 2016-03-09 07:20:32 UTC
Description of problem:
unable to upgrade 5.6.0@RHEL6@externalOracle to 5.7.0@RHEL6@externalPostgreSQL (IMO would be same for all PostgreSQL variants)


Version-Release number of selected component (if applicable):
Satellite-5.7.0-RHEL6-re20150108.2-x86_64.iso
rhn-upgrade-5.7.0.29-1.el6sat.noarch


How reproducible:
always


Steps to Reproduce:
1. Attempt to upgrade 5.6.0@RHEL6@externalOracle to
   5.7.0@RHEL6@externalPostgreSQL (no OS upgrade)


Actual results:
# /mnt/tmp/install.pl --upgrade --external-postgresql --run-updater=yes
* Starting Red Hat Satellite installer.
* Performing pre-install checks.
* Pre-install checks complete.  Beginning installation.
* RHN Registration.
** Registration: System is already registered with RHN.  Not re-registering.
* Upgrade flag passed.  Stopping necessary services.
* Purging conflicting packages.
* Checking for uninstalled prerequisites.
There are some packages from Red Hat Enterprise Linux that are not part
of the @base group that Satellite will require to be installed on this
system. The installer will try resolve the dependencies automatically.
* Installing RHN packages.
Warning: yum did not install the following packages:
        OpenIPMI
        OpenIPMI-libs
        lm_sensors-libs
        net-snmp-libs
        uuid
* Now running spacewalk-setup.
* Setting up SELinux..
** Database: Setting up database connection for PostgreSQL backend.
Hostname (leave empty for local)? extpg.example.com
Port [5432]? 
Database? mydb3
Username? mydbuser
Password? 
** Database: Populating database.
The Database has schema.  Would you like to clear the database [Y]? y
** Database: Clearing database.
** Database: Shutting down spacewalk services that may be using DB.
** Database: Services stopped.  Clearing DB.
** Database: Re-populating database.
*** Progress: ####################################
* Setting up users and groups.
** GPG: Initializing GPG and importing key.
You must enter an email address.
Admin Email Address? root@localhost
* Performing initial configuration.
* Activating Red Hat Satellite.
** Certificate not activated.
** Upgrade process requires the certificate to be activated after the schema is upgraded.
* Enabling Monitoring.
* Configuring apache SSL virtual host.
Should setup configure apache's default ssl server for you (saves original ssl.conf) [Y]? y
* Configuring tomcat.
* Configuring jabberd.
* Creating SSL certificates.
** Skipping SSL certificate generation.
* Deploying configuration files.
* Update configuration in database.
* Setting up Cobbler..
cobblerd does not appear to be running/accessible
Cobbler requires tftp and xinetd services be turned on for PXE provisioning functionality. Enable these services [Y]? y
This portion of the Red Hat Satellite upgrade process has successfully completed.
Please refer to appropriate upgrade document in /etc/sysconfig/rhn/satellite-upgrade
for any remaining steps in the process.


Expected results:
DB should be migrated.


Additional info:
In /usr/share/perl5/vendor_perl/Spacewalk/Setup.pm (spacewalk-setup-2.3.0-15.el6sat.noarch) there is:


[...]
use constant ORACLE_RHNCONF_BACKUP =>
  '/tmp/oracle-rhn.conf';
[...]
sub is_db_migration {
        [...]
        if (-f ORACLE_RHNCONF_BACKUP) {
                read_config(ORACLE_RHNCONF_BACKUP, \%config);
        } else {
                read_config(DEFAULT_RHN_CONF_LOCATION, \%config);
        }

        # Satellite 5.3 and older used default_db -> we know we are on Oracle
        # -> we know we want to migrate to PostgreSQL (no --external-oracle specified)
        return 1 if (exists $config{'default_db'});

        # Satellite 5.4 and beyond used db_backend
        return 1 if (exists $config{'db_backend'} and $config{'db_backend'} eq 'oracle');

        return 0;
}
[...]


So if there is no file /tmp/oracle-rhn.conf (with backup of rhn.conf created before configuration to new external PostgreSQL was written), we are not doing the migration.

That file seems to be created in install.pl:


[...]
sub backup_oracle_rhnconf {
  my $opts = shift;
  my $schema_version;

  return if ((not $opts->{'upgrade'}) or -f Spacewalk::Setup::ORACLE_RHNCONF_BACKUP);

  foreach my $schema ('satellite-schema', 'rhn-satellite-schema') {
    system("rpm -q --qf='%{VERSION}' $schema >/dev/nul 2>&1");
    if ($? >> 8 == 0) {
      $schema_version = `rpm -q --qf='%{VERSION}' $schema 2>/dev/null`;
    }
  }

  if ($schema_version and $schema_version =~ /^5\.[2345]\./ and
      -f Spacewalk::Setup::DEFAULT_RHN_CONF_LOCATION) {
    system("cp", "-f", Spacewalk::Setup::DEFAULT_RHN_CONF_LOCATION, Spacewalk::Setup::ORACLE_RHNCONF_BACKUP);
  }
}
[...]


So if I read that correctly, that file is created only when satellite-schema package is installed in version 5.5 and below.

Comment 2 Jan Hutař 2016-03-09 07:29:46 UTC
As a workaround to get this running after I found `./install.pl --upgrade --external-postgresql` did not migrated mine DB, I have restored /etc/rhn/rhn.conf from backup (so it contains mine external Oracle DB connection info) and downgraded satellite-schema package to 5.5.* version with `rpm -Uvh --oldpackage satellite-schema-5.5.0.13-1.el6sat.noarch.rpm`.

Comment 3 Jan Hutař 2016-03-09 07:31:14 UTC
There is a workaround, so lowering severity.

Comment 4 Tomas Lestach 2016-03-09 08:57:50 UTC
Jan, my understanding is, this upgrade scenario isn't supported. Feel free to point me to any sources, in case I'm wrong.
I'd say you need to do it in two steps:
1) upgrade 5.6.0@extOra -> 5.7.0@extOra
2) migrate 5.7.0@extOra -> 5.7.0@extPG according to https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/5.7/html/Installation_Guide/sect-Migrating_from_an_External_Oracle_Database_to_an_External_PostgreSQL_Database.html
(Btw. this docs still needs to be verified by QA, see ​Bug 1313492 for more info.)

It looks like NOTABUG for me.

Comment 5 Jan Hutař 2016-03-09 10:35:07 UTC
IMO it is:

Check /etc/sysconfig/rhn/satellite-upgrade/README from rhn-upgrade-5.7.0.29-1.el6sat.noarch package:

| Database considerations
| -----------------------
| 
| Red Hat Satellite 5.7 supports several options for database backend:
| 
| 1. ... embedded ... PostgreSQL ...
| 
| 2. ... managed ... PostgreSQL ...
| 
| 3. ... external PostgreSQL ...
| 
| 4. ... external Oracle ...
| 
| 
| If your current Satellite uses embedded Oracle database, ...
| 
| If your current Satellite uses external Oracle database, you may upgrade to
| Red Hat Satellite 5.7 with database options 1, 2, 3 or 4.

I'll be happy if you prove me I miss-understood here :-/

Comment 6 Tomas Lestach 2016-03-09 15:06:24 UTC
I'm aware the upgrade has some gaps, that's why Bug 1313262.

Comment 7 Ales Dujicek 2016-09-21 09:10:10 UTC
Another way to workaround it is to create the backup manually before ./install.pl --upgrade
# cp /etc/rhn/rhn.conf /tmp/oracle-rhn.conf
But then you would hit bz1315974 anyway

Comment 8 Tomas Lestach 2018-04-09 14:56:18 UTC
We have re-reviewed this bug, as part of an ongoing effort to improve Satellite/Proxy feature and bug updates, review and backlog.

This is a low priority bug and has no currently open customer cases. While this bug may still valid, we do not see it being implemented prior to the EOL of the Satellite 5.x product. As such, this is being CLOSED DEFERRED. 

Closing now to help set customer expectations as early as possible. You are welcome to re-open this bug if needed.


Note You need to log in before you can comment on or make changes to this bug.