[SLE] A dynamic updates/supplementary server?
I would appreciate a pointer if this is possible and the document exists already. I have three systems (Desktop on 10.0, HTPC on 9.3, and Laptop on 10.1) Once some of the wrinkles are out of 10.1, I intend updating all systems to 10.1. As I understand things, this means that I'll either download each patch 3 times, or I have to make a local sync of a very large portion of the updates and supplementary trees. What'd be very useful is a setup where one machine acts as a server for all my machines, but it only retrieves the packages as and when they are required, and then dishes them out to the requesting machine. This way I don't waste bandwidth (mirrors and mine) downloading KDE 3.5.3 three times, and I don't waste bandwidth dowloading updates for a whole load of software I'll never even install. I know that YOU could leave updates in a folder, but it was never especially clear to me how other machines could use this. Was the folder to be exported, and mounted on the clients? Would there be conflicts with multiple machines using a single dir for managing patches? Or do I have to have SLES for this kind of functionality? Of course, this is now all up in the air due to the 10.1 changes. Any guidance out there? Regards -- Steve Boddy -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Saturday 03 June 2006 03:16, Stephen Boddy wrote:
I would appreciate a pointer if this is possible and the document exists already.
I have three systems (Desktop on 10.0, HTPC on 9.3, and Laptop on 10.1) Once some of the wrinkles are out of 10.1, I intend updating all systems to 10.1. As I understand things, this means that I'll either download each patch 3 times, or I have to make a local sync of a very large portion of the updates and supplementary trees.
You're confusing update and upgrade: - You want to upgrade 9.3 and 10.0 to 10.1 - You want to update the 10.1 laptop 2 different procedures using 2 different repositories.
What'd be very useful is a setup where one machine acts as a server for all my machines, but it only retrieves the packages as and when they are required, and then dishes them out to the requesting machine. This way I don't waste bandwidth (mirrors and mine) downloading KDE 3.5.3 three times, and I don't waste bandwidth dowloading updates for a whole load of software I'll never even install.
You mean some kind of caching proxy? (I'm making the name up, I don't know if it's called that way...) A kind of system that caches all packages, and serves the cached package instead of retrieving them again. Googling... "gg:caching proxy" yields http://www.squid-cache.org/. Is that what you mean? It is part of SL-10.1. ;) I suppose this works only if the URL's in the request are the same, e.g. http://a.org/p.rpm and http://b.org/p.rpm point both to the same package, but I guess the proxy server would see them as different, because the URL's differ.
I know that YOU could leave updates in a folder, but it was never especially clear to me how other machines could use this. Was the folder to be exported, and mounted on the clients? Would there be conflicts with multiple machines using a single dir for managing patches? Or do I have to have SLES for this kind of functionality?
Of course, this is now all up in the air due to the 10.1 changes. Any guidance out there?
This might also be of interest to you: http://en.opensuse.org/Installation_Sources http://en.opensuse.org/Making_a_DVD_from_CDs http://en.opensuse.org/1_CD_Install Perhaps it's possible to set up your own installation source with only those packages you need. Cheers, Leen -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Saturday 03 June 2006 09:22, Leendert Meyer wrote:
On Saturday 03 June 2006 03:16, Stephen Boddy wrote:
I would appreciate a pointer if this is possible and the document exists already.
I have three systems (Desktop on 10.0, HTPC on 9.3, and Laptop on 10.1) Once some of the wrinkles are out of 10.1, I intend updating all systems to 10.1. As I understand things, this means that I'll either download each patch 3 times, or I have to make a local sync of a very large portion of the updates and supplementary trees.
You're confusing update and upgrade:
- You want to upgrade 9.3 and 10.0 to 10.1 - You want to update the 10.1 laptop
2 different procedures using 2 different repositories.
No, I'm not. The older release info was perhaps spurious and given too much prominence. The intended point was that eventually I will have all three machines at 10.1. _Then_ any new updates, in say the kernel, would be downloaded 3x, wasting the mirrors, and my own, bandwidth.
What'd be very useful is a setup where one machine acts as a server for all my machines, but it only retrieves the packages as and when they are required, and then dishes them out to the requesting machine. This way I don't waste bandwidth (mirrors and mine) downloading KDE 3.5.3 three times, and I don't waste bandwidth dowloading updates for a whole load of software I'll never even install.
You mean some kind of caching proxy? (I'm making the name up, I don't know if it's called that way...)
A kind of system that caches all packages, and serves the cached package instead of retrieving them again.
Googling... "gg:caching proxy" yields http://www.squid-cache.org/. Is that what you mean? It is part of SL-10.1. ;)
I suppose this works only if the URL's in the request are the same, e.g. http://a.org/p.rpm and http://b.org/p.rpm point both to the same package, but I guess the proxy server would see them as different, because the URL's differ.
Well this might work if: 1) the machines could be forced to utilise the same repository for updates, which so far the new software updater seems to be configured by the remote registration server choosing one, 2) If the proxy could be configured correctly, i.e. Normal caching elsewhere, but for the narrowly defined repository cache everything forever no matter how big. I don't use a proxy, as my limited experience has been that they actually make things more sluggish, though that might have been the wimpy system it was running on.
I know that YOU could leave updates in a folder, but it was never especially clear to me how other machines could use this. Was the folder to be exported, and mounted on the clients? Would there be conflicts with multiple machines using a single dir for managing patches? Or do I have to have SLES for this kind of functionality?
Of course, this is now all up in the air due to the 10.1 changes. Any guidance out there?
This might also be of interest to you:
http://en.opensuse.org/Installation_Sources http://en.opensuse.org/Making_a_DVD_from_CDs http://en.opensuse.org/1_CD_Install
Perhaps it's possible to set up your own installation source with only those packages you need.
That would be a maintenence nightmare. I'd have to download the packages, and rebuild the repos. everytime there is an update, assuming I'm aware that an update has been released. No, not a viable solution I'm afraid. Essentially, the ideal setup would look like: mirror (full updates folder) v desktop (local "sparse" updates folder) v HTPC/laptop/desktop software updater client. (assume all are running 10.1) When any of the clients request a package update, the desktop looks for it in the sparse folder. If it's there is starts dishing it out. If not, it retrieves it from the mirror, and dishes it out as well. Later a second client requests the same package. It is now in the local folder, so no need to use the mirror, and I only use bandwidth downloaded updates for packages I have installed. It might be possible to code this as some sort of hybrid unionfs/fuse filesystem if there isn't a way to do it with the existing tools. Regards -- Steve Boddy -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
participants (2)
-
Leendert Meyer
-
Stephen Boddy