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.
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?
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 client. Aligned to Space 0.3 for now, but not sure we know/agree with possible change. Cliff.
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.
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. /etc/yum/pluginconf.d/rhnplugin.conf enabled = 1 [rhel-i386-server-5] enabled = 1 protect = yes [rhel-i386-server-fastrack-5] 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?
Created attachment 317229 [details] Config file per repo changes for rhnplugin.py by James Antill
This won't be in spacewalk 0.5, punting to space06
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.
Spacewalk 0.8 has been released