Bug 644239 - ISS based satellite-sync should fall back automatically on client 3.4
ISS based satellite-sync should fall back automatically on client 3.4
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Satellite Synchronization (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Miroslav Suchý
Jiri Kastner
: Regression
Depends On:
Blocks: sat54-errata
  Show dependency treegraph
Reported: 2010-10-19 04:28 EDT by Jérôme Fenal
Modified: 2010-12-13 09:31 EST (History)
5 users (show)

See Also:
Fixed In Version: spacewalk-backend-1.2.13-14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-12-13 09:31:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jérôme Fenal 2010-10-19 04:28:15 EDT
Description of problem:

Satellite 5.4 comes with a new XML protocol, 3.6, incompatible by default with Satellite 5.3 version : 3.4

Specifying --dump-version=3.4 makes ISS work between Sat 5.3 & Sat 5.4, but as the satellite-sync client knows it is talking to 3.4 server, it should really switch to 3.4 XML automatically.

Version-Release number of selected component (if applicable):
Satellite 5.4, build satellite-embedded-oracle-5.4.0-20101015-rhel-5-x86_64.iso

How reproducible:

Steps to Reproduce:
1. Setup ISS, master Satellite 5.3, slave Satellite 5.4
2. satellite-sync -l does not work
3. satellite-sync --dump-version=3.4 -l works
Actual results:
# satellite-sync -l
23:19:25 Red Hat Network Satellite - live synchronization
23:19:25    url: https://sat.octothorpe.fr
23:19:25    debug/output level: 1
23:19:25    db:  rhnsat/<password>@rhnsat
23:19:25 Retrieving / parsing channel-families data
+++ sending log as an email +++


(Check logs/email for potentially more detail)

Error Message:
    Client version 3.6 does not match server version 3.4
    Error Class Code: 3012
    Error Class Info: Mismatching versions

Expected results:

Since client knows it is talking to 3.4 server, it should switch to 3.4 protocol automatically.

Fallback : issue message to user to use --dump-version=3.4 to make things work.

Additional info:
Comment 1 Miroslav Suchý 2010-11-03 05:59:26 EDT
Commited to spacewalk.git as d5d0fa098df3f6a56329bd093c29e968992c1036

do not check minor version of xml_dump_version
All dumps with the same major version are (and in future should) be backward
and forward compatible.
Old satellites can understoo new dumps as new xml attributes and elements, which old
satellite do not understood are ignored (like sha256 checksums).
And new satellites understood older dumps. We always have to be able to read old dumps.
If we ever move to new incompatible format, we will have to bump up major version of xml_dump.
Comment 2 Miroslav Suchý 2010-11-22 08:25:43 EST
cherry picked to satellite.git as commit 6b9df358caeade0331d643d7509f0a0be77507e5
Comment 4 Miroslav Suchý 2010-11-23 06:05:47 EST
Note: the verification of protocol check is made on master. Therefore this change is only for setup
Sat5.4 (master) - Sat5.3 and older (slave).

To allow 5.3 as master and 5.4 as slave we will need to backport it and release 5.3 errata.
Comment 5 Jan Hutař 2010-11-24 08:41:44 EST
please note this issue will be fixed in Satellite 5.4.0, so we expect configuration "Satellite 5.3.0 slave; 5.4.0 master" to work now (see comment #1).

If you want this to be fixed in Satellite 5.3.0 as well, please open support ticket.

Comment 7 Jiri Kastner 2010-11-24 08:49:34 EST
verified with setup mentioned in comment 5 as this bug is against satellite 5.4 version.
Comment 8 errata-xmlrpc 2010-12-13 09:31:57 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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