Bug 489736 - Generated Wizard kickstarts use expiring package urls
Summary: Generated Wizard kickstarts use expiring package urls
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Provisioning
Version: 530
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Justin Sherrill
QA Contact: Steve Salevan
URL:
Whiteboard:
Depends On:
Blocks: 457075
TreeView+ depends on / blocked
 
Reported: 2009-03-11 15:54 UTC by Justin Sherrill
Modified: 2009-09-10 19:24 UTC (History)
3 users (show)

Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-10 19:24:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
remote console log - failed kickstart (12.31 KB, text/x-log)
2009-08-11 08:31 UTC, Tomas Lestach
no flags Details

Description Justin Sherrill 2009-03-11 15:54:36 UTC
We generate kickstarts that use urls for packages such as:

wget -P /tmp/rhn_rpms/optional http://@@http_server@@/download/package/f803e3b52d52e17f59ec8d65c2eb33aa40cc2685/1236818400278/1/6096/pyOpenSSL-0.6-1.p23.i386.rpm http://@@http_server@@/download/package/edfe1d04094beb5b893f23ea41919788b6527d2c/1236818400300/1/4672/rhnlib-2.1.2-11.el4.noarch.rpm http://@@http_server@@/download/package/89a0ad0e971e7248ad83c5d2fddab739eab8e5e9/1236818400330/1/5304/libxml2-python-2.6.16-12.6.i386.rpm


These expire after a certain amount of time and we probably need to just get rid of expiring package urls either for kickstart generation or for satellite as a whole.

Comment 1 Clifford Perry 2009-03-17 15:45:55 UTC
I do not agree with making this change. Please re-open as an RFE if you wish to get todd W input in this as well. To me making this change exposes a way for any user who has access to Satellite to gain access to any content on the Satellite, this leaves us in a state where the product is moving from keeping content restricted and needing authorization to gain access to it, to being un-authorized for content. 

So, to me, WONTFIX. I did not see a strong reason within the bug to make this change as being needed within product. Customers with custom or RHEL content often do not want it to be shared and available to all, just select registered systems and users. 

Cliff

Comment 2 Justin Sherrill 2009-03-17 16:10:25 UTC
Cliff, 


We have to fix this bug, since part of the kickstarts are broken because of it.   

We're writing kickstarts to the file system with package urls that expire after 4 hours or so.  Now we have to do one of the following:

1)  Remove expiring urls on packages

2) change it such that just kickstart generation uses urls that don't expire (this would just be for packages such as up2date, rhnlib, etc...) 

3) remove the functionality that tries to update the client packages during the %post section of a kickstart.


Now if we don't want to completely remove expiring urls.  I would vote for option 2.  As that is very low risk, and I don't think most customers would care if people have free reign to download rhnlib.

justin

Comment 3 Mike McCune 2009-03-18 16:11:24 UTC
If I had to pick an option for now I'd go for #2.

Cliff does raise a good point that if customers rely on and *need* channel content to be protected then blindly removing this for all content is probably something we should decide on beyond the scope of this bug.

Comment 4 Clifford Perry 2009-03-19 14:53:01 UTC
Justin - please can you explain why a 4 hr expire time is a problem? Are kickstarts taking longer than 4 hours to complete? 

Cliff

Comment 5 Justin Sherrill 2009-03-19 14:56:35 UTC
Cliff,

We are now writing kickstart files to disk upon modification/creation.  Then whenever they are needed, cobbler reads the files and renders the kickstart.  So say you created the kickstart on monday (it gets written to disk).  And then on friday you to go kickstart a machine.  The urls will have expired.  

We are no longer generating the kickstart files upon demand.

Comment 6 Clifford Perry 2009-03-24 18:35:47 UTC
I swear I *did* this last week and Brandon as my witness! 

Option #2. 

Cliff

Comment 7 Justin Sherrill 2009-03-26 18:59:18 UTC
commit	54d423cd091a2ce6dbd57a79875314ba5a4d01c0
tree	23b28cad47af8d53071ff70fd45aee7bf04f4eab	tree | snapshot
parent	2e8b8a04c63031634158d5761b391da1148a2bb5	commit | diff



- made kickstart package download url generation use non-expiring download urls
- made it so that setting the expiration time to 0 in the config file (web.download_url_lifetime), caused expiration to be disabled server wide
- added "web.non_expirable_package_urls" config option to disable expiration on a package name basis

both of these config values are in /etc/rhn/defaults/rhn_web.conf (but can be overridden in /etc/rhn/rhn.conf)

Comment 8 Steve Salevan 2009-05-15 22:06:20 UTC
Tested and VERIFIED on 5/7 ISO.

Comment 9 Tomas Lestach 2009-08-11 08:31:08 UTC
Created attachment 357000 [details]
remote console log - failed kickstart

Comment 10 Tomas Lestach 2009-08-11 08:32:39 UTC
If I schedule a kickstart at the next system check in, the kickstart works nice.

But if I schedule the start after 12hours (like during night or weekend), kickstart fails with [from remote console]:
--------------------------------------------------------------------------------
loader received SIGSEGV!  Backtrace:                                           
[0x8048cf4]
[0xfa9420]
[0x817ebf3]
[0x806254c]
[0x806bb7b]
[0x806bcb6]
[0x806c167]
[0x806b59e]
[0x80618dc]
[0x8062019]
install exited abnormally [1/1] 
sending termination signals...done
sending kill signals...done
disabling swap...
unmounting filesystems...
	/proc/bus/usb done
	/proc done
	/dev/pts done
	/sys done
	/tmp/ramfs done
you may safely reboot your system
--------------------------------------------------------------------------------
(whole console log in attachment - Comment#9)

on webui I see successfully finished:
* System reboot scheduled by admin	 08/10/09 11:00:56 PM 
* Initiate a kickstart scheduled by admin	 08/10/09 11:00:54 PM 
* Package Install scheduled by admin	 08/10/09 11:00:28 PM 

but the kickstart never finishes.

Reproducer:
1. schedule a kickstart at the next system check in and make sure, the kickstart finishes successfully and the client is capable of this type of kickstart. (run osad on the client)
2. schedule the same kickstart for the same client to be started after 12hours
Kickstart fails.

Using:
Satellite-5.3.0-RHEL5-re20090730.0
Kickstarting a 32bit client with Red Hat Enterprise Linux (v. 5 for 32-bit x86), no Virtualization  

(I reproduced it 3 times with 2 different clients, because I wasn't sure, whether the client is correct.)

Comment 11 Justin Sherrill 2009-08-11 13:13:27 UTC
Hrm,  that backtrace that you are seeing looks like anaconda is crashing and really doesn't have anything to do with this bug.  (an expired package URL wouldn't cause anaconda to crash).

Can you reliably reproduce this issue ?

Comment 12 Tomas Lestach 2009-08-11 13:31:01 UTC
As I wrote, I am sure about this behavior (I've reproduced it several times). Not sure, if it's an anaconda bug, because I'd say, it's the same anaconda that runs in the immediate kickstart and in the postponed kickstart. The only difference was the 12h time offset.
Let me know, if I can provide more information.

Comment 13 Justin Sherrill 2009-08-11 13:51:54 UTC
Oh yeah, i missed that last statement, sorry about that tlestach :}

Comment 14 Clifford Perry 2009-08-11 14:43:14 UTC
Server side log files would indicate clearly on what happened during the FAILED installation vs the successful installation. I propose to open a new bug specific on the information here. Also capture server side logs and/or allow login by devel to system being used to grab/review those log files. If the failure is due to an expired URL, we should see that clearly. If the failure is due to something else, then logs will look normal right until anaconda blew up and stopped requesting the content. 

Cliff

Comment 15 Clifford Perry 2009-08-11 14:45:24 UTC
or of course, also review the ks.cfg used by anaconda for each installation and see if there is anything different within them. (re-reviewing the output given, I cannot tell if anaconda threw the error at start/middle/end of installation process).

Comment 16 Justin Sherrill 2009-08-12 20:09:24 UTC
So looking at the logs:


10.34.33.158 - - [12/Aug/2009:10:30:21 -0400] "GET /cblr/svc/op/ks/system/hp-dl360-05.rhts.englab.brq.redhat.com:1 HTTP/1.1" 200 12266 "-" "Python-urllib/2.4
"
10.34.33.158 - - [12/Aug/2009:10:30:24 -0400] "GET /cobbler/images/ks-rhel-i386-server-5-u3/initrd.img HTTP/1.1" 200 6300177 "-" "Python-urllib/2.4"
10.34.33.158 - - [12/Aug/2009:10:30:43 -0400] "GET /cobbler/images/ks-rhel-i386-server-5-u3/vmlinuz HTTP/1.1" 200 1826516 "-" "Python-urllib/2.4"
10.34.33.158 - - [12/Aug/2009:10:30:46 -0400] "GET /cblr/svc/op/ks/system/hp-dl360-05.rhts.englab.brq.redhat.com:1 HTTP/1.1" 200 12266 "-" "Python-urllib/2.4
"

It doesn't look like the kickstart is getting very far before dying.  Another way to reproduce this is to create a kickstart and then try to use it after about 4 hours.  I spoke with thomas and he said he had tried such a scenario and it worked fine, so I'm going to go ahead and move this back to on_Qa for him.  He said he would open another but for the advanced scheduling kickstart.  I'm also running a test to see what happens with that.

Comment 17 Tomas Lestach 2009-08-13 09:17:30 UTC
I created a new BZ #517252 for the problem described in Comment#10.

I confirm that following scenario works:
1. Create a kickstart
2. Wait at least 4hours.
3. Schedule a kickstart with option "Begin kickstart at the next system check in"

Client will be successfully kickstarted. (Also with a several days old kickstart profile.)

Stage validated -> RELEASE_PENDING
(setting from ON_QA to RELEASE_PENDING, because it was alreday verified by ssalevan)

Comment 18 Brandon Perkins 2009-09-10 19:24:33 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html


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