Bug 453454 - Want real config files in yum.repos.d
Want real config files in yum.repos.d
Product: Spacewalk
Classification: Community
Component: Clients (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Matthews
Red Hat Satellite QA List
Depends On:
Blocks: space08
  Show dependency treegraph
Reported: 2008-06-30 14:37 EDT by Michael DeHaan
Modified: 2011-08-25 09:51 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-01-27 15:51:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Config file per repo changes for rhnplugin.py by James Antill (23.68 KB, application/octet-stream)
2008-09-19 15:31 EDT, John Matthews
no flags Details

  None (edit)
Description Michael DeHaan 2008-06-30 14:37:04 EDT
Description of problem:

I'd like Spacewalk to have real config files in yum.repos.d for channels, rather
than having them on the server where from the client, they cannot be configured,
accessed, or queried.

Two use cases:

(A) I would like to manage which channels a system accesses with a configuration
management system of my choice (or vim).  I should of course have entitlements
for the channels that require entitlements, but it should also be possible to
have channels that expose themselves as simple HTTP mirrors that do not require
entitlements to access (as should be the case for a Fedora repo)

(B) I would like to be able to enable options like the yum priorities plugin to
control the priority of channels from Spacewalk versus other repos I have
configured with yum.

This enables Spacewalk to concentrate on channel management and I can use it
better with things like cfengine/puppet/bcfg2 or even Func.

This may require forking yum_rhn_plugin and making a spacewalk_rhn_plugin, and
installing both, or otherwise adding additional capabilities.
Comment 1 Jan Pazdziora 2008-07-09 09:22:48 EDT
We will probably need to do more detailed analysis about how this "Spacewalk
which is only a management of channel mirroring" should interact with the
current "Spacewalk which allows you to setup channels and packages on systems on
the WebUI". In the current situation, the server needs to know what channels the
client is subscribed to, to be able to provide Web-based management of packages
and (for example) errata-notifications. If the configuration of the client can
change randomly on the client system side, what functionality should be
available to that system?
Comment 2 Clifford Perry 2008-08-01 13:56:24 EDT
Not sure if this makes full sense. Would making the plugin able to merge in
client side configs with server side generated repo configs work? Make our
plugin play nicer with yum and other plugin's in general. 

Use case A - well - your asking to allow client to choose channels it is
subscribed too on the Spacewalk system. This would seem to indicate that someone
who does not have the right permissions in UI (does not have a
username/password, just a systemid file) now has permissions to change
subscriptions and thus entitlements consumed. I do not think this is a good
thing to do. We lose the concept of a central package repository as well and
management of systems registered to your Spacewalk system. 

Use case B - I agree with, but think it can be done with a more robust plugin

Aligned to Space 0.3 for now, but not sure we know/agree with possible change. 


Comment 3 Michael DeHaan 2008-08-01 14:00:06 EDT
This is a use case expressed to me many times by various users who are not using
Satellite but might like to.

I would assume Satellite could still gate access to restricted content, but they
want to be able to manage their repos with config management tools.

So, think of this in terms of other use cases and widening the userbase.

Perhaps this is something we do in Pulp first to prove it is possible and then
move it to Spacewalk.
Comment 4 John Matthews 2008-09-19 14:58:35 EDT
For RHEL 5.3 we added in the ability to set per repo config options.  The options are currently set in the rhnplugin.conf file.  A section is created per repo.id, any option put in that section will be passed into the YumRepo object. 

For example if you wanted to use yum-protectbase and prevent fastrack from over writing a package you would do the below.

enabled = 1

enabled = 1
protect = yes

enabled = 1

This allows a user to disable a channel on the client side (setting enabled=0), yet the ultimate access control is still on the server side for enabling.  The client does a call to the server and gets a list of potential channels.  It then looks to form yum repos per channel.  If the local config options says to disable a channel, the repo will not be formed.  

For RHEL 5.4 we plan to proceed to the next step and provide a file per repo which can do the same options.  We are concerned where the repo files should be located.  We are worried if we store the repo files under /etc/yum.repos.d AND the rhnplugin is disabled, yum wouldn't be able to access the repos and errors would show up.  We are thinking of creating a new directory and storing the files there.   We received a patch from James Antill which does this functionality, it creates a separate directory and stores the repo files there.  

How does this sound?
Comment 5 John Matthews 2008-09-19 15:31:23 EDT
Created attachment 317229 [details]
Config file per repo changes for rhnplugin.py by James Antill
Comment 6 John Matthews 2009-02-20 13:21:44 EST
This won't be in spacewalk 0.5, punting to space06
Comment 8 Michael Mráka 2010-01-27 15:51:58 EST
As for (A) in Spacewalk 0.7 we introduced 'spacewalk-channel' tool which allows you change subscribed channels from commandline (from client). 

As for (B) aditional per channel options can be configured in /etc/yum/pluginconf.d/rhnplugin.conf (see comment #4).

Closing now, if you disagree feel free to re-open.
Comment 9 Michael Mráka 2010-02-16 07:58:55 EST
Spacewalk 0.8 has been released

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