Bug 482885 - Default yum config used during install
Default yum config used during install
Status: CLOSED WONTFIX
Product: Spacewalk
Classification: Community
Component: WebUI (Show other bugs)
0.4
All Linux
low Severity medium
: ---
: ---
Assigned To: Mike McCune
Red Hat Satellite QA List
:
Depends On:
Blocks: swcobbler06 space16
  Show dependency treegraph
 
Reported: 2009-01-28 12:28 EST by John Hodrien
Modified: 2011-08-05 08:05 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-05 08:05:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Hodrien 2009-01-28 12:28:21 EST
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 10:10:12 EDT
this one didn't make 0.5, moving to 0.6
Comment 2 Erik van Pienbroek 2009-09-10 03:14:07 EDT
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 09:52:37 EDT
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 2010-11-19 11:04:24 EST
Mass-moving to space13.
Comment 5 Miroslav Suchý 2011-04-11 03:32:58 EDT
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 03:36:59 EDT
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.
Comment 7 Jan Pazdziora 2011-07-20 07:51:07 EDT
Aligning under space16.
Comment 8 Jan Pazdziora 2011-08-05 08:05:31 EDT
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.

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