[Spacewalk-list] spacewalk-data-fsck file present but listed

[Jan Pazdziora]

On Thu, Jun 30, 2011 at 12:35:44PM -0600, Jason M. Nielsen wrote:
> When I run spacewalk-data-fsck I am seeing a very large number of
> files with the formatted message like that listed below.
> 
> This seems to indicate these files are on the file system and not in
> the database.
> 
> If this was the case then why am I not only able to find said files
> in the GUI and download them manually but also install via yum and
> the gui indicates the same file system path?
> 
> Can someone explain this or is this a bug and I should avoid running
> this command to try and clean things up. It would appear it wants to
> go through and destroy every single rpm across my entire SW
> installation claiming all have a mismatch and so far not a single
> one it listed appears to be in this scenario via the GUI.
> 
> Command line:
> 
> root at leonov:/var/log/rhn/reposync# spacewalk-data-fsck -v
> Checking if packages from database are present on filesystem
> File path mismatch: /var/satellite/redhat/1/b94/NetworkManager/0.7.0-10.el5_5.2/i386/b94963155f4be87ed21337a0a15e9fba/NetworkManager-0.7.0-10.el5_5.2.i386.rpm
> (evr: 1:0.7.0-10.el5_5.2 vs. 0.7.0-10.el5_5.2)
> ...
> 
> In the GUI:
> 
> NAME: NetworkManager-0.7.0-10.el5_5.2.i386.rpm
> 
> FILE SYSTEM PATH: redhat/1/b94/NetworkManager/0.7.0-10.el5_5.2/i386/b94963155f4be87ed21337a0a15e9fba/NetworkManager-0.7.0-10.el5_5.2.i386.rpm

The files are stored on the filesystem, and the paths of the files are
stored in the database. So theoretically, the paths could have any
random form and since the paths would be in the database, Spacewalk
would still be able to find the correct file.

In reality thou we try to keep the paths sane, so they include the
NEVRA and checksum in the directory segment names.

There was a bug in our code which did not put the epoch to the path
(if epoch is not specified in the rpm, it is not put there at all).
We've fixed the bug so newly synced/pushed rpms don't have the problem
but you can still have rpms in Spacewalk that have paths that do not
match this expectation. This does not mean the file won't be found --
if the file is stored in /var/satellite in the location that is stored
in the database, things are sane, they just don't meet some additional
expectation about the format of that path.

We currently don't have any tool to fix this issue -- but it should be
fairly easy to add a recovery step to either spacewalk-data-fsck or
separate script which would rename the file and update the database
(ideally hardlink, commit, remove old file, purge old directory
structure).

I'll be happy to review patches that would implement this.

-- 
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat