[Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients
philippe bidault
philippe.bidault at gmail.com
Tue Feb 26 14:36:42 UTC 2019
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 <portase.florin at medianetork.ro>
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.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.
>
> 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 at 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 <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
>
> 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
> gzip < $_PKG_SEC/Packages > $_PKG_SEC/Packages.gz
> touch -r Packages Packages.gz
> $_BIN_PATH/secureAptDeb.sh stretch stretch-security
> cd $_PKG_UNIV
> touch -r Packages.gz Packages.new && mv Packages.new Packages
> gzip < $_PKG_SEC/Packages > $_PKG_SEC/Packages.gz
>
> touch -r Packages Packages.gz
> $_BIN_PATH/secureAptDeb.sh stretch stretch-universe
>
>
> After this, taskomatic wasn't triggered BUT::
>
> ON client side: => apt-get update && apt-get upgrade => taskomatic is
> triggered and Pakages && Packages.gz are regenerated :(
>
>
>
> ing ehcache from ehcache-failsafe.xml found in the classpath:
> jar:file:/usr/share/java/ehcache-core.jar!/ehcache-failsafe.xml
> INFO | jvm 1 | 2019/02/26 14:58:00 | 2019-02-26 14:58:00,038
> [DefaultQuartzScheduler_Worker-2] INFO
> com.redhat.rhn.taskomatic.task.ChannelRepodata - In the queue: 3
> INFO | jvm 1 | 2019/02/26 14:58:00 | 2019-02-26 14:58:00,188 [Thread-561]
> INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - File Modified
> Date:2019-02-26 04:42:14 CET
> INFO | jvm 1 | 2019/02/26 14:58:00 | 2019-02-26 14:58:00,188 [Thread-560]
> INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - File Modified
> Date:2019-02-26 04:40:05 CET
> INFO | jvm 1 | 2019/02/26 14:58:00 | 2019-02-26 14:58:00,188 [Thread-561]
> INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - Channel
> Modified Date:2019-02-24 17:58:28 CET
> INFO | jvm 1 | 2019/02/26 14:58:00 | 2019-02-26 14:58:00,188 [Thread-560]
> INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - Channel
> Modified Date:2019-02-26 14:29:17 CET
> INFO | jvm 1 | 2019/02/26 14:58:00 | 2019-02-26 14:58:00,238 [Thread-561]
> INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - Generating
> new DEB repository for channel stretch-main
> INFO | jvm 1 | 2019/02/26 14:58:00 | 2019-02-26 14:58:00,247 [Thread-560]
> INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - Generating
> new DEB repository for channel stretch-updates
> INFO | jvm 1 | 2019/02/26 14:58:06 | 2019-02-26 14:58:05,957 [Thread-560]
> INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - Repository
> metadata generation for 'stretch-updates' finished in 5 seconds
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20190226/0a379386/attachment.htm>
More information about the Spacewalk-list
mailing list