Bug 482885

Summary:	Default yum config used during install
Product:	[Community] Spacewalk	Reporter:	John Hodrien <johnh>
Component:	WebUI	Assignee:	Mike McCune <mmccune>
Status:	CLOSED WONTFIX	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	low
Version:	0.4	CC:	erik-fedora, jpazdziora, mmccune
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-08-05 12:05:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	490771, 723481

Description John Hodrien 2009-01-28 17:28:21 UTC

Description of problem:

Let's assume you don't want to touch the default repos and just use spacewalk. Currently it's a complete pain to achieve that. During the install fedora-release or centos-release will install files in /etc/yum.repos.d/ that will be used by yum later on. This isn't a problem during the first stage of the install as these aren't used.

rhnreg_ks, however, uses yum to download packages associated with an activation key, and so ends up pulling in packages that you didn't want installed. Overriding the yum config is the only solution, but it's currently fairly painful to acheive, as spacewalk claims the first post script.

Version-Release number of selected component (if applicable):

How reproducible:

Repeatable.

Steps to Reproduce:
1. Kickstart where some packages are associated with the activation key, on a machine that cannot see the outside world (makes it easy to see).
2. Look what happens at the rhnreg_ks step.

Actual results:

Machine attempts to contact hosts listed in the /etc/yum.repos.d/*.repo files.

Desired results:

Machine will just access the spacewalk repos.

Additional info:

I understand this is a general requirement, but there needs to be an easy way to achieve it. If the order of the post scripts could be controlled (such that the user could insert a post script before the spacewalk one) then this problem would be much reduced.

To be honest, I'd imagine that this behaviour would be the default, as why would you want your client machines to go outside of spacewalk?

Comment 1 Mike McCune 2009-03-23 14:10:12 UTC

this one didn't make 0.5, moving to 0.6

Comment 2 Erik van Pienbroek 2009-09-10 07:14:07 UTC

This bug still occurs with Spacewalk 0.6.

It prevents users to use the provisioning feature in environments with no direct internet access. The rhn_check command performed in the %post phase uses yum to install some packages..and this always fails in such environments because yum bails out while trying to download repository information from the public mirrors (as those can't be reached)

Comment 3 John Hodrien 2009-09-10 13:52:37 UTC

Easily worked round with a pre-script (this worked with 0.5, I've not tested against 0.6), but I agree the default behaviour is undesirable.


mkdir -p /tmp/ks-tree-shadow/etc/yum.repos.d/custom
cat << EOF > /tmp/ks-tree-shadow/etc/yum.conf
[main]
cachedir=/var/cache/yum
reposdir=/etc/yum.repos.d/custom/
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
distroverpkg=centos-release
tolerant=1
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
EOF

Comment 4 Jan Pazdziora (Red Hat) 2010-11-19 16:04:24 UTC

Mass-moving to space13.

Comment 5 Miroslav Suchý 2011-04-11 07:32:58 UTC

We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 6 Miroslav Suchý 2011-04-11 07:36:59 UTC

We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 7 Jan Pazdziora (Red Hat) 2011-07-20 11:51:07 UTC

Aligning under space16.

Comment 8 Jan Pazdziora (Red Hat) 2011-08-05 12:05:31 UTC

Since the workaround is available (see comment 3), I'm going to close this bugzilla now.

Please reopen if there is a patch available which would solve the problem in a more elegant manner.