Description of problem:
When satellite-sync pulls down kickstart trees from hosted, It overrides the
last_modified date to the date it synced the files. This has been the behavior
since long. This becomes a problem with channel dump generation (for incremental
dumps) as the date ranges no longer get validated for kickstart trees and pulls
not a very high priority/blocker IMO, this bug fits well with the Enhancements
we're planning for rhn-sat-exporter tool for 520.
Investigating further, looks like we don't export last_modified from hosted. So
for us to include the right KickstartTree last_modified date field into sat's
rhnKickstartTree table, we need this date to be first exported by hosted
I opened a bug(bz#328271) for hosted to add this to the exporter. Once thats
done, we can grab the last_modified from the xml stream and populate db with
Comment #1 From James Bowes (email@example.com) on 2007-10-17 19:55 EST
Data is sent, but as last-modified rather than last_modified
Looks like even though the data is sent as a different key, looks like the
satsync was never written to handle last_modified dates for kickstart-trees and
hence there seems to be no validation for the last-modified dates verses the the
timestamps. So we pretty much need to rewrite rhnKickstartTreeCollection and
Container classes. I would say we could scope this for next release if we're
short on time.
After discussing with cliff, moving to sat-5.2 ..
Moving to sat-channel-dumps tracker. Agree we should look to address this as part of the feature code changes needed to redo channel dump creation process.
Fixed in Spacewalk master 460aad3e019c6fd064732aed14127d822d62217b.
Taking QA contact for the bug verification.
Verified against: (on rhel-i386-server-5-u4)
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.
Although the errata fixing this particular issue is out, I'd like
to point out two important things:
1) The updated packages won't update last_modified values that already
exist in the database. This means, if the previous satellite-sync
set these values incorrectly, new sync won't update these values. It
will only be able to insert new correct values for newly synchronized
2) Due to bug #576222, even correctly set last_modified values will be
overwritten when taskomatic executes CobblerSyncTask, which modifies
existing rows in rhnKickstartableTree for use with cobbler (disabling
this task may help, as long as cobbler functionality is not required).