Bug 700527 - rhncfg-client lists lower-ranked config channel for file
Summary: rhncfg-client lists lower-ranked config channel for file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Configuration Management
Version: 540
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Lestach
QA Contact: Martin Minar
URL:
Whiteboard:
Depends On: 633400
Blocks: sat54-blockers
TreeView+ depends on / blocked
 
Reported: 2011-04-28 15:26 UTC by Tasos Papaioannou
Modified: 2018-11-14 14:18 UTC (History)
7 users (show)

Fixed In Version: spacewalk-backend-1.2.13-54
Doc Type: Bug Fix
Doc Text:
Consequence: When a client is subscribed to several configuration channels containing a common configuration file, rhncfg doesn't reflect set configuration channel priorities. Result: rhncfg correctly reflects set configuration channel priorities.
Clone Of: 633400
Environment:
Last Closed: 2011-08-23 04:09:46 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Patch proposed (1.19 KB, patch)
2011-07-13 00:17 UTC, Marcelo Moreira de Mello
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1194 0 normal SHIPPED_LIVE Red Hat Network Satellite Server spacewalk-backend bug fix update 2011-08-23 04:09:39 UTC

Description Tasos Papaioannou 2011-04-28 15:26:05 UTC
+++ This bug was initially created as a clone of Bug #633400 +++

Description of problem:
If a system is subscribed to two configuration channels, and the same filename is included in both channels, then the client-side commands "rhncfg-client elist" or "rhncfg-client list" display the wrong (lower rank) configuration channel for that file.

Example, using Satellite 5.4 on RHEL 5.6 x86_64:
spacewalk-backend-config-files-1.2.13-38.el5sat

and client on RHEL 5.6 x86_64:
rhncfg-client-5.9.27-1.el5sat

Steps to Reproduce:

1.) Set up two configuration channels, config-1 and config-2.
2.) In both channels, create the same file, /tmp/test.txt.
3.) Subscribe the client system to both configuration channels, with config-1 set to rank 1 and config-2 set to rank 2.
4.) From the client system, run rhncfg-client elist or rhncfg-client list, and see that the config-2 version of the file is incorrectly listed:

# rhncfg-client elist
Mode          Owner Group          Size Rev      Config Channel    File
-rw-r--r--     root root              5   1          config-2    /tmp/test.txt

5.) Actual deployment of the files via "rhncfg-client get" does pull the correct files, however.

Actual results:
config-2 channel is listed as the source for /tmp/test.txt.

Expected results:
config-1 channel is listed as the source for /tmp/test.txt.

The problem is in /usr/share/rhn/server/handlers/config/rhn_config_management.py on the Satellite server. The client_list_files function loops through the configuration channels (in order of highest rank to lowest rank) and adds each file to result_hash, without checking whether the file was already added by a previous config channel. The following patch resolves the issue:

# diff -pruN /usr/share/rhn/server/handlers/config/rhn_config_management.py.bak /usr/share/rhn/server/handlers/config/rhn_config_management.py
--- /usr/share/rhn/server/handlers/config/rhn_config_management.py.bak	2011-04-28 10:59:52.000000000 -0400
+++ /usr/share/rhn/server/handlers/config/rhn_config_management.py	2011-04-28 10:59:03.000000000 -0400
@@ -143,7 +143,9 @@ class ConfigManagement(configFilesHandle
                     break
 
                 path = row['path']
-                result_hash[path] = (config_channel, path, row['config_file_type_id'])
+                # result_hash[path] = (config_channel, path, row['config_file_type_id'])
+                if not path in result_hash:
+                    result_hash[path] = (config_channel, path, row['config_file_type_id'])
 
         result = result_hash.values()
         # Sort by path first since that's what the web site does

Comment 1 Stephan Dühr 2011-06-17 12:09:59 UTC
The patch does not handle local overrides correctly. Before applying the patch, rhncfg-client elist, shows the System ID for local override files. After the patch, it shows a config channel name. rhncfg-client verify still works correctly.

Comment 2 Stephan Dühr 2011-07-04 08:55:02 UTC
Please note that after applying this patch, rhncfg-client elist only incorrectly displays the config channel name instead of the system ID for locally managed files that override a file in a config channel. Also note that the Size and Rev Column of the output correctly show the Size and Rev of the local override file.

Comment 5 Marcelo Moreira de Mello 2011-07-13 00:17:06 UTC
Created attachment 512542 [details]
Patch proposed

Hello, 

 Patch were sent to spacewalk devel maillist for approval.

   Mail Thread: 
     https://www.redhat.com/archives/spacewalk-devel/2011-July/msg00010.html

Cheers, 
mmello

Comment 8 Tomas Lestach 2011-07-26 12:21:15 UTC
Jan committed Marcelo's patch to upstream as: 46830082e095a9273ef2e5fe6fcd3a91eb14a952

Comment 15 Tomas Lestach 2011-08-15 15:24:00 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Consequence:
When a client is subscribed to several configuration channels containing a common configuration file, rhncfg doesn't reflect set configuration channel priorities.
Result:
rhncfg correctly reflects set configuration channel priorities.

Comment 18 errata-xmlrpc 2011-08-23 04:09:46 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/RHBA-2011-1194.html


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