Hi all,
I''m looking into a way to centrally manage installed packages on a
fairly fine-grained level. We prefer not to blindly install every new
update, but when a mechanism in which we can "approve" of a certain
version or not. At first I was thinking about something external to
puppet, but then I remembered that it''s possible in puppet to tell
which version needs to be installed.
Now, I''m thinking of a way to have each Package statement check an
external resource. The reason that I can''t simply have a central
template generated by some script that sets something like this:
package { "tcpdump":
ensure => "3.9.5-2etch1",
}
is that not every package is installed on each server. Also, I have
some machines that can upgrade without a problem, other machines that
are to valuable to upgrade without testing.
In short, is there a way to make Package{} query some external data
source to check which version of which package needs to be installed
on this machine? Or have people other ways to do this?
Essentially, I''m a bit tired of ssh''ing to about 50 machines
each
morning to install the latest version of file or tcpdump. But I don''t
want everything done automagically, because there are some things that
I don''t want upgraded every time. Tips welcome.
--
Gegroet,
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 13 August 2007, Tim Stoop wrote:> In short, is there a way to make Package{} query some external data > source to check which version of which package needs to be installed > on this machine? Or have people other ways to do this?You could write a puppet function, which does the lookup and use it like this: package { $p: ensure => target_version($p) } Perhaps you can access some puppet internals even, to see where you are called, to avoid the parameter?> Essentially, I''m a bit tired of ssh''ing to about 50 machines each > morning to install the latest version of file or tcpdump. But I don''t > want everything done automagically, because there are some things that > I don''t want upgraded every time. Tips welcome.Alternatively you could use one of the "distributed ssh" alternatives, like clusterssh - administer multiple ssh or rsh shells simultaneously or dsh - dancer''s shell, or distributed shell Regards, DavidS - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGwDhq/Pp1N6Uzh0URAtb8AJ0b8nl/QLbv4Lk4qZHzuRJuh1emUgCfVkx5 Dlud7BmjLD49wF/st919V1k=1qvW -----END PGP SIGNATURE-----
On Aug 13, 2007, at 5:54 AM, David Schmitt wrote:> > You could write a puppet function, which does the lookup and use it > like this: > > package { $p: ensure => target_version($p) } > > Perhaps you can access some puppet internals even, to see where you > are > called, to avoid the parameter?Another option, depending on your platform, is to keep a local repository that only has versions you want in it, so it''s always safe to upgrade. That''s probably the easiest to maintain. -- If a `religion'' is defined to be a system of ideas that contains unprovable statements, then Godel taught us that mathematics is not only a religion, it is the only religion that can prove itself to be one. -- John Barrow --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com