Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 453454 - Want real config files in yum.repos.d
Summary: Want real config files in yum.repos.d
Alias: None
Product: Spacewalk
Classification: Community
Component: Clients
Version: 0.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John Matthews
QA Contact: Red Hat Satellite QA List
Depends On:
Blocks: space08
TreeView+ depends on / blocked
Reported: 2008-06-30 18:37 UTC by Michael DeHaan
Modified: 2011-08-25 13:51 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-01-27 20:51:58 UTC

Attachments (Terms of Use)
Config file per repo changes for by James Antill (deleted)
2008-09-19 19:31 UTC, John Matthews
no flags Details

Description Michael DeHaan 2008-06-30 18:37:04 UTC
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 13:22:48 UTC
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 17:56:24 UTC
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 18:00:06 UTC
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 18:58:35 UTC
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, 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 19:31:23 UTC
Created attachment 317229 [details]
Config file per repo changes for by James Antill

Comment 6 John Matthews 2009-02-20 18:21:44 UTC
This won't be in spacewalk 0.5, punting to space06

Comment 8 Michael Mráka 2010-01-27 20:51:58 UTC
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 12:58:55 UTC
Spacewalk 0.8 has been released

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