클라이언트가 RHEL Satellite Server 5.5(EOL 방식)에 멈춰 있고 EPEL을 하위 채널로 실행하고 있습니다. 오랫동안 업데이트하지 않았습니다. 기타 변수, Python 2.6, Redhat 6.9
그러나 EPEL 저장소(spacewalk-repo-sync)를 업데이트하려고 하면 결국 gzip 오류로 인해 실패합니다(파일이 gzip 압축 파일이 아님). epel의 매니페스트는 bz2(updateinfo.xml.bz2)입니다. (파일 이름을 덤프하기 위해 gzip.py의 오류 처리기를 편집했습니다.)
Google에서 이에 대한 참조를 보았지만 깨끗한 솔루션이나 해결 방법은 없습니다. (위성 업그레이드 외에는 현재 옵션이 아닙니다.)
어떤 아이디어가 있나요? gzip을 사용하는 다른 저장소일까요? 여기에 조금 갇혀 있으면 근시안적이라도 놀라지 않을 것입니다.
IUS 및 Redhats 표준 채널과 잘 작동합니다.
감사해요.
답변1
EPEL 저장소에는 일부 압축된 XML 파일이 포함되어 있습니다. 당신들의 노후화되고 지친 위성 버전은 그러한 현대적 복잡성을 이해할 수 없습니다.
알려진 버그. 바라보다버그 970315 - RFE: spacewalk-repo-sync는 bz2 압축 xml 파일이 포함된 yum 저장소를 지원하지 않습니다.
Bugzilla의 동료가 언급한 것처럼 수정 사항을 Satellite 인스턴스로 백포트해 보십시오. 이것은4년 전에 제출됨, 변형하기 쉬워 보입니다.
답변2
저는 약 700개의 가상 머신으로 구성된 RHEL6 환경에서 spacewalk 2.2를 실행하고 있습니다. 수정해야 해요아메드 사지드nightly_sync는 EPEL을 포함하여 필요한 저장소에 사용됩니다. 내 버전을 사용할 수 있습니다.여기.
모든 저장소를 Spacewalk 서버에 로컬로 다운로드하고 Apache를 통해 Spacewalk 저장소를 공용 디렉터리로 지정했습니다. reposync가 완료되면 spacewalk가 형식을 인식할 수 있도록 필요에 따라 EPEL의 updateinfo.xml을 처리할 수 있습니다.
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
그런 다음 필요한 채널에서 spacewalk-repo-sync를 실행합니다(하나만 있습니다).
(지금은) 더럽지만 작동합니다. 매일 밤 오전 1시쯤 실행되도록 crontab에 설정했습니다. 모든 저장소를 포함하면 초기 동기화에 시간이 걸릴 수 있습니다. 필요한 경우 EPEL만 처리하도록 이를 줄일 수 있습니다.