roll back update

[Muhammad Yousuf Khan]

Hello All,

i have seen so many apt modules on puppet forge website. they are more like changing source list path defining. HTTP proxy blah blah but what i want is a bit more.
is there any apt module  which can help me to update only selective updates (like in Microsoft Wsus does, it list down all the updates and people can select and apply those patches on selective nodes and if they find it problematic then can remotely uninstall it too.i want this to be done on my Debian server farm and and i also want to roll back as needed (for example if any securety or OS update creating problem of some kind i can roll it back with puppet live management/manual run).
i dont know how practical it is. however as i have already got the concept of Wsus therefore my mind is trying to think of wsus like puppet module.
Please help.
thanks,
MYK

[SHARNIND...@dell.com]

Mohammad,

 

As far as I know, there is nothing in the puppet world that does what you want. On the other hand, puppet does give you the flexibility to manage packages to be installed (or uninstalled) on the managed nodes.

 

Whether you can use it for installing/removing patches, depends on how the patches are distributed.  On a redhat based system, puppet will use rpm to install/remove packages and on a debian based system it’ll use apt, so that intelligence is already built-in to puppet.

 

Puppet gives you a framework and leaves it up to your creativity (or lack of it) to go wild.

 

Take a look at the puppet cookbook for basic examples and in the end there is nothing better than to RTFM.

 

http://www.puppetcookbook.com/posts/install-package.html

 

--

Sharninder

 

 

 

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/46482f37-c6e1-4242-b87e-f689a3c11016%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jason Antman]

There's nothing existing that I know of that works in the GUI-based way
you seem to be talking about. Because, well, we *nix people usually
don't do that.

I've really only worked on RPM-based systems, so I'm not sure if this is
still applicable in the debian world...

There are 2 types of updates I do

1) updating one package or a set of packages (like, updating Puppet from
3.1.0 to 3.4.1) which I do with the "ensure" parameter on the Package
type. Some stuff is wrapped up in classes, and this can be done through
an ENC (parameterized classes, or global params if need be) or Hiera.
I'll change the version on one node, test it, then an environment, test
it, and eventually apply it everywhere. If you need to downgrade/roll
back, that *can* work... might work better in the apt/deb world than it
does in yum/rpm.

2) Full system updates/upgrades, what RHEL-derivatives term as
"distribution upgrades", i.e. updating all packages from CentOS 6.3 to
6.4. I rebuild the box. No reason to mess with doing this through the
distro, I just shut it down, clean the cert in puppet, do a fresh PXE
boot (and kickstart) and let Puppet do its thing. This has the added
benefit of reducing entropy, and even providing a nice DR test (like if
you just log in and poweroff immediately...)

-Jason

[Steven VanDevender]

Jason Antman writes:
> There's nothing existing that I know of that works in the GUI-based way
> you seem to be talking about. Because, well, we *nix people usually
> don't do that.

> I've really only worked on RPM-based systems, so I'm not sure if this is
> still applicable in the debian world...

Debian-based distributions have interactive tools like "aptitude"
(curses-based) or "synaptic" (GNOME GUI) that can let you do selective
package installation and upgrades on a host, in addition to the
command-line "apt-get" and "dpkg" utilties. These don't really offer
centralized management of a group of hosts, though.

In the RPM world there's Spacewalk (or the Red Hat Satellite Server
commercial product based on it) for doing centralized package
management. There's probably some equivalent in the Debian world but
I'm not aware of what that is. Setting up a local repository mirror can
let you control what packages are visible to hosts so you can control
package versions for installation and upgrades (in fact, I've seen
people set up multiple mirrors visible to different environments so they
can do things like staged upgrade testing).

[Jesse Throwe]

You can also do zfs/btrfs snapshots before doing a distribution
upgrade, allowing for a rollback of the OS. SuSE has rolled this into
some of the most recent versions of their OS (I believe the command
line tool is called snapper).

EIther way, none of the solutions are particularly puppet oriented.

[jcbollinger]

I wonder whether what you want is actually a bit less.  If you want to ensure specific packages installed on your target nodes, then you express that in Puppet DSL by declaring appropriate Package resources.  Good package managers (such as apt and yum) will install/update the target package's dependencies, too, if needed.

# Ensure package woot is installed:
package { 'woot':  ensure => 'present' }

# Ensure version 0.42 of package woot is installed:
package { 'woot':  ensure => '0.42' }

# Ensure the latest available version of package woot is installed:
package { 'woot':  ensure => 'latest' }

# Ensure package woot is not installed:
package { 'woot':  ensure => 'absent' }

If you want to control what packages are available for installation, then details depend on which package management system you are using.  That's where managing Apt sources comes into play for Apt-based systems.  Also, it is usually to your advantage in this area to maintain your own package repositories within your organization, instead of relying on external ones.

As for rollback, there really isn't such a thing in the context of a whole computer system.  Not on any OS.  Some filesystems do allow you to capture and later revert to snapshots of the filesystem state, but that's not quite the same thing.  The closest you can get is reverting a virtual machine to a previously-captured full-system snapshot, but even that cannot reliably revert all of the actions that the target system performed between when the snapshot is captured and when the VM is reverted to it.

Limiting rollback to specific package versions, however, the closest Puppet provides is to 'ensure' a desired (earlier) package version in your Package declaration.


John