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

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

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.

Justin - please can you explain why a 4 hr expire time is a problem? Are kickstarts taking longer than 4 hours to complete? 

Cliff

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.

I swear I *did* this last week and Brandon as my witness! 

Option #2. 

Cliff

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)

Tested and VERIFIED on 5/7 ISO.

Created attachment 357000 [details]
remote console log - failed kickstart

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.)

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 ?

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.

Oh yeah, i missed that last statement, sorry about that tlestach :}

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

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).

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.

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)

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