[Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

[Paul-Andre Panon]

On Tue, 26 Feb 2019 15:05:54 +0100, Florin Portase
<portase.florin at medianetork.ro> wrote:
>
>On 2019-02-22 22:30, Robert Paschedag wrote:
>
> Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase
<portase.florin at medianetork.ro>: On 2019-02-13 10:56, Florin Portase
wrote:
>>
>> Hello,
>>
>> I just have upgraded the spacewalk server from 2.7 => 2.9.
>>
>> Just to mention spacewalk 2.7 +  patches was working just fine for both
debian & ubuntu.
>> Now, for ubuntu 16.05 I have over 100 packages marked as up-gradable(
>> over and over.
>> ...
>> So, after digging through  SPW archive Dec '18 til Feb '19 finally I
>> come to something more acceptable:
>>
>> 1. sync script for Ubuntu channels
>>
>> 2. "spacewalk-add-debian-multiarch-header.py.NEW " took it from
>>...
>Below is your error
>
>Packages.new is the "modified" Packages which you rename and
>*afterwards* use its "modified" timestamp. This is wrong.
>
>You have to use the "modified" timestamp of the "original" (the one
generated by Spacewalk) packages file
>
>So when you have the original "Packages" file (by spacewalk), do
>
>- run the <add_header> script (which generates "Packages.new")
>- gzip -c Packages.new > Packages.gz
>- touch -r Packages Packages.new Packages.gz && mv Packages.new Packages
>
>So you have transferred the original timestamp to the new files and all
set to "secure" your repo then.
>
>Robert
>
>>> /bin/mv $_PKG_MAIN/Packages.new $_PKG_MAIN/Packages /bin/mv
>>> $_PKG_SEC/Packages.new $_PKG_SEC/Packages /bin/mv
>>> $_PKG_UPD/Packages.new $_PKG_UPD/Packages /bin/mv
>>> $_PKG_UNIV/Packages.new $_PKG_UNIV/Packages
>>>
>>> gzip < $_PKG_MAIN/Packages > $_PKG_MAIN/Packages.gz gzip <
>>> $_PKG_UPD/Packages  > $_PKG_UPD/Packages.gz gzip < $_PKG_SEC/Packages

>>> > $_PKG_SEC/Packages.gz gzip < $_PKG_UNIV/Packages >
>>> $_PKG_UNIV/Packages.gz
>>>
>>> Here I run into another problem, it seems taskomatic is generating
>>> Package files over and over ( touch -r Packages.gz  Packages seems to
>>> have no effect)
>>
>> This seems to be new. You might have to check within code, at which
>> conditions a rebuild of the Packages file gets triggered
>>
>> I'm still on SW2.7 so I cannot test on my environment.
>>
>> Robert
>
BTW, I was having a similar issue with automated (Taskomatic?)
regeneration of the package files,
wiping out the customized package files on my xenial and bionic channels
that had been rebuilt
to include the additional (DEP11?) metadata headers such as MultiArch:.
The timestamps were being
re-assigned correctly however, so I couldn't figure out why until some
time after I read Robert's
e-mail above. It turns out that, for Ubuntu 16 and 18, I was using the
SecureApt.sh
script to build the signed Release and InRelease files for those channels
and repos. Since those
aren't part of the standard channel cache files automatically-generated by
Spacewalk, I thought
it would be OK. Nope. I since modified the SecureApt.sh to modify the
timestamp on the signed
Release files to match the Package timestamp and that seems to have fixed
the problem, although
I won't really know for sure until another week.

Cheers,

Paul-Andre