1

Client is stuck on RHEL Satellite Server 5.5 (Way EOL) and runs EPEL as a child channel. Long not updated. Other variables, Python 2.6, Redhat 6.9

But when trying to update the EPEL repo (spacewalk-repo-sync) it fails at the end with a gzip error (file not a gzipped file) The manifest for epel is bz2 (updateinfo.xml.bz2). (I edited the error handler in gzip.py to dump the file name).

See references to it googling, but no clean solution or work around. (beside upgrading Satellite which is not an option right now).

Any thoughts? A different repo that uses gzip perhaps? Just a little stuck here and wouldn't be surprised if I was being myopic.

Works fine with IUS and Redhats standard channels.

Thanks.

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
IGotAHeadache
  • 13
  • 5

2 Answers2

2

EPEL repo contains some compressed xml files. Your aging and weary version of Satellite doesn't understand such modern complexities.

Known bug. See Bug 970315 - RFE: spacewalk-repo-sync does not support yum repos containing bz2 compressed xml files

Try backporting the fix to your instance of Satellite like the colleague referenced in the bugzilla did ? Here's the commit, from 4 years ago, looks pretty easy to retrofit.

steve
  • 21,582
  • 5
  • 48
  • 75
  • 1
    I was looking for something like that (found similiar) looking for the entry point to edit a file in the right place. I'll see if I can find the commit and see if it differs dramatically from 1.75. – IGotAHeadache Aug 10 '17 at 13:41
  • 1
    voted this up, but not enough rep for it to show. – IGotAHeadache Aug 10 '17 at 13:42
  • 1
    I will add the following detail. I have spacewalk 1.75 and only needed to backport the changes in fileutils.py and yum_src.py. A reading of these files and reposync.py seemed to show that 1.75 reposync.py was agnostic as far as filenames and types and the bug was tied only to these two files. Reposync in the commit above and my copy are very divergent. Maybe something changed later on and needed more. But it updated epel without issue after fixing those two files and updated the errata. Also, line numbers are not exact as the commit is against a different file base. – IGotAHeadache Aug 10 '17 at 17:33
2

I run spacewalk 2.2 in a RHEL6 environment consisting of ~700 vms. I needed to modify ahmedsajid's nightly_sync to work for the repos I needed, including EPEL. My version is available here.

I am downloading all repos locally to my Spacewalk server and pointing the Spacewalk repo to a public directory via Apache. Once reposync is complete, I can handle EPEL's updateinfo.xml as needed so that spacewalk recognizes the format:

set -o pipefail
if ls $REPO_DIR/$REPO/*updateinfo.xml.gz 2>/dev/null | tail -n 1 ; then
  echo "updateinfo.xml.gz found"
  gunzip -c $(ls -rt $REPO_DIR/$REPO/*updateinfo.xml.gz | tail -n 1) > $REPO_DIR/$REPO/updateinfo.xml
else
  echo "updateinfo.xml.gz not found"
  file=$(curl -s https://dl.fedoraproject.org/pub/epel/6Server/x86_64/repodata/ | grep "updateinfo.xml.bz2" | cut -d'"' -f6)
  echo "Downloading EPEL $file"
  wget -q -P $REPO_DIR/$REPO/ https://dl.fedoraproject.org/pub/epel/6Server/x86_64/repodata/$file
  bunzip2 -c $(ls -rt $REPO_DIR/$REPO/*updateinfo.xml.bz2 | tail -n 1) > $REPO_DIR/$REPO/updateinfo.xml
fi

After that, I run spacewalk-repo-sync on the channels I need (only one for me).

It's dirty (right now), but it works. I set this in crontab to run each night around 1 am. The intial sync may take a while if you include all of your repos. You could shave this down to handle only EPEL, if necessary.

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
RickMulder
  • 21
  • 3