Yes they can :)
Indeed, the SFT are using a pre-compiled md5sum files list.
I added a field corresponding to a file version and the ca_*0_28 md5sums
to this file, and tweaked the tests.
They should now behave like this :
- test if the RPM is the latest (defined in a SFT map file) version (now
: 0_28)
- if not, test the file and compare it to the known (accepted) versions,
i.e 0_26 and 0_28 (0_26/0_27 seem to have the same checksums (?) )
I'm currently testing this feature, I'll commit the changes soon if
everything is OK.
Regards
Frederic Schaer
CIC on Duty - France
Oliver KEEBLE a écrit :
> But the situation is now that one certificate file (01621954.0) can have
> one of two valid checksums, depending on version. Can the SFTs can
> handle this case?
>
> Oliver Keeble Information Technology Department
> [log in to unmask] CERN
> +41 22 76 72360 CH-1211 Geneva 23
>
>
> Frederic Schaer wrote:
>
>> Hi,
>>
>> This is because the md5sums used by the SFT haven't been upgraded yet I
>> guess...
>> This will hopefully be done today
>>
>> - Piotr : maybe it would be good to find a way to compile these md5sums
>> on the fly ?
>>
>> Frederic
>>
>> Kyriakos G. Ginis a écrit :
>>
>>> On Fri, Apr 08, 2005 at 08:31:11AM +0200, Ricardo Graciani wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> This morning test reports the following error:
>>>>
>>>> Checking ca_UKeScience RPM: FAILED: rpm is ca_UKeScience-0.28-1,
>>>> checking the file itself (/etc/grid-security/certificates/01621954.0)
>>>> /etc/grid-security/certificates/01621954.0: FAILED
>>>> md5sum: WARNING: 1 of 1 computed checksum did NOT match
>>>>
>>>> I went to the machine where the test run and check with rpm
>>>> content:
>>>>
>>>> Everything looks OK with the files.
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> On HG-01-GRNET we have exatly the same problem.
>>>
>>> --
>>> Kyriakos Ginis, PhD Candidate
>>> Software Engineering Laboratory
>>> National Technical University of Athens
>>>
>>>
>>>
>
|