Created attachment 421369 [details] chat log between me and jsherrill Description of problem: Spacewalk 1.0 pushes out configuration files on system registration even when the "Configuration File Deployment:" checkbox is unchecked for the activation key. In v0.6 this worked as advertised (didn't push out configuration files), but with 1.0 this checkbox seems to have no effect since the configuration files from the activation key associated configuration channel get scheduled to be deployed to the newly registered machine and are picked up by the client. Version-Release number of selected component (if applicable): 1.0 How reproducible: always Steps to Reproduce: 1. Make a configuration channel 2. Make an activation key and associate the configuration channel with the key, but make sure "Configuration File Deployment:" is unchecked for the activation key. 3. Make a kickstart profile and associate the activation key with the kickstart profile. 4. Make sure you have configuration file management checked for the kickstart profile. 5. Grab the %post section of the kickstart file and put it into a shell script and run it with root privileges on the machine you want to register Actual results: Machine is registered, spacewalk immediately schedules a configuration file deployment, and the client picks up the configuration files from the configuration channel associated with the key with which the machine registered. Expected results: Machine should get registered and associated with the configuration channel but it shouldn't get the configuration files pushed to it. This is the behavior I saw in RHN 4.2something when we used to use it through our university and spacewalk 0.6 . Additional info: jsherrill mentioned that turning off the configuration file management option in the kickstart profile might actually fix this logic within spacewalk but it did not. Current workaround: 1) Deassociate the configuration channel from the activation key 2) Register the system and as many systems as needed. With no configuration channel paired with the activation key no configuration files are automatically deployed. 3) Manually add the configuration channel to the set of hosts you just registered so that they can be part of the channel and so that the other files can be deployed to these hosts in the future as needed. Of course if a bare metal kickstart is needed then the configuration channel should be associated with the key.
Mass-moving to space13.
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.
Aligning under space16.
I confirm that the problem is still present on Spacewalk nightly (1.6).
I confirm that the checkbox affects the behaviour of plain rhnreg_ks --activationkey=1-test-1 --force correctly -- if it is checked, the events Deploy config files to system Completed Deploy config files to system scheduled by (none) 09/19/11 3:24:12 AM EDT System Event Completed Schedule a config deploy for activation key scheduled by (none) 09/19/11 3:24:11 AM EDT Package Install Completed Package Install scheduled by (none) 09/19/11 3:24:10 AM EDT System Event (n/a) Subscription via Token 09/19/11 3:23:51 AM EDT are scheduled and executed, if it is unchecked, just Package Install Completed Package Install scheduled by (none) 09/19/11 3:22:16 AM EDT System Event (n/a) Subscription via Token 09/19/11 3:21:59 AM EDT are done. So the problem is indeed kickstart specific.
*** Bug 630938 has been marked as a duplicate of this bug. ***
I initially suspected that the change in behaviour was somehow caused by change done for bug 557581. However, I don't see where it could have been caused at all because commit fa77ce8f3e7badc2c5a445819c4a36aa281f8741 changed server_token.py, while upon kickstart, the execution path goes via server_kickstart.py and action/kickstart.py, not touching the server_token.py at all. The decision to deploy or not deploy the config files (via the configfiles.deploy action) is done based on the deploy_configs column returned by get_kickstart_session_info which just selects rhnKickstartSession.deploy_configs. And the same code was there in 0.6 as well.
Addressed in Spacewalk master, 0e4e633f225466f45cb48d2d6db3458c135d1c76 and 197126b6b6aaeac65c51253523a5180d08361e9d.
Spacewalk 1.6 has been released.