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

2019-02-19 Thread Florin Portase 
On 2019-02-13 10:56, Florin Portase wrote:

> Hello, 
> 
> I just have upgraded the spacewalk server from 2.7 => 2.9. 
> 
> I have applied also the sql patch from 
> https://bugzilla.redhat.com/show_bug.cgi?id=1661347 
> 
> + upgraded the clients from : 
> 
> http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>  
> 
> 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, here are more info about: 
> 
> Spacewalk server 2.9 (upgraded from 2.7) 
> 
> +spacewalk-add-debian-multiarch-header.py 
> 
> Ubuntu client: 16.04 ( basic install => only ssh server) 
> 
> -here are the list of packages that are installed over and over... 
> 
> The following packages will be upgraded:
> accountsservice amd64-microcode apparmor apport apt base-files bash 
> bash-completion bsdutils ca-certificates cloud-guest-utils console-setup
> console-setup-linux coreutils cryptsetup cryptsetup-bin dh-python 
> distro-info-data dnsmasq-base dpkg friendly-recovery gcc-5-base git git-man 
> grep
> grub-common grub-pc grub2-common ifupdown init init-system-helpers 
> initramfs-tools initramfs-tools-core keyboard-configuration klibc-utils kmod
> language-selector-common libaccountsservice0 libapt-pkg5.0 libasprintf0v5 
> libaudit-common libc6 libdbus-1-3 libglib2.0-0 libgssapi-krb5-2 libk5crypto3
> libkrb5-3 libkrb5support0 liblxc1 libpam-modules libparted2 libperl5.22 
> libplymouth4 libpolkit-backend-1-0 libpolkit-gobject-1-0 libpython2.7-minimal
> libpython2.7-stdlib libpython3.5-stdlib libsasl2-2 libsasl2-modules 
> libsasl2-modules-db libstdc++6 libsystemd0 libx11-data linux-firmware
> linux-headers-4.4.0-116 linux-headers-4.4.0-142 locales login logrotate 
> lsb-base lxc-common lxd lxd-client mdadm mount ntfs-3g open-iscsi 
> open-vm-tools
> openssh-sftp-server perl perl-base perl-modules-5.22 plymouth policykit-1 
> procps python python-apt python-apt-common python-minimal python2.7
> python2.7-minimal python3-apt python3-distupgrade python3-update-manager 
> python3.5-minimal resolvconf rsync snapd software-properties-common systemd
> systemd-sysv tar ubuntu-release-upgrader-core udev update-manager-core 
> update-notifier-common util-linux uuid-runtime vim-common vim-runtime xfsprogs
> zlib1g
> 113 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/145 MB of archives.
> After this operation, 0 B of additional disk space will be used.
> Do you want to continue? [Y/n] n
> Abort. 
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

signature.asc
Description: OpenPGP digital signature
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

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

2019-02-19 Thread Eric Herget 
This sounds like the issue/fix discussed here - 
https://github.com/spacewalkproject/spacewalk/wiki/DebianUbuntuSupportIn27 
- just the client change, you shouldn't need to clean and sync channels 
since you were already running the updated parsing in 2.7.


If you upgraded the clients, possibly this fix got overwritten? I'm not 
familiar with what comes from the debclients url you mentioned - I don't 
know if this fix has been applied.


Eric


On 2/19/19 9:23 AM, Florin Portase wrote:


On 2019-02-13 10:56, Florin Portase wrote:


Hello,

I just have upgraded the spacewalk server from 2.7 => 2.9.

I have applied also the sql patch from 
https://bugzilla.redhat.com/show_bug.cgi?id=1661347


+ upgraded the clients from :

http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/


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, here are more info about:


Spacewalk server 2.9 (upgraded from 2.7)

+|spacewalk-add-debian-multiarch-header.py|

Ubuntu client: 16.04 ( basic install => only ssh server)


-here are the list of packages that are installed over and over...


The following packages will be upgraded:
  accountsservice amd64-microcode apparmor apport apt base-files bash 
bash-completion bsdutils ca-certificates cloud-guest-utils console-setup
  console-setup-linux coreutils cryptsetup cryptsetup-bin dh-python 
distro-info-data dnsmasq-base dpkg friendly-recovery gcc-5-base git 
git-man grep
  grub-common grub-pc grub2-common ifupdown init init-system-helpers 
initramfs-tools initramfs-tools-core keyboard-configuration 
klibc-utils kmod
  language-selector-common libaccountsservice0 libapt-pkg5.0 
libasprintf0v5 libaudit-common libc6 libdbus-1-3 libglib2.0-0 
libgssapi-krb5-2 libk5crypto3
  libkrb5-3 libkrb5support0 liblxc1 libpam-modules libparted2 
