[Spacewalk-list] Snapshot Rollback always redeploys all configuration files

[Jason M. Nielsen]

I attempted this in on RHEL5 and 6. 6 just blew up and Im looking into 
why now. RHEL5 worked but re/deployed when it appears it should not 
have. It also appears to have wanted to modify the group membership 
which also never changed though I cant confirm this.

Please let me know once you have the file so I can remove it. Thanks!
http://www.myriad.com/rollback_rhn_check_output.tar.gz

Process
========
RHEL5:
*yum install psutils
*yum install a2ps
*Attempted to rollback to the psutils only install.
*At no point was anything done regarding config files spacewalk side.

RHEL6:
*yum install psutils
*yum install bsf
*Attempted to rollback to the psutils only install.
*At no point was anything done regarding config files spacewalk side.

Results
========
rhel6_rollback.txt: Contains rhn_check output for a RHEL6 system.
*This crashed and I have no clue why as I dont know what an "oracle" 
user has to do with this system in any form nor fashion. It does not 
exist, never has existed and does spacewalk even deal with system user 
accounts? This one totally confuses me too.

rhel5_rollback.txt: Contains rhn_check output for a RHEL5 system.
*The rollback succeeded but it did indeed do the following:
1)Deployed all files from all subscribed channels.
2)Deployed files from subscribed channels which were never deployed to 
this server.
3)Deployed files that had been changed locally on the server but not via 
spacewalk meaning it should have at most realized they changed but it 
was never part of a spacewalk even so there should have been no rollback 
of said file(s).

rhel5_before_rollback.jpg
*Configuration comparison via spacewalk gui screen shot of the RHEL5 
system before rollback.

rhel5_after_rollback.jpg
*Configuration comparison via spacewalk gui screen shot of the RHEL5 
system after rollback.


Specific examples of what happens:
/etc/logrotate.d/console
*Never existed on this system yet it deployed.

/etc/rc3.d/S98myriadfirstboot
*Is deployed during server creation but destroys itself on the first 
boot. It was redeployed even though it was part of no scheduled action. 
Suppose this might be a legitimate action though since it sees its 
missing. Seems odd to me that since its removal is not a spacewalk event 
why it would decide to redeploy when not told to do so.

/etc/cron.d/spacewalk_rhncheck
I commented out the first cron job in this file and it was redeployed 
with the non-comment one. Again, I never changed it via spacewalk (vi 
locally only) and it was redeployed. Spacewalk at most would know its 
different but its not part of a rollback as the file prior to 
this(S98myriadfirstboot).

/etc/resolv.conf
*Tossed in "#test" at the bottom of the file. It was redeployed and 
comment lost. Again this was edited locally and not via spacewalk and it 
should have not rolled back as there was nothing to "rollback" to.


On 12/12/2011 06:02 AM, Jan Pazdziora wrote:
> On Wed, Nov 30, 2011 at 01:17:37PM -0700, Jason M. Nielsen wrote:
>> SW 1.6 on RHEL 5.7.
>>
>> Update a single RPM.
>>
>> Check provisioning and snapshots and note the one available that has
>> that single package to rollback.
>>
>> Notice it claims there are changes to be rolled back on:
>> "System Group Membership"
>> "Configuration Files"
>>
>> If you rollback it appears to actually perform this. ie: Files that
>> were never deployed to server get deployed.
>>
>> None of these happened. Even checks of the files manually shows the
>> checksums are the same and the contents are the same visually.
>> Additionally they were neither changed nor redeployed. Actually some
>> were never even deployed to this server.
>>
>> Even stranger, if I visit the lastest snapshot which should be the
>> "current state" it still shows all of these same "System Group
>> Membership" and "Configuration Files" as having rollbacks.
>>
>> Anyone else seen this issue? Configuration setting on my end? Bug?
>> This is not how it should be working is it? Kind of at a loss here.
>
> Please show us the output of rhn_check -vv run on the client after the
> events were scheduled.
>