Bug 489736 - Generated Wizard kickstarts use expiring package urls
Generated Wizard kickstarts use expiring package urls
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Provisioning (Show other bugs)
530
All Linux
low Severity medium
: ---
: ---
Assigned To: Justin Sherrill
Steve Salevan
: Reopened
Depends On:
Blocks: 457075
  Show dependency treegraph
 
Reported: 2009-03-11 11:54 EDT by Justin Sherrill
Modified: 2009-09-10 15:24 EDT (History)
3 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 15:24:33 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)
remote console log - failed kickstart (12.31 KB, text/x-log)
2009-08-11 04:31 EDT, Tomas Lestach
no flags Details

  None (edit)
Description Justin Sherrill 2009-03-11 11:54:36 EDT
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 11:45:55 EDT
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 12:10:25 EDT
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 12:11:24 EDT
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 10:53:01 EDT
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 10:56:35 EDT
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 14:35:47 EDT
I swear I *did* this last week and Brandon as my witness! 

Option #2. 

Cliff
Comment 7 Justin Sherrill 2009-03-26 14:59:18 EDT
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 18:06:20 EDT
Tested and VERIFIED on 5/7 ISO.
Comment 9 Tomas Lestach 2009-08-11 04:31:08 EDT
Created attachment 357000 [details]
remote console log - failed kickstart
Comment 10 Tomas Lestach 2009-08-11 04:32:39 EDT
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 09:13:27 EDT
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 09:31:01 EDT
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 09:51:54 EDT
Oh yeah, i missed that last statement, sorry about that tlestach :}
Comment 14 Clifford Perry 2009-08-11 10:43:14 EDT
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 10:45:24 EDT
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 16:09:24 EDT
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 05:17:30 EDT
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 15:24:33 EDT
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.