Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to push updated software to other SuSE machines from single image?
- Thread starter strikelit
- Start date
I don't know SUSE's methodology. However, the RedHat and Debian derived distributions are typically/always a "pull" based update methodology. Meaning you add a cron job (or manually) to launch the updating tool. You make decisions about what to update, and then the package manager applies the packages/dependencies, etc.
An approach that larger organizations can take (where they are careful about bandwidth usage that leaves their LAN perimeter) is to build a local package server for the distribution(s) that are in service within the environment. Then, instead of scripting/cron'ing the local machines to request updates from an external host, they are instead drawing from a local package "server"/repository within the LAN perimeter.
I've never seen something like M$'s SMS that scripts a "push" from a central point to client machines in the linux distribution space. COULD be out there, just never seen it.
D.E.R. Management - IT Project Management Consulting
An approach that larger organizations can take (where they are careful about bandwidth usage that leaves their LAN perimeter) is to build a local package server for the distribution(s) that are in service within the environment. Then, instead of scripting/cron'ing the local machines to request updates from an external host, they are instead drawing from a local package "server"/repository within the LAN perimeter.
I've never seen something like M$'s SMS that scripts a "push" from a central point to client machines in the linux distribution space. COULD be out there, just never seen it.
D.E.R. Management - IT Project Management Consulting
Depending on the exact permutation (Suse vs OpenSuse, versions, etc.) you may have a number of options:
1) rug/zmd - the Redcarpet updater daemon. Originally from RedHat, was bought by Novell for use in ZenWorks
2) you - Yast Online Update. More of a "pull" kinda thing.
3) libzypp based apps - opensuse amalgamated the above two into a single overall framework not too long ago
If you want immediate, verified, full "push" management of packages, etc. then zen will do exactly that. It does cost money though.
Since these are workstations, you could go with the default updater applet that they include for either KDE or Gnome. You would need to kick it in to "full automatic" mode and configure a yum or apt repository that you control. To get an update out to those machines then, you would need to import a new package into the repository, then wait until the next interval that the updater applet does it's thing. This is still a "pull" method of doing things, but it does work.
Cheers!
1) rug/zmd - the Redcarpet updater daemon. Originally from RedHat, was bought by Novell for use in ZenWorks
2) you - Yast Online Update. More of a "pull" kinda thing.
3) libzypp based apps - opensuse amalgamated the above two into a single overall framework not too long ago
If you want immediate, verified, full "push" management of packages, etc. then zen will do exactly that. It does cost money though.
Since these are workstations, you could go with the default updater applet that they include for either KDE or Gnome. You would need to kick it in to "full automatic" mode and configure a yum or apt repository that you control. To get an update out to those machines then, you would need to import a new package into the repository, then wait until the next interval that the updater applet does it's thing. This is still a "pull" method of doing things, but it does work.
Cheers!
So far, I've never heard of any way you can "push" an update. You could try getting your updated via a proxy. That way your proxy will cache your updates and all subsequent client updates will be faster.
Alternatively, get you package manager/updater to keep all updated packages in its cache on one "master" workstation. Script the other clients to rsync the masters cache folder and do an upudate.
--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--
Alternatively, get you package manager/updater to keep all updated packages in its cache on one "master" workstation. Script the other clients to rsync the masters cache folder and do an upudate.
--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--
I agree with the majority on what should happen, but now that a few of your systems has fallen behind you can either update them manually if all the updates are in the package manager or the other options:
Ghost - (note ext support sucked the last time I used it and was only able to raw the whole disk)
dd or netdd - If the systems have all the same settings and the home directories are on a seperate partion, you should be able to use dd or netdd from a live distro to "push an image"
Additional question for zeland, sounds like your talking about apt. Is there a way to have the proxy/master also send the settings for each package?
[plug=shameless]
[/plug]
Ghost - (note ext support sucked the last time I used it and was only able to raw the whole disk)
dd or netdd - If the systems have all the same settings and the home directories are on a seperate partion, you should be able to use dd or netdd from a live distro to "push an image"
Additional question for zeland, sounds like your talking about apt. Is there a way to have the proxy/master also send the settings for each package?
[plug=shameless]
[/plug]
jstreich:
To my understanding, the OP was inquiring if all the latest patches installed on one of his workstation could be "pushed" to the other workstations.
The first question that would have come to all our minds would be why not let all the individual workstation do their own independent updates, unless bandwidth and time were constraints in his situation. This would be the most "logical" of solution because all the workstations might have different packages installed.
The premise of my answer is based on the above assumed constraints the OP might be facing. The "master" (the updated workstation) serves as a starting point in updating the remainder of his workstations.
The package managers/updates that I've worked with (up2date, apt, yum) store their downloaded packages in /var/cache/[xxx], where [xxx] depends on the package managers/updates used. Some configuration may be required so that they do not remove the downloaded packages after finishing an update. From here on, the remainder of the workstation need only to copy the cached packages from the "master" workstation and run their own updates. If the other workstation have exactly the same packages, then the update would complete without the need to download anything else off the net.
strikelit:
BTW, why do you not just allow all your workstations to do their own updates?
--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--
To my understanding, the OP was inquiring if all the latest patches installed on one of his workstation could be "pushed" to the other workstations.
The first question that would have come to all our minds would be why not let all the individual workstation do their own independent updates, unless bandwidth and time were constraints in his situation. This would be the most "logical" of solution because all the workstations might have different packages installed.
The premise of my answer is based on the above assumed constraints the OP might be facing. The "master" (the updated workstation) serves as a starting point in updating the remainder of his workstations.
The package managers/updates that I've worked with (up2date, apt, yum) store their downloaded packages in /var/cache/[xxx], where [xxx] depends on the package managers/updates used. Some configuration may be required so that they do not remove the downloaded packages after finishing an update. From here on, the remainder of the workstation need only to copy the cached packages from the "master" workstation and run their own updates. If the other workstation have exactly the same packages, then the update would complete without the need to download anything else off the net.
strikelit:
BTW, why do you not just allow all your workstations to do their own updates?
--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--
- Status
Similar threads
- Locked
- Question
- Locked
- Question