Thanks for the practical tip.
This is the way to go if you have different machines running the same distro version.
I guess it's faster to make yum retrieve from your intranet the packages already downloaded on one machine...
Any suggestions for automatically moving packs in /var/cache/yum to this kind of personal repo ? apart from a custom shell script run by cron... ?
Discussion on:
View:
Show:
That is the best suggestion. =)
You could always just mirror the upstream repository locally and point all the clients to it. Might not make a lot of sense if you only have a few machines and/or have bandwidth constraints, otherwise that might be more hands-off.
But a custom shellscript is pretty easy... cronjob to download all available yum updates, move them to the repository, run createrepo, then do the yum update (may remove them from the cache otherwise I think, you'd have to check to make sure). I think you could probably do that in 4-5 lines of bash.
You could always just mirror the upstream repository locally and point all the clients to it. Might not make a lot of sense if you only have a few machines and/or have bandwidth constraints, otherwise that might be more hands-off.
But a custom shellscript is pretty easy... cronjob to download all available yum updates, move them to the repository, run createrepo, then do the yum update (may remove them from the cache otherwise I think, you'd have to check to make sure). I think you could probably do that in 4-5 lines of bash.
Even if you have only a few machines, mirroring upstream repositories and building from those locally is worthwhile doing. It's the only way to accurately version control your local system builds and updates. i.e. mirror from upstream to a local repo and freeze. Make a second copy of that repo sometime later and then sync up. Wash rinse repeat. If you just rely on the upstream repositories, then you leave yourself exposed to upstream changes between builds, where a system you build a month from now will very likely have a different mix of package versions than a system you build today. If todays system is your test environment and the next system is production, then the production will be different from test, and your test was a waste of time. So always create your own repos, keep multiple versions and build your systems from them.
If you want to get really flash, and you're prepared to live life on the bleeding edge, try out Spacewalk. You can achieve the same effect by mirroring from upstream and then pushing the mirrored packages into a Spacewalk channel. Each time you reposync, create a new channel (increment its name) and push the updated collection into it. A system can be told which version to use by changing the channel associated with its subscription and then scheduling an update (or running yum).
If you want to get really flash, and you're prepared to live life on the bleeding edge, try out Spacewalk. You can achieve the same effect by mirroring from upstream and then pushing the mirrored packages into a Spacewalk channel. Each time you reposync, create a new channel (increment its name) and push the updated collection into it. A system can be told which version to use by changing the channel associated with its subscription and then scheduling an update (or running yum).
Creating a mirror of a repository is not be best solution for your case.
If all you want is to speed up the repository access (and/or reduce bandwidth usage) then setting up a proxy cache (e.g. squid) on your local network and configuring yum to use it is the bets solution.
This way, only the needed files will be transferred, and only once, even if several systems request the same file.
If all you want is to speed up the repository access (and/or reduce bandwidth usage) then setting up a proxy cache (e.g. squid) on your local network and configuring yum to use it is the bets solution.
This way, only the needed files will be transferred, and only once, even if several systems request the same file.
Actually, it's come to my attention that using "createrepo -d" is better as it also creates the sqlite database which makes stuff faster, so I would change the script noted from saying "createrepo ." to "createpo -d .".
so, where is i386 package? CD-install or /usr/bin/i386?
i don't know steps you do. you can tell clearer for me about it ! thanks you.
and have error:
ftp://internalhost.com/repo/Fedora/10/i386/repodata/repomd.xml: [Errno 4] IOError: [Errno ftp error] timed out
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: myrepo. Please verify its path and try again.
help me!
i don't know steps you do. you can tell clearer for me about it ! thanks you.
and have error:
ftp://internalhost.com/repo/Fedora/10/i386/repodata/repomd.xml: [Errno 4] IOError: [Errno ftp error] timed out
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: myrepo. Please verify its path and try again.
help me!
Creating a local YUM CentOS repository is very easy. If you several servers and workstations in your environment, it's a good practice to create your own local YUM repository. This gives you more configuration control on what goes on your systems. I found the following step-by-step procedure to create a local CentOS YUM repository.
http://www.howtoforge.com/creating_a_local_yum_repository_centos
http://www.howtoforge.com/creating_a_local_yum_repository_centos
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
