Puppet users - Apr 2011 - What to do if something is not required on the clients?

Dear all,

It''s probably a newbie question again: What to do to  ensure something
is "not running" or "not installed" and things like that as
oppose to
"ensure => installed", "ensure => running", etc. ?
e.g. if I want to
make sure that http is not running on certain clients - any way of
doing that?

Thanks in advance. Cheers!!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 15, 2011, at 1:02 AM, Sans wrote:
> Dear all,
> 
> It''s probably a newbie question again: What to do to  ensure
something
> is "not running" or "not installed" and things like
that as oppose to
> "ensure => installed", "ensure => running", etc.
? e.g. if I want to
> make sure that http is not running on certain clients - any way of
> doing that?
For the package example, I''d try "ensure => absent".  I
think I remember that works.

For the httpd example, I''d try just ensuring that the httpd package
isn''t installed.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks Patrick!
Where can I get the list of attributes and their predefined values?
Cheers!!


On Apr 15, 9:12 am, Patrick <kc7...@gmail.com>
wrote:
> For the package example, I''d try "ensure => absent".
 I think I remember that works.
>
> For the httpd example, I''d try just ensuring that the httpd
package isn''t installed.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 15-04-11 10:20, Sans wrote:
> Thanks Patrick!
> Where can I get the list of attributes and their predefined values?
> Cheers!!

The type reference:
http://docs.puppetlabs.com/references/latest/type.html

> On Apr 15, 9:12 am, Patrick <kc7...@gmail.com> wrote:
>> For the package example, I''d try "ensure =>
absent".  I think I remember that works.
>>
>> For the httpd example, I''d try just ensuring that the httpd
package isn''t installed.
> 

Regards,
Martijn.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 15, 9:37 am, Martijn Grendelman <mart...@iphion.nl>
wrote
>
> > On Apr 15, 9:12 am, Patrick <kc7...@gmail.com> wrote:
> >> For the package example, I''d try "ensure =>
absent".  I think I remember that works.
"ensure => absent" uses "rpm -e'' to remove a package,
which is a
problem for the packages with related dependencies. Is there any way
to use "yum remove" to do that? Cheers!!
>
> >> For the httpd example, I''d try just ensuring that the
httpd package isn''t installed.
>
> Regards,
> Martijn.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 15, 2011, at 6:04 PM, Sans wrote:
> On Apr 15, 9:37 am, Martijn Grendelman <mart...@iphion.nl> wrote
>> 
>>> On Apr 15, 9:12 am, Patrick <kc7...@gmail.com> wrote:
>>>> For the package example, I''d try "ensure =>
absent".  I think I remember that works.
> 
> "ensure => absent" uses "rpm -e'' to remove a
package, which is a
> problem for the packages with related dependencies. Is there any way
> to use "yum remove" to do that? Cheers!!
It''s been too long since I use rpm.  Are you saying it refuses to
remove the package because something depends on apache, or that you want to
remove stuff apache installed (like libapache or whatever)?


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 16, 2:36 am, Patrick <kc7...@gmail.com>
wrote:
>
> > "ensure => absent" uses "rpm -e'' to remove
a package, which is a
> > problem for the packages with related dependencies. Is there any way
> > to use "yum remove" to do that? Cheers!!
>
> It''s been too long since I use rpm.  Are you saying it refuses to
remove the package because something depends on apache, or that you want to
remove stuff apache installed (like libapache or whatever)?
yes, former. In RHEL, system-config-httpd depends on httpd package and
using "rpm -e" httpd cannot be uninstalled if system-config-httpd is
also not uninstalled beforehand. Cheers!!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 04/16/2011 09:12 AM, Sans wrote:
> 
> 
> On Apr 16, 2:36 am, Patrick <kc7...@gmail.com> wrote:
>>
>>> "ensure => absent" uses "rpm -e'' to
remove a package, which is a
>>> problem for the packages with related dependencies. Is there any
way
>>> to use "yum remove" to do that? Cheers!!
>>
>> It''s been too long since I use rpm.  Are you saying it refuses
to remove the package because something depends on apache, or that you want to
remove stuff apache installed (like libapache or whatever)?
> 
> yes, former. In RHEL, system-config-httpd depends on httpd package and
> using "rpm -e" httpd cannot be uninstalled if system-config-httpd
is
> also not uninstalled beforehand. Cheers!!
Hi,

what version of puppet is this?

Does "puppetd --test --noop -dv" give you (near the top of the output)
any indication why it doesn''t use the "yum" provider for
packages?

There are cases where a provider works, but isn''t correctly recognized
as default on a system. You can include ''provider =>
"yum"'' in your
package resources in this case.

HTH,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 15, 8:04 pm, Sans <r.santanu....@gmail.com>
wrote:
> On Apr 15, 9:37 am, Martijn Grendelman <mart...@iphion.nl> wrote
>
>
>
> > > On Apr 15, 9:12 am, Patrick <kc7...@gmail.com> wrote:
> > >> For the package example, I''d try "ensure =>
absent".  I think I remember that works.
>
> "ensure => absent" uses "rpm -e'' to remove a
package, which is a
> problem for the packages with related dependencies. Is there any way
> to use "yum remove" to do that? Cheers!!
You can use a conditional to make the package managed only when you
want to have it, and an exec to "yum remove" it when you
don''t:

if $i_want_httpd {
   package { "httpd":
       ...
   }
} else {
   exec { "yum -y remove httpd":
      onlyif => "rpm -q httpd"  # only if it''s installed
   }
}

But that''s messy, and it begs the question: if you have packages
installed that depend on httpd then don''t you need to ensure them
absent anyway?  I mean, for each such package there are two
possibilities:

1) The dependent package is managed by Puppet.  In this case, you must
ensure it absent too, else you cannot achieve a consistent
configuration.  You will either get Puppet failures or flip-flops
between whether httpd is installed or not.  (I am fairly sure that
this is why the yum Package provider uses "rpm -e" instead of
"yum
remove" in the first place.)  To fix it, you have to ensure the
dependent package absent too, and in that case you can address your
original problem by twiddling the dependent package''s dependencies.
For example:

package { "httpd-special-gizmo":
   ...
   before => $i_want_httpd ? {
      "no" => Packge["httpd"],
      default => undef
   }
}

2) The dependent package is not managed by Puppet.  In this case,
think hard about why you want this situation in the first place.  If
you decide you do want it, then I would be very surprised if you
really also want to remove the dependent packages automatically.  If
you decide you do not want the situation, then you can convert this
case to case (1) by bringing the dependent packages under management.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, 2011-04-18 at 23:22 +1000, jcbollinger wrote:
> (I am fairly sure that
> this is why the yum Package provider uses "rpm -e" instead of
"yum
> remove" in the first place.)  
Except that installing or removing packages with rpm is now deprecated:

http://illiterat.livejournal.com/7834.html


--
Ian



-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 04/19/2011 03:57 AM, Ian Mortimer wrote:
> On Mon, 2011-04-18 at 23:22 +1000, jcbollinger wrote:
> 
>> (I am fairly sure that
>> this is why the yum Package provider uses "rpm -e" instead of
"yum
>> remove" in the first place.)  
> 
> Except that installing or removing packages with rpm is now deprecated:
> 
> http://illiterat.livejournal.com/7834.html
Looking at the provider more closely, it does indeed seem to fall back
to rpm for removing packages. However, it does implement a native
"purge" function. So setting ''ensure =>
"purged"'' may do the right thing.

Then of course, if you want puppet to uninstall using yum but *not*
purge, you''re currently screwed.
The OP may want to consider raising a bug about this.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 18, 2:22 pm, jcbollinger <John.Bollin...@stJude.org>
wrote:
> [ ..... ]
>
> 1) The dependent package is managed by Puppet.  In this case, you must
> ensure it absent too, else you cannot achieve a consistent
> configuration.  You will either get Puppet failures or flip-flops
> between whether httpd is installed or not.  (I am fairly sure that
> this is why the yum Package provider uses "rpm -e" instead of
"yum
> remove" in the first place.)  To fix it, you have to ensure the
> dependent package absent too, and in that case you can address your
> original problem by twiddling the dependent package''s
dependencies.
> For example:
>
If I understand you correctly, how do one know about the packages that
depend on a certain package? Even though someone may know about the
"dependent" packages, do you mean to list all the packages with
"no"
parameter? Cheers!!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 18, 8:57 pm, Ian Mortimer <I.Morti...@uq.edu.au>
wrote:
> On Mon, 2011-04-18 at 23:22 +1000, jcbollinger wrote:
> > (I am fairly sure that
> > this is why the yum Package provider uses "rpm -e" instead
of "yum
> > remove" in the first place.)  
>
> Except that installing or removing packages with rpm is now deprecated:
>
> http://illiterat.livejournal.com/7834.html
I can''t read the article (livejournal is blocked here).

The bottom line as far as our discussion goes, however, is that it is
*intentional* that the yum Package provider fails to remove packages
on which other installed packages depend, and that there is good
technical justification for that design choice.  I would be surprised
if other Package providers were different in that regard.  Your Puppet
manifests need to account for that, one way or another.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 04/19/2011 03:18 PM, jcbollinger wrote:
> 
> 
> On Apr 18, 8:57 pm, Ian Mortimer <I.Morti...@uq.edu.au> wrote:
>> On Mon, 2011-04-18 at 23:22 +1000, jcbollinger wrote:
>>> (I am fairly sure that
>>> this is why the yum Package provider uses "rpm -e"
instead of "yum
>>> remove" in the first place.)  
>>
>> Except that installing or removing packages with rpm is now deprecated:
>>
>> http://illiterat.livejournal.com/7834.html
> 
> I can''t read the article (livejournal is blocked here).
> 
> The bottom line as far as our discussion goes, however, is that it is
> *intentional* that the yum Package provider fails to remove packages
> on which other installed packages depend, and that there is good
> technical justification for that design choice.  I would be surprised
> if other Package providers were different in that regard.  Your Puppet
> manifests need to account for that, one way or another.
I disagree.

First off, the apt provider *will* recursively uninstall depending packages.

Second, this *is* sound design. If I tell puppet that I don''t want
package "X" on my system, I expect it to remove it and do whatever is
necessary, except the provider''s backend objects.

It is your opinion that a package manager should object as soon as a
depended package would be removed by an uninstallation. Myself, I don''t
want to be bothered with such details. I fully expect my package manager
do care about all aspects of dependeny resolution, be it during
installation or its opposite.

Regards,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 19, 6:08 am, Sans <r.santanu....@gmail.com>
wrote:
> On Apr 18, 2:22 pm, jcbollinger <John.Bollin...@stJude.org>
wrote:> [ ..... ]
>
> > 1) The dependent package is managed by Puppet.  In this case, you must
> > ensure it absent too, else you cannot achieve a consistent
> > configuration.  You will either get Puppet failures or flip-flops
> > between whether httpd is installed or not.  (I am fairly sure that
> > this is why the yum Package provider uses "rpm -e" instead
of "yum
> > remove" in the first place.)  To fix it, you have to ensure the
> > dependent package absent too, and in that case you can address your
> > original problem by twiddling the dependent package''s
dependencies.
> > For example:
>
> If I understand you correctly, how do one know about the packages that
> depend on a certain package?
Well that''s part of a deeper problem, isn''t it?  If you
don''t know
what packages you might end up removing or why they''re installed in
the first place, then are you really comfortable with blindly removing
them?  I certainly wouldn''t be.
> Even though someone may know about the
> "dependent" packages, do you mean to list all the packages with
"no"
> parameter? Cheers!!
No, I don''t mean that.  For a very tightly-controlled configuration,
one might choose to declare all packages that should be installed and
to purge anything else, but that can be hard to maintain, and I
wouldn''t recommend it unless you really need it.  Most people
don''t go
that far.

I mean you test your manifests before rolling them out and collect
automated reports from the clients afterward, you troubleshoot
failures, and when you identify a package dependency that causes
removal of another package to fail, you add a
    package { "unwanted-dependency":
        ensure => absent,
        before => Package["dependent-package"]
    }
to the affected nodes'' manifests.  (Or if the dependency is already
under management then adjust its declaration as needed.)

Also, the frequency of such problems will be reduced if you take
firmer control of your machines'' initial provisioning.  For example,
your initial install might be the bare minimum needed to get Puppet
running, with everything else needed being installed under Puppet
control.  Alternatively, do at least consider a provisioning system
that starts all your systems in the same, known state -- that way you
can solve the dependency issues once for that configuration and cover
the majority of package dependency issues that you will ever need to
handle.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 19, 8:26 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
> On 04/19/2011 03:18 PM, jcbollinger wrote:
[...]
> > The bottom line as far as our discussion goes, however, is that it is
> > *intentional* that the yum Package provider fails to remove packages
> > on which other installed packages depend, and that there is good
> > technical justification for that design choice.  I would be surprised
> > if other Package providers were different in that regard.  Your Puppet
> > manifests need to account for that, one way or another.
>
> I disagree.
>
> First off, the apt provider *will* recursively uninstall depending
packages.
That''s an unfortunate inconsistency between providers.  I am
surprised.

Oddly enough, I found bug 1739, closed on 0.24.x, that makes exactly
the change from "rpm -e" to "yum -y remove".  That would
make the yum
provider work like the apt provider.  I didn''t find anything
suggesting that it was reverted, yet the change is not present in the
released code.
> Second, this *is* sound design. If I tell puppet that I don''t want
> package "X" on my system, I expect it to remove it and do
whatever is
> necessary, except the provider''s backend objects.
I didn''t say that behavior such as the apt provider''s is
unsound or
unjustified, rather I said that the Yum provider''s behavior is
intentional (my deduction) and justified.  When there is justification
for two incompatible alternatives, a design decision must be made, and
it was made -- inconsistently -- for the Package providers.
> It is your opinion that a package manager should object as soon as a
> depended package would be removed by an uninstallation.
It is my opinion that it is *reasonable* for a Puppet Package provider
refuse to remove a package on which others depend instead of removing
all dependencies along with it.  It is _not_ my opinion that the
alternative would be _un_reasonable.  Both approaches have advantages
and disadvantages.

It is less reasonable, however, that providers are inconsistent in
this regard.
> Myself, I don''t
> want to be bothered with such details. I fully expect my package manager
> do care about all aspects of dependeny resolution, be it during
> installation or its opposite.
That''s fair.  But consider this:

package { "foo":
    ensure => absent
}

package { "i-depend-on-foo":
    ensure => latest
}

The manifest is inherently inconsistent, yet if the Package provider
performs automatic dependency installation and removal then it can be
applied without error.  The result depends on which package is managed
first, and at least one of the packages will flip-flop between being
installed and uninstalled.  The specified configuration can never be
achieved.  If I had that situation in one of my manifests, I would
want an error message.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Apr 19, 2011 at 7:46 AM, jcbollinger <John.Bollinger@stjude.org>
wrote
>
>
> On Apr 19, 8:26 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
> wrote:
>> On 04/19/2011 03:18 PM, jcbollinger wrote:
>
> [...]
>
>> > The bottom line as far as our discussion goes, however, is that it
is
>> > *intentional* that the yum Package provider fails to remove
packages
>> > on which other installed packages depend, and that there is good
>> > technical justification for that design choice.  I would be
surprised
>> > if other Package providers were different in that regard.  Your
Puppet
>> > manifests need to account for that, one way or another.
>>
>> I disagree.
>>
>> First off, the apt provider *will* recursively uninstall depending
packages.
>
> That''s an unfortunate inconsistency between providers.  I am
> surprised.
>
> Oddly enough, I found bug 1739, closed on 0.24.x, that makes exactly
> the change from "rpm -e" to "yum -y remove".  That
would make the yum
> provider work like the apt provider.  I didn''t find anything
> suggesting that it was reverted, yet the change is not present in the
> released code.
The commit is still present, it''s implemented as the purge action for
yum provider. Check:

git show d5e19f
git blame lib/puppet/provider/package/yum.rb

Nan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 19, 2:48 pm, jcbollinger <John.Bollin...@stJude.org>
wrote:
>
> > If I understand you correctly, how do one know about the packages that
> > depend on a certain package?
>
> Well that''s part of a deeper problem, isn''t it?  If you
don''t know
> what packages you might end up removing or why they''re installed
in
> the first place, then are you really comfortable with blindly removing
> them?  I certainly wouldn''t be.
>
I don''t think that''s the way you do it. You don''t
install packages at
random or without having known why you installing that package for -
do you? And if you know the packages you installing, you already know
the dependences and the related packages. At least that''s the case
here. In this example, if I know that I definitely don''t want httpd to
be installed on the system at the first place, then why should I care
about all the packages (maybe installed by default) that need httpd -
isn''t it?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, 2011-04-20 at 07:37 +1000, Sans wrote:
> if I know that I definitely don''t want httpd to
> be installed on the system at the first place, then why should I care
> about all the packages (maybe installed by default) that need httpd -
What happens if an update of a required package introduces a new
dependency on httpd.  "yum update" will install httpd to satisfy
the dependency but then you have a conflict in your puppet manifest
between ensuring httpd is absent while ensuring the dependent package
is latest.

(Admittedly I haven''t seen this with httpd but something similar
with mysql-server on Fedora).


--
Ian


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Apr 19, 2011 at 9:31 PM, Ian Mortimer <I.Mortimer@uq.edu.au>
wrote:
> On Wed, 2011-04-20 at 07:37 +1000, Sans wrote:
>
> > if I know that I definitely don''t want httpd to
> > be installed on the system at the first place, then why should I care
> > about all the packages (maybe installed by default) that need httpd -
>
> What happens if an update of a required package introduces a new
> dependency on httpd.  "yum update" will install httpd to satisfy
> the dependency but then you have a conflict in your puppet manifest
> between ensuring httpd is absent while ensuring the dependent package
> is latest.
>
> (Admittedly I haven''t seen this with httpd but something similar
> with mysql-server on Fedora).
>
>
> --
> Ian
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
This is an excellent example of ''right tool for the job''.
The native package manager should be used to manage packages. Puppet is the
tool we are using to manage/configure that package manager in an automated
fashion keeping in mind that it''s not usurping the package
manager''s
function.
Yum is a frontend to rpm (man, I don''t miss rpm dependency hell of days
gone
by) and puppet is basically an extra team member (or team even) IMHO.


-- 
Cheers,

Steven
-----------------------
Steven Acres
UNIX/Linux System Administrator

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 19, 10:04 am, Nan Liu <n...@puppetlabs.com>
wrote:
> On Tue, Apr 19, 2011 at 7:46 AM, jcbollinger
<John.Bollin...@stjude.org> wrote
[...]
> > Oddly enough, I found bug 1739, closed on 0.24.x, that makes exactly
> > the change from "rpm -e" to "yum -y remove".  That
would make the yum
> > provider work like the apt provider.  I didn''t find anything
> > suggesting that it was reverted, yet the change is not present in the
> > released code.
>
> The commit is still present, it''s implemented as the purge action
for
> yum provider. Check:
>
> git show d5e19f
> git blame lib/puppet/provider/package/yum.rb
My bad: I missed that the feature was implemented as purge instead of
ordinary remove.  That does provide a useful insight on the underlying
request: if you want to instruct the yum provider to ensure a package
removed along with any other packages that depend on it, then setting

    ensure => purged

on the package ought to do the trick.  Not that I think it''s a good
idea, except possibly in the case to which bug 1739 was addressed,
cyclic dependencies.

Thanks for the clarification.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 19, 4:37 pm, Sans <r.santanu....@gmail.com>
wrote:
> On Apr 19, 2:48 pm, jcbollinger <John.Bollin...@stJude.org> wrote:
>
> > > If I understand you correctly, how do one know about the packages
that
> > > depend on a certain package?
>
> > Well that''s part of a deeper problem, isn''t it?  If
you don''t know
> > what packages you might end up removing or why they''re
installed in
> > the first place, then are you really comfortable with blindly removing
> > them?  I certainly wouldn''t be.
>
> I don''t think that''s the way you do it. You
don''t install packages at
> random or without having known why you installing that package for -
> do you?
I don''t, and you are making my case for me.  If a package I think I
want absent has a dependent package present, then (in my case) that
dependency is there on purpose.  If I have done my provisioning
correctly, then either the dependency is something I want on
substantially all nodes, or it is something that I installed
afterward, via Puppet.  As Ian points out, however, that installation
may have been implicit and incidental to installation or upgrade of a
different package.

The possibilities can be divided among a few cases:

1) The dependent package is explicitly managed by Puppet.  In this
case you *must* ensure it absent for those nodes where its dependency
must be absent, otherwise your configuration is inconsistent and
unachievable.

2) The dependent package is provisioned and wanted, or at least
accepted, on all nodes, but it is not Puppet-managed by default.
Inasmuchas a requirement that this package be absent is exceptional,
it is reasonable and even wise to explicitly ensure its absence via
Puppet when that is needed.

3) The dependent package is not intentionally provisioned, not Puppet-
managed, and by default unwanted.  If the package is in fact present,
then I want to know it so I can figure out why.  Either there is some
system requirement that is not captured in the node''s Puppet
configuration (and which I do not want to break), or the configuration
is inconsistent, or there has been a provisioning or administration
failure.  Any of these alternatives require my attention, so I want
the puppet client to make noise.
> And if you know the packages you installing, you already know
> the dependences and the related packages. At least that''s the case
> here. In this example, if I know that I definitely don''t want
httpd to
> be installed on the system at the first place, then why should I care
> about all the packages (maybe installed by default) that need httpd -
> isn''t it?
You continue to make my case.  If you definitely don''t want httpd (for
example) installed, then you should not provision your systems with
it, right?  If you don''t provision your systems with it, and
you''re
certain you don''t want it, but later it gets installed anyway, then
don''t you think that situation would require some investigation?
Especially if httpd gets installed because something you do want
depends on it?  I think so.

If none of that persuades you then it looks like you can ensure =>
purged instead of ensure => absent to get the behavior you want.  I
would not be comfortable with doing that, but perhaps it makes sense
to you.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks John and others.
For my case, I definitely know I don''t need "httpd" and any
packages
(or updates) that depend on httpd, so  "ensure => purged" should
work
for me, in this particular occasion.

However, I also tried this (I posted this before in this thread abut
can''t see that anymore):

package {
        ''httpd'': notify => Exec[
''remove-httpd'' ];
    }

exec { ''remove-httpd'':
        command     => ''/usr/bin/yum remove -y httpd'',
        refreshonly => true,
    }

but doesn''t work either. What am I doing anything wrong here? Cheers!!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> However, I also tried this (I posted this before in this thread abut
> can''t see that anymore):
> 
> package {
>         ''httpd'': notify => Exec[
''remove-httpd'' ];
>     }
> 
> exec { ''remove-httpd'':
>         command     => ''/usr/bin/yum remove -y httpd'',
>         refreshonly => true,
>     }
> 
> but doesn''t work either. What am I doing anything wrong here?
Cheers!!
Hi,

this is a very bad idea and abuse of notify.

The above tells puppet "whenever you change the httpd package (install
it, remove it, update it) do that exec afterwards".

But the package has no ensure, so puppet will never try anything with
the package. Even if you set "ensure => absent" (which
didn''t work for
you), the notify wouldn''t fire either, because puppet wasn''t
able to
perform the requested action in the first place. Depending resources
(and notify implies a dependency) are skipped after such errors.

You do not want to manage a package using both a native type and an
exec. That''s bound to blow up into your face. In fact, try to *not
ever*
call out to your package manager in an exec.

As an aside, notify => exec is almost always inferior to a good "exec {
onlyif => ... }" rule.
If you make a booboo in your exec, you may later have a hard time
generating a new notify. Conditions in "onlyif" and "unless"
are a lot
more reliable.
Here, you should have used an onlyif involving "rpm -q". But
don''t do
that ;-)

Regards,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks Felix, for the explaining this to me. I''m still learning Puppet
and making mistakes. Although I used  "ensure => purged" for httpd,
I
wanted to know why this wasn''t working. Thanks again. Cheers!!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.