
내 로컬 네트워크에 Fedora 패키지용 RPM 저장소를 생성하고 싶습니다. 저장소 제한으로 인해 처음에는 저장소를 비우고 패키지에 액세스한 후 패키지를 다운로드하고 싶습니다.
배경
저는 로컬 VM을 사용하여 작업을 많이 합니다. 새 VM을 생성하고 Fedora를 설치할 때마다 인터넷에서 많은 패키지가 다운로드되며 다운로드된 패키지의 대부분은 동일합니다. 프로세스 속도를 높이기 위해 동일한 네트워크에 있는 서버에 RPM을 캐시하고 싶습니다.
createrepo
비슷한 질문에 & 조합으로 답변했습니다 reposync
. reposync
패키지 중 일부만 필요할 때 전체 저장소를 미리 복제하고 싶지 않기 때문에 그 부분이 마음에 들지 않습니다 .
이상적인 솔루션
내 로컬 네트워크의 서버가 Fedora 설치를 위한 RPM 저장소 역할을 하도록 하고 싶습니다. NET에 구성된 모든 메타데이터를 통과해야 합니다 /etc/yum.repo.d/*
. 서버는 요청된 RPM이 로컬 캐시에 있는 경우 해당 RPM을 전달해야 하며 그렇지 않은 경우 이를 다운로드하여 전달해야 합니다.
https://mirrors.fedoraproject.org/...
덜 야심찬 접근 방식은 http 프록시 대신 단일 RPM 저장소를 구성하고 사용하는 것입니다 .
업데이트: 2015년 11월 2일
나는 이미 네트워크에서 nginx를 실행하고 있으므로 proxy_pass
및 proxy_cache
. 그것은 효과가 있지만 IMHO에는 이점보다 단점이 더 많습니다.
- NET에 구성된 모든 저장소에 대해 별도의 구성입니다
/etc/yum.repo.d/*
. - 대체 미러로 인해
metadata
에서 사용할 수 없습니다 .https://mirrors.fedoraproject.org/
squid
의견에서 제안한 대로 nginx를 삭제하고 설치했습니다 . squid
나에게 잘 작동합니다. 이 store_id_program
구성을 사용하면 RPM이 원래 어디에서 왔는지에 관계없이 대체 미러를 사용하고 여전히 캐시에 적중할 수도 있습니다.
답변1
여기에서 rpm 캐싱을 위해 미세 조정된 squid.conf를 찾을 수 있습니다:
https://github.com/spacewalkproject/spacewalk/blob/master/proxy/installer/squid.conf
메모리와 포트 설정만 수정하면 됩니다.
답변2
이에 대한 좋은 해결책을 찾으셨는지 모르겠지만 저는 결국 빠르고 작은 Go 프로그램을 작성하게 되었습니다. 캐싱 프록시 역할을 하며 RPM을 유지하지만 데이터베이스 파일의 업스트림을 프록시하므로 항상 정확합니다. 현재는 CentOS, Fedora EPEL 및 Arch Linux용으로 구성되어 있습니다.
당신은 그것을 볼 수 있습니다https://github.com/yobert/remirror
답변3
apt-cacher-ng
훌륭하게 작동합니다. 우리는 그것을 한동안 사용하고 있는데 잘 작동합니다. 그리고 더 효율적으로 사용하려면 https 미러가 아닌 http 미러만 사용해야 한다는 점을 기억하세요(당연히 https 트래픽은 볼 수 없고 캐시할 수 없습니다).
&protocol=http
http 미러만 사용하도록 페도라 공식 저장소를 구성하려면 구성 URL 끝에 추가할 수 있습니다 metalink
. 예를 들어 fedora
저장소의 경우 다음과 같습니다:
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch&protocol=http
https://www.unix-ag.uni-kl.de/~bloch/acng/
캐싱 프록시. 주로 Debian(및 Debian 기반) 배포판을 위한 Linux 배포자의 패키지 파일에 특화되어 있지만 이에 국한되지는 않습니다. 무엇이 좋은지 알아보려면 Apt-Cacher 문서를 참조하세요.
답변4
Yum Wiki에는 다음이 포함된 페이지가 포함되어 있습니다.캐싱 솔루션 검토
주제 중 일부:
-
Pros Zero configuration, on the client side. Post setup it mostly just works and everything should be immediate. Only downloads what is required by the users. Fully automated server side, once setup/working. Cons Requires setting up a local Squid + Apache-httpd + IntelligentMirror to serve the data. If the server is down then metalinks/MM will route you to an external mirror. Only intelligently caches packages, not metadata.
(베타) avahi-packages-server.py 및 yum avahi 지원(참조:http://james.fedorapeople.org/yum/avahi)
Pros Zero configuration client. Zero configuration server. Only downloads what is required by the users. Cons Not upstream yet (still beta). A client that doesn't run the avahi server side doesn't share it's downloads (so all clients need to run the "server"). Requires working avahi on the network.