Bug 494870 - Server version mismatch when syncing from Master Satellite
Summary: Server version mismatch when syncing from Master Satellite
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Satellite Synchronization
Version: 530
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Pradeep Kilambi
QA Contact: Jeff Browning
URL:
Whiteboard:
Depends On:
Blocks: 457071
TreeView+ depends on / blocked
 
Reported: 2009-04-08 13:35 UTC by Jeff Browning
Modified: 2009-09-10 20:04 UTC (History)
1 user (show)

Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-10 20:04:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jeff Browning 2009-04-08 13:35:53 UTC
Description of problem:
When syncing from a master satellite, you get this error by default with all normal configurations in place:

13:00:21 Retrieving / parsing channel-families data
+++ sending log as an email +++

SYNC ERROR:

(Check logs/email for potentially more detail)


Error Message:
    Client version 3.3 does not match server version 3.2
Error Class Code: 3012
Error Class Info: Mismatching versions

The workaround is to edit this file on the Master:

/usr/share/rhn/satellite_exporter/constants.py

And change PROTOCOL_VERSION to 3.3, then restart httpd. This is not a standard configuration step for ISS.

Version-Release number of selected component (if applicable):
Satellite-5.3.0-RHEL5-re20090403.2-i386-embedded-oracle.iso

How reproducible:
100%

Steps to Reproduce:
1. Install two satellites
2. Configure them normally to be master and slave
3. Try to satellite-sync -l from the slave to the master
  
Actual results:
13:00:21 Retrieving / parsing channel-families data
+++ sending log as an email +++

SYNC ERROR:

(Check logs/email for potentially more detail)


Error Message:
    Client version 3.3 does not match server version 3.2
Error Class Code: 3012
Error Class Info: Mismatching versions

Expected results:
It should work without having to use the workaround.

Additional info:

Comment 2 Jeff Browning 2009-04-27 22:25:32 UTC
Protocol version is now set at 3.3 by default.

Verified

Comment 3 Michael Mráka 2009-08-12 13:36:14 UTC
Verified in stage -> RELEASE_PENDING.

* successfuly ISS'ed without touching PROTOCOL_VERSION on any of master/slave.

Comment 4 Brandon Perkins 2009-09-10 20:04:30 UTC
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.

http://rhn.redhat.com/errata/RHEA-2009-1434.html


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