Puppet updated yum packages without logging?

[Matthew Barr]

We just saw an interesting scenario:

Puppet 2.7.18 updated packages on a RHEL 6.2 box to a newer version without logging that fact.

We've already fixed our code so it doesn't happen again, but I'm wondering if this is expected behavior or a bug.

* I presume the default  "ensure" behavior on package is "latest"?    The type reference doesn't say that…  

* For now, we've switched to using ensure => present… but I'd have liked the logs to reflect that update.

Details, if necessary: 

Now, we had the code as such:

package {

 php:;

 php-common:;

 php-xml:;

 php-domxml;:

}

and there was a single not present package to install  (php-domxml).  

Interestingly, the package was actually an older package name that's now handled by a new package (php-xml), which meant that the actual message logged was a failure.

Jul 25 14:09:43 web01 puppet-agent[1021]: (/Stage[main]/Php/Package[php-domxml]/ensure) change from absent to present failed: Could not find package php-domxml

This was the only package message logged, and yet we ended up with newer versions.  

Matthew Barr

Technical Architect

E: mb...@snap-interactive.com

AIM: matthewbarr1

c:  (646) 727-0535

[Michael Stahnke]

Did something else pull that package in as a dependency?

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

[Matthew Barr]

No, it updated all the PHP packages that were mentioned in the manifest.  There were about 20 listed, and no actual install happened.

I'm betting that it uses a default action of Latest, and just updated them all behind the scenes.  But I'd expect a logged action on that, as well as a comment on the default behavior in the type reference.

( I'm not as worried about the docs - there has to be some default, and latest isn't a terrible one. ) 

Matthew Barr

Technical Architect

E: mb...@snap-interactive.com

AIM: matthewbarr1

c:  (646) 727-0535

[llo...@oreillyauto.com]

On Thursday, July 26, 2012 1:16:40 PM UTC-5, Matthew Barr wrote:

No, it updated all the PHP packages that were mentioned in the manifest.  There were about 20 listed, and no actual install happened.

I'm betting that it uses a default action of Latest, and just updated them all behind the scenes.  But I'd expect a logged action on that, as well as a comment on the default behavior in the type reference.

( I'm not as worried about the docs - there has to be some default, and latest isn't a terrible one. ) 

'latest' as a default is a bad idea IMO.. can easily lead to breakage if things update on their own. But then again, I've always been one that prefers to explicitly set things, even if it is the default.

Less confusion, or problems if defaults change.
 

puppet-users+unsubscribe@googlegroups.com.

For more options, visit this group at

http://groups.google.com/group/puppet-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.

To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.

[Bill Fraser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Matthew,

According to the source, defaultto is set to 'installed', of which
'present' is an alias.

https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/package.rb

Which means no package updates should have occurred. As for why they
did and why nothing was logged .. that I don't know.

Regards,
Bill Fraser
System Administrator
Pythian

On 12-07-26 10:37 AM, Matthew Barr wrote:
> We just saw an interesting scenario: Puppet 2.7.18 updated packages
> on a RHEL 6.2 box to a newer version without logging that fact.
>
> We've already fixed our code so it doesn't happen again, but I'm
> wondering if this is expected behavior or a bug.
>
> * I presume the default "ensure" behavior on package is "latest"?

> The type reference doesn't say that�
>
> * For now, we've switched to using ensure => present� but I'd have

> liked the logs to reflect that update.
>
>
>
> Details, if necessary:
>
> Now, we had the code as such:
>
>
> package { php:; php-common:; php-xml:; php-domxml;: } and there was
> a single not present package to install (php-domxml).
>
>
> Interestingly, the package was actually an older package name
> that's now handled by a new package (php-xml), which meant that the
> actual message logged was a failure.
>
>
> Jul 25 14:09:43 web01 puppet-agent[1021]:
> (/Stage[main]/Php/Package[php-domxml]/ensure) change from absent to
> present failed: Could not find package php-domxml
>
> This was the only package message logged, and yet we ended up with
> newer versions.
>
>
>
> Matthew Barr Technical Architect E: mb...@snap-interactive.com AIM:
> matthewbarr1 c: (646) 727-0535
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlARkCUACgkQ5xgg9J6hpUt/qACg2oEH5x7qEb2X9YxFbYZh9i+G
Q6EAnRiwQY4bpqKc+SLA6XgUm7z/LJ/S
=8Sxe
-----END PGP SIGNATURE-----

[Michael Stahnke]

I can't reproduce this. I used sudo because it was out-of-date on my system.


[0] root@centos6-64 /tmp> rpm -q sudo
sudo-1.7.4p5-9.el6_2.x86_64

[0] root@centos6-64 /tmp> yum list available | grep sudo
sudo.x86_64 1.7.4p5-12.el6_3 updates

[0] root@centos6-64 /tmp> puppet --version
2.7.12 (Puppet Enterprise 2.5.2)

[0] root@centos6-64 /tmp> cat test.pp
package {
sudo:;
}

[0] root@centos6-64 /tmp> puppet apply --verbose test.pp
info: Loading facts in
/opt/puppet/share/puppet/modules/stdlib/lib/facter/root_home.rb
info: Loading facts in
/opt/puppet/share/puppet/modules/stdlib/lib/facter/facter_dot_d.rb
info: Loading facts in
/opt/puppet/share/puppet/modules/stdlib/lib/facter/puppet_vardir.rb
info: Loading facts in /var/opt/lib/pe-puppet/lib/facter/root_home.rb
info: Loading facts in /var/opt/lib/pe-puppet/lib/facter/facter_dot_d.rb
info: Loading facts in /var/opt/lib/pe-puppet/lib/facter/puppet_vardir.rb
info: Applying configuration version '1343301257'
notice: Finished catalog run in 0.18 seconds

[0] root@centos6-64 /tmp> rpm -q sudo
sudo-1.7.4p5-9.el6_2.x86_64

[0] root@centos6-64 /tmp> yum list available | grep sudo
sudo.x86_64 1.7.4p5-12.el6_3 updates

So, as you can see, my sudo package didn't update.

On Thu, Jul 26, 2012 at 11:44 AM, Bill Fraser <fra...@pythian.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Matthew,
>
> According to the source, defaultto is set to 'installed', of which
> 'present' is an alias.
>
> https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/package.rb
>
> Which means no package updates should have occurred. As for why they
> did and why nothing was logged .. that I don't know.
>
> Regards,
> Bill Fraser
> System Administrator
> Pythian
>
> On 12-07-26 10:37 AM, Matthew Barr wrote:
>> We just saw an interesting scenario: Puppet 2.7.18 updated packages
>> on a RHEL 6.2 box to a newer version without logging that fact.
>>
>> We've already fixed our code so it doesn't happen again, but I'm
>> wondering if this is expected behavior or a bug.
>>
>> * I presume the default "ensure" behavior on package is "latest"?

>> The type reference doesn't say that…
>>
>> * For now, we've switched to using ensure => present… but I'd have

>> liked the logs to reflect that update.
>>
>>
>>
>> Details, if necessary:
>>
>> Now, we had the code as such:
>>
>>
>> package { php:; php-common:; php-xml:; php-domxml;: } and there was
>> a single not present package to install (php-domxml).
>>
>>
>> Interestingly, the package was actually an older package name
>> that's now handled by a new package (php-xml), which meant that the
>> actual message logged was a failure.
>>
>>
>> Jul 25 14:09:43 web01 puppet-agent[1021]:
>> (/Stage[main]/Php/Package[php-domxml]/ensure) change from absent to
>> present failed: Could not find package php-domxml
>>
>> This was the only package message logged, and yet we ended up with
>> newer versions.
>>
>>
>>
>> Matthew Barr Technical Architect E: mb...@snap-interactive.com AIM:
>> matthewbarr1 c: (646) 727-0535
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlARkCUACgkQ5xgg9J6hpUt/qACg2oEH5x7qEb2X9YxFbYZh9i+G
> Q6EAnRiwQY4bpqKc+SLA6XgUm7z/LJ/S
> =8Sxe
> -----END PGP SIGNATURE-----
>

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.

> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.

[jcbollinger]

On Thursday, July 26, 2012 9:57:27 AM UTC-5, Michael Stanhke wrote:

Did something else pull that package in as a dependency?

That is what I'm inclined to think, Matthew's denial notwithstanding.  It is at any rate exactly the behavior that would be expected if some other package were installed or updated that required newer versions of the packages in question.  Puppet knows about and logs only the package it actually requests.

Furthermore, it does not follow from the failure to install the one new package that no other packages were updated in that run.  If yum performed dependency resolution successfully and download all the needed packages, then it would have started installs.  The requested package will always be installed last, because it depends directly or indirectly on everything else.  If one of the installs fails then yum will fail, but any packages that were successfully installed before the failure will remain installed.

This is all a good argument for maintaining your own repositories.  If you control the packages available for installation then you don't need to worry (as much) about unwanted updates.


John

[Jakov Sosic]

Maybe /var/log/yum.log can tell the story - if there is a list of
packages with prefix "Updated: " followed by the php-domxml with prefix
"Installed: " then it seems quite obvious what happened.

Also, Matthew should test the case on a development machine - install
the set of packages of older version, and then manually try to run yum
install php-domxml. It is enough that php-domxml requires package "php"
to recursively upgrade every php package on the system...



--
Jakov Sosic
www.srce.unizg.hr

[Jakov Sosic]

On 07/26/2012 09:24 PM, Michael Stahnke wrote:
> I can't reproduce this. I used sudo because it was out-of-date on my system.

Try to install php and all the modules pre-upgrade versions on some dev
machine and then run yum install php-domxml and observe what happens. I
bet it's the php-domxml that pulls latest "php" and in turn recursively
pulls everything else as upgrade to satisfy the newest "php".


--
Jakov Sosic
www.srce.unizg.hr

[Matthew Barr]

On Thu, Jul 26, 2012 at 4:52 PM, jcbollinger <John.Bo...@stjude.org> wrote:

That is what I'm inclined to think, Matthew's denial notwithstanding.  It is at any rate exactly the behavior that would be expected if some other package were installed or updated that required newer versions of the packages in question.  Puppet knows about and logs only the package it actually requests.

Furthermore, it does not follow from the failure to install the one new package that no other packages were updated in that run.  If yum performed dependency resolution successfully and download all the needed packages, then it would have started installs.  The requested package will always be installed last, because it depends directly or indirectly on everything else.  If one of the installs fails then yum will fail, but any packages that were successfully installed before the failure will remain installed.

This is all a good argument for maintaining your own repositories.  If you control the packages available for installation then you don't need to worry (as much) about unwanted updates.

I'm actually guessing this is what happened.  The docxml package is not present, and is actually obsoleted by php-xml, but I'm guessing that yum didn't say that early enough to have stopped a massive upgrade across all PHP packages.

And yes,  I'm well aware of the need to control your own repo's.  I don't control these systems sufficiently to be able to do that for all my repo's, but it's the first thing we're doing for the new datacenter we're building.  

It was an odd set of circumstances, which led to a package failing to install, but actually requiring newer versions.

I'm glad that the default is to use present, which overall means that the issue is.. moot... and the problem was caused by a bad list of yum packages to install that I got from documentation from a predecessor.  

Oh what fun it is to move to using config mgmt ;)  So much simpler to do it on clean builds!