This content has been marked as final. Show 6 replies
roadgeek wrote:You can create your own. If you have ULN access, use http://www.oracle.com/technetwork/articles/servers-storage-admin/yum-repo-setup-1659167.html otherwise search the forum for Alvaro's script or use something like Spacewalk, Mrepo or Pulp.
Thank you! Are there plans to make more mirrors available as well? I spot checked a few that are listed, but the ones in the US didn't look current.
Is downloading the complete public yum repository via the Internet a good solution? Isn't the Oracle public yum server already slow and won't downloading the whole enchilada make it even worse?
The base repositories can easily be copied from the installation DVD, but the latest repositories are several times larger than the base repositories and contain many packages and versions of packages that most users will not need. Is downloading the complete latest repository a good idea?
During its normal use YUM maintains a local cache of repository metadata. It's the downloading and maintaining of the metadata cache that is the most annoying and causing the unusual delays, in particular with the huge latest repository. It is even necessary when not installing any software and just checking for available packages. I think the default time to live of the local yum cache should be increased. It might make sense to increase the metadataexpire parameter, the default is only 1.5 hours.
Dude wrote:Downloading once a day from a single server is way better than having all your servers update themselves from public-yum.oracle.com, both from your perspective and ours. Also, all the sync scripts work serially, which means they're only downloading a single file at a time. Which is fine. :)
Isn't the Oracle public yum server already slow and won't downloading the whole enchilada make it even worse?
Having a local yum repository also solves the metadata issue as you'd be downloading and running the metadata locally. Also, we store ALL the packages ever released in our _latest channels, which makes the metadata much larger than your mirror needs to be. A local ULN mirror only stores the latest packages by default.
Yes, but isn't that true only after the GB's of data have already been downloaded? How long will the initial creation of the repository take using the public yum server, in particular if the service is already slow and causing timeouts?
What I'm saying is that if there are performance issues with the public yum service than starting to download the complete repository, in particular the _latest repository, is not a good solution. However, I guess you cannot prevent anyone form creating a script or downloading the complete thing.
To increase the metadata_expire parameter might be more efficient in some scenarios.