libperl5.22 libplymouth4 libpolkit-backend-1-0 libpolkit-gobject-1-0 
libpython2.7-minimal
  libpython2.7-stdlib libpython3.5-stdlib libsasl2-2 libsasl2-modules 
libsasl2-modules-db libstdc++6 libsystemd0 libx11-data linux-firmware
  linux-headers-4.4.0-116 linux-headers-4.4.0-142 locales login 
logrotate lsb-base lxc-common lxd lxd-client mdadm mount ntfs-3g 
open-iscsi open-vm-tools
  openssh-sftp-server perl perl-base perl-modules-5.22 plymouth 
policykit-1 procps python python-apt python-apt-common python-minimal 
python2.7
  python2.7-minimal python3-apt python3-distupgrade 
python3-update-manager python3.5-minimal resolvconf rsync snapd 
software-properties-common systemd
  systemd-sysv tar ubuntu-release-upgrader-core udev 
update-manager-core update-notifier-common util-linux uuid-runtime 
vim-common vim-runtime xfsprogs

  zlib1g
113 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/145 MB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.



___
Spacewalk-list mailing list
Spacewalk-list@redhat.com 
https://www.redhat.com/mailman/listinfo/spacewalk-list




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list



--
Eric Herget | Senior Software Engineer
Red Hat Satellite

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

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

2019-02-22 Thread Florin Portase 
On 2019-02-13 10:56, Florin Portase wrote:

> Hello, 
> 
> I just have upgraded the spacewalk server from 2.7 => 2.9. 
> 
> I have applied also the sql patch from 
> https://bugzilla.redhat.com/show_bug.cgi?id=1661347 
> 
> + upgraded the clients from : 
> 
> http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>  
> 
> 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) 
> 
> ___
> 
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

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
"https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html";


wget  -q
http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
 \
-O /tmp/Packages-xenial-main.gz && gunzip -f
/tmp/Packages-xenial-main.gz
wget  -q
http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
 \
-O /tmp/Packages-xenial-updates.gz  && gunzip -f
/tmp/Packages-xenial-updates.gz
wget  -q
http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
\
-O /tmp/Packages-xenial-security.gz && gunzip -f
/tmp/Packages-xenial-security.gz

s=180
trap 'echo "Ctrl-C detected."' 2
for (( i=$s ; i>0; i--));
do
#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
echo -ne  "\rFinishing sync in: $i seconds\033[0K";
sleep 1
done
echo -e "\nSync completed!"
trap 2
$_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
$_PKG_MAIN/Packages/tmp/Packages-xenial-main
$_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
$_PKG_UPD/Packages  /tmp/Packages-xenial-updates
$_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
$_PKG_SEC/Packages  /tmp/Packages-xenial-security
$_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
$_PKG_UNIV/Packages/tmp/Packages-xenial-universe

/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

cd $_PKG_MAIN
$_BIN_PATH/secureApt.sh  xenial xenial-main
touch -r Packages.gz  Packages
cd $_PKG_UPD
$_BIN_PATH/secureApt.sh  xenial xenial-updates
touch -r Packages.gz  Packages
cd $_PKG_SEC
$_BIN_PATH/secureApt.sh  xenial xenial-security
touch -r Packages.gz  Packages 

So just to resume, SYNC =>OK, applying ALL missing headers =>OK, now the
packages that are showed as up-gradable dropped from ~120 to only 6 (  
base-files libbind9-140 libisc160 libisccc140 libisccfg140 liblwres141 )


~~BUT~~ 

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)

signature.asc
Description: OpenPGP digital signature
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

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

2019-02-22 Thread Robert Paschedag 
Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase 
:
>On 2019-02-13 10:56, Florin Portase wrote:
>
>> Hello, 
>> 
>> I just have upgraded the spacewalk server from 2.7 => 2.9. 
>> 
>> I have applied also the sql patch from
>https://bugzilla.redhat.com/show_bug.cgi?id=1661347 
>> 
>> + upgraded the clients from : 
>> 
>>
>http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>
>> 
>> 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) 
>> 
>> ___
>> 
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>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
>"https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html";
>
>
>wget  -q
>http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
> \
>-O /tmp/Packages-xenial-main.gz && gunzip -f
>/tmp/Packages-xenial-main.gz
>wget  -q
>http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
> \
>-O /tmp/Packages-xenial-updates.gz  && gunzip -f
>/tmp/Packages-xenial-updates.gz
>wget  -q
>http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
>\
>-O /tmp/Packages-xenial-security.gz && gunzip -f
>/tmp/Packages-xenial-security.gz
>
>s=180
>trap 'echo "Ctrl-C detected."' 2
>for (( i=$s ; i>0; i--));
>do
>#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
>echo -ne  "\rFinishing sync in: $i seconds\033[0K";
>sleep 1
>done
>echo -e "\nSync completed!"
>trap 2
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_MAIN/Packages/tmp/Packages-xenial-main
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_UPD/Packages  /tmp/Packages-xenial-updates
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_SEC/Packages  /tmp/Packages-xenial-security
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_UNIV/Packages/tmp/Packages-xenial-universe
>
>/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
>
>cd $_PKG_MAIN
>$_BIN_PATH/secureApt.sh  xenial xenial-main
>touch -r Packages.gz  Packages
>cd $_PKG_UPD
>$_BIN_PATH/secureApt.sh  xenial xenial-updates
>touch -r Packages.gz  Packages
>cd $_PKG_SEC
>$_BIN_PATH/secureApt.sh  xenial xenial-security
>touch -r Packages.gz  Packages 
>
>So just to resume, SYNC =>OK, applying ALL missing headers =>OK, now
>the
>packages that are showed as up-gradable dropped from ~120 to only 6 (  
>base-files libbind9-140 libisc160 libisccc140 libisccfg140 liblwres141
>)
>
>
>~~BUT~~ 
>
>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



-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

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

2019-02-22 Thread Robert Paschedag 
On 2/22/19 7:53 PM, Robert Paschedag wrote:
> Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase 
> :
>> On 2019-02-13 10:56, Florin Portase wrote:
>>
>>> Hello,
>>>
>>> I just have upgraded the spacewalk server from 2.7 => 2.9.
>>>
>>> I have applied also the sql patch from
>> https://bugzilla.redhat.com/show_bug.cgi?id=1661347
>>>
>>> + upgraded the clients from :
>>>
>>>
>> http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>>
>>>
>>> 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)
>>>
>>> ___
>>>
>>> Spacewalk-list mailing list
>>> Spacewalk-list@redhat.com
>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>> 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
>> "https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html";
>>
>>
>> wget  -q
>> http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
>> \
>>-O /tmp/Packages-xenial-main.gz && gunzip -f
>> /tmp/Packages-xenial-main.gz
>> wget  -q
>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
>> \
>>-O /tmp/Packages-xenial-updates.gz  && gunzip -f
>> /tmp/Packages-xenial-updates.gz
>> wget  -q
>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
>> \
>>-O /tmp/Packages-xenial-security.gz && gunzip -f
>> /tmp/Packages-xenial-security.gz
>>
>> s=180
>> trap 'echo "Ctrl-C detected."' 2
>> for (( i=$s ; i>0; i--));
>>do
>>#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
>>echo -ne  "\rFinishing sync in: $i seconds\033[0K";
>> sleep 1
>>done
>> echo -e "\nSync completed!"
>> trap 2
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_MAIN/Packages/tmp/Packages-xenial-main
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_UPD/Packages  /tmp/Packages-xenial-updates
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_SEC/Packages  /tmp/Packages-xenial-security
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_UNIV/Packages/tmp/Packages-xenial-universe
>>

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  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
>>
>> cd $_PKG_MAIN
>>$_BIN_PATH/secureApt.sh  xenial xenial-main
>>touch -r Packages.gz  Packages
>> cd $_PKG_UPD
>>$_BIN_PATH/secureApt.sh  xenial xenial-updates
>>touch -r Packages.gz  Packages
>> cd $_PKG_SEC
>>$_BIN_PATH/secureApt.sh  xenial xenial-security
>>touch -r Packages.gz  Packages
>>
>> So just to resume, SYNC =>OK, applying ALL missing headers =>OK, now
>> the
>> packages that are showed as up-gradable dropped from ~120 to only 6 (
>> base-files libbind9-140 libisc160 libisccc140 libisccfg140 liblwres141
>> )
>>
>>
>> ~~BUT~~
>>
>> 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
>
>
>




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

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

2019-02-22 Thread Robert Paschedag 
On 2/22/19 10:30 PM, Robert Paschedag wrote:
> On 2/22/19 7:53 PM, Robert Paschedag wrote:
>> Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase 
>> :
>>> On 2019-02-13 10:56, Florin Portase wrote:
>>>
 Hello,

 I just have upgraded the spacewalk server from 2.7 => 2.9.

 I have applied also the sql patch from
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1661347

 + upgraded the clients from :


>>> http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>>>

 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)

 ___

 Spacewalk-list mailing list
 Spacewalk-list@redhat.com
 https://www.redhat.com/mailman/listinfo/spacewalk-list
>>>
>>> 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
>>> "https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html";
>>>
>>>
>>> wget  -q
>>> http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
>>> \
>>>-O /tmp/Packages-xenial-main.gz && gunzip -f
>>> /tmp/Packages-xenial-main.gz
>>> wget  -q
>>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
>>> \
>>>-O /tmp/Packages-xenial-updates.gz  && gunzip -f
>>> /tmp/Packages-xenial-updates.gz
>>> wget  -q
>>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
>>> \
>>>-O /tmp/Packages-xenial-security.gz && gunzip -f
>>> /tmp/Packages-xenial-security.gz
>>>
>>> s=180
>>> trap 'echo "Ctrl-C detected."' 2
>>> for (( i=$s ; i>0; i--));
>>>do
>>>#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
>>>echo -ne  "\rFinishing sync in: $i seconds\033[0K";
>>> sleep 1
>>>done
>>> echo -e "\nSync completed!"
>>> trap 2
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_MAIN/Packages/tmp/Packages-xenial-main
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_UPD/Packages  /tmp/Packages-xenial-updates
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_SEC/Packages  /tmp/Packages-xenial-security
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_UNIV/Packages/tmp/Packages-xenial-universe
>>>
>
> 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  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
>

OopsI was wrong. The modified time of "Packages.gz" is the one you
need to preserve

See this function, which checks, if the files has to be regenerated.

...
public boolean isChannelRepodataStale(Channel channel) {
File theFile = new File(mountPoint + File.separator + pathPrefix +
File.separator + channel.getLabel() + File.separator +
"Packages.gz");
// Init Date objects without milliseconds
Calendar cal = Calendar.getInstance();
cal.setTime(new Date(theFile.lastModified()));
cal.set(Calendar.MILLISECOND, 0);
Date fileModifiedDate = cal.getTime();
cal.setTime(channel.getLastModified());
cal.set(Calendar.MILLISECOND, 0);
Date channelModifiedDate = cal.getTime();

// the file Modified date should be getting set when the file
// is moved into the correct location.
log.info("File Modified Date:" + LocalizationService.getInstance().
formatCustomDate(fileModifiedDate));
log.info("Channel Modified Date:" +
LocalizationService.getInstance().
formatCustomDate(channelModifiedDate));
return !fileModifiedDate.equals(channelModifiedDate);
}

...

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
>>>

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

2019-02-26 Thread Florin Portase 
On 2019-02-22 22:30, Robert Paschedag wrote:

> On 2/22/19 7:53 PM, Robert Paschedag wrote: Am 22. Februar 2019 13:11:00 MEZ 
> schrieb Florin Portase : On 2019-02-13 10:56, 
> Florin Portase wrote:
> 
> Hello,
> 
> I just have upgraded the spacewalk server from 2.7 => 2.9.
> 
> I have applied also the sql patch from 
> https://bugzilla.redhat.com/show_bug.cgi?id=1661347 
> + upgraded the clients from :
> 
> http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
> 
> 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) 
> ___
> 
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list 
> 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
> "https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html";
> 
> wget  -q
> http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
> \
> -O /tmp/Packages-xenial-main.gz && gunzip -f
> /tmp/Packages-xenial-main.gz
> wget  -q
> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
> \
> -O /tmp/Packages-xenial-updates.gz  && gunzip -f
> /tmp/Packages-xenial-updates.gz
> wget  -q
> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
> \
> -O /tmp/Packages-xenial-security.gz && gunzip -f
> /tmp/Packages-xenial-security.gz
> 
> s=180
> trap 'echo "Ctrl-C detected."' 2
> for (( i=$s ; i>0; i--));
> do
> #printf '\rFinishing sync in: %2d seconds' $i; sleep 1
> echo -ne  "\rFinishing sync in: $i seconds\033[0K";
> sleep 1
> done
> echo -e "\nSync completed!"
> trap 2
> $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
> $_PKG_MAIN/Packages/tmp/Packages-xenial-main
> $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
> $_PKG_UPD/Packages  /tmp/Packages-xenial-updates
> $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
> $_PKG_SEC/Packages  /tmp/Packages-xenial-security
> $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
> $_PKG_UNIV/Packages/tmp/Packages-xenial-universe

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  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
>> 
>> cd $_PKG_MAIN
>> $_BIN_PATH/secureApt.sh  xenial xenial-main
>> touch -r Packages.gz  Packages
>> cd $_PKG_UPD
>> $_BIN_PATH/secureApt.sh  xenial xenial-updates
>> touch -r Packages.gz  Packages
>> cd $_PKG_SEC
>> $_BIN_PATH/secureApt.sh  xenial xenial-security
>> touch -r Packages.gz  Packages
>> 
>> So just to resume, SYNC =>OK, applying ALL missing headers =>OK, now
>> the
>> packages that are showed as up-gradable dropped from ~120 to only 6 (
>> base-files libbind9-140 libisc160 libisccc140 libisccfg140 liblwres141
>> )
>> 
>> ~~BUT~~
>> 
>> 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

Hi Rober, 

So far so good, 

here is the modified part of sync script: 

cd $_PKG_MAIN
touch -r Packages.gz Packages.new && mv Packages.new Packages
gzip < $_PKG_MAIN/Packages > $_PKG_MAIN/Packages.gz
touch -r Packages Packages.gz
$_BIN_PATH/secureAptDeb.sh stretch stretch-main
cd $_PKG_UPD
touch -r Packages.gz Packages.new  && mv Packages.new Packages
gzip < $_PKG_UPD/Packages  > $_PKG_UPD/Packages.gz
touch -r Packages Packages.gz
$_BIN_PATH/secureAptDeb.sh stretch stretch-updates
cd $_PKG_SEC
touch -r Packages.gz Packages.new && mv Packages.new Packages

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

2019-02-26 Thread philippe bidault 
Hi Florin,

Not sure if this is your case, but I did had this same issue by installing
the rhn packages from this Opensuse repository :
http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/

I did create this ticket :
https://bugzilla.opensuse.org/show_bug.cgi?id=1123726

hoping that this could be checked, but no reply so far, not sure if this is
because I did not create the ticket in the correct place.

Anyway, I am now installing the rhn packages directly from the official
debian and Ubuntu repositories, and no more issue anymore.

Exemple for Debian 9:
wget
http://ftp.de.debian.org/debian/pool/main/r/rhnsd/rhnsd_5.0.4-3+b1_amd64.deb
wget
http://ftp.de.debian.org/debian/pool/main/r/rhn-client-tools/rhn-client-tools_2.3.5-1_amd64.deb
wget
http://ftp.de.debian.org/debian/pool/main/a/apt-spacewalk/apt-transport-spacewalk_1.0.6-4.1_all.deb

Regards,
Philippe.

On Tue, 26 Feb 2019 at 15:06, Florin Portase 
wrote:

> On 2019-02-22 22:30, Robert Paschedag wrote:
>
> On 2/22/19 7:53 PM, Robert Paschedag wrote:
>
> Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase <
> portase.flo...@medianetork.ro>:
>
> On 2019-02-13 10:56, Florin Portase wrote:
>
> Hello,
>
> I just have upgraded the spacewalk server from 2.7 => 2.9.
>
> I have applied also the sql patch from
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1661347
>
>
> + upgraded the clients from :
>
>
>
> http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>
>
> 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)
>
>
> ___
>
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
> 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
> "
> https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html
> "
>
>
> wget  -q
>
> http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
> \
>-O /tmp/Packages-xenial-main.gz && gunzip -f
> /tmp/Packages-xenial-main.gz
> wget  -q
>
> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
> \
>-O /tmp/Packages-xenial-updates.gz  && gunzip -f
> /tmp/Packages-xenial-updates.gz
> wget  -q
>
> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
> \
>-O /tmp/Packages-xenial-security.gz && gunzip -f
> /tmp/Packages-xenial-security.gz
>
> s=180
> trap 'echo "Ctrl-C detected."' 2
> for (( i=$s ; i>0; i--));
>do
>#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
>echo -ne  "\rFinishing sync in: $i seconds\033[0K";
> sleep 1
>done
> echo -e "\nSync completed!"
> trap 2
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
> $_PKG_MAIN/Packages/tmp/Packages-xenial-main
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
> $_PKG_UPD/Packages  /tmp/Packages-xenial-updates
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
> $_PKG_SEC/Packages  /tmp/Packages-xenial-security
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
> $_PKG_UNIV/Packages/tmp/Packages-xenial-universe
>
>
> 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  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
>
> cd $_PKG_MAIN
>$_BIN_PATH/secureApt.sh  xenial xenial-main
>touch -r Packages.gz  Packages
> cd $_PKG_UPD
>$_BIN_PATH/secureApt.sh  xenial xenial-updates
>touch -r Packages.gz  Packages
> cd $_PKG_SEC
>$_BIN_PATH/secureApt.sh

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

2019-03-05 Thread Paul-Andre Panon 
On Tue, 26 Feb 2019 15:05:54 +0100, Florin Portase
 wrote:
>
>On 2019-02-22 22:30, Robert Paschedag wrote:
>
> Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase
: 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  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

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list