Re: Trouble installing packages with Puppet on Arch Linux

[jcbollinger]

On Monday, July 9, 2012 1:02:43 PM UTC-5, Matthew Rayfield wrote:

Hey everyone,

I seem to be running into an error that I can't find an answer for.

I have a simple manifest that installs a few packages and then starts a few services. But it chokes while installing Nginx with this error:

err: /Stage[main]//Package[nginx]/ensure: change from purged to present failed: Could not set 'present on ensure: invalid byte sequence in US-ASCII at /tmp/vagrant-puppet/manifests/manifest.pp:11

If I run the manifest again, it will get to the next package and then have the same error with that package. BUT, if I run it a THIRD time, it finishes cleanly.

I'm pretty puzzled. I've done a good amount of searching, but haven't found anything useful about this error.

Here's my manifest:

exec { 'sudo pacman -Syuw --noconfirm':
    path => '/usr/bin',
}
package { 'mongodb':
    ensure => present,
}
package { 'nginx':
    ensure => present,
}
package { 'python-pymongo':
    ensure => present,
}
package { 'python-tornado':
    ensure => present,
}
package { 'supervisor':
    ensure => present,
}
service { 'mongodb':
    ensure    => running,
    enable    => true,
    hasstatus => false,
}
service { 'nginx':
    ensure    => running,
    enable    => true,
    hasstatus => false,
}
Exec['sudo pacman -Syuw --noconfirm'] -> Package['mongodb'] -> Package['nginx'] -> Package['python-pymongo'] -> Package['python-tornado'] -> Package['supervisor'] -> Service['mongodb'] -> Service['nginx']

I don't know much about Arch's peculiarities, and almost nothing about pacman, but if Puppet doesn't do the same thing every time then it means something about the target node changed between runs.

The error message Puppet emitted probably indicates that pacman returned a non-zero error code when Puppet tried to use it to install the package. It looks like a script associated with the package originally reported the error.  If that leaves pacman satisfied that the package is installed, however, then Puppet probably won't try to install it again the next time.  You'll have to decide for yourself whether the package is installed as it should be.  You can probably generate the same error running pacman by hand from the same starting system state.

Does pacman handle inter-package dependencies automatically (like yum, for instance)?  If so then you oughtn't to need all the relationships between the packages, and without those Puppet probably would have made it through the whole catalog on the first go.


John

[Matthew Rayfield]

Thanks for your reply jcbollinger!

I think that this could actually be a bug.

After reading your response I edited my manifest to only install the first package. I then went in and used pacman manually and noticed a pattern: The packages that were getting this error displayed "optional dependencies" after pacman ran. The packages with no optional dependencies installed fine through puppet. I'm wondering if somehow that display of text is breaking whatever confirmation-of-installation check puppet does.

I glanced at the source of pacman.rb, but I'm not a Ruby guy and couldn't figure where the problem could be. I'm thinking it might be higher up than pacman.rb.

I'll do a little more testing and submit a bug report after more confirmation.

Thanks,

Matthew Rayfield

[jcbollinger]

On Tuesday, July 10, 2012 2:16:14 PM UTC-5, Matthew Rayfield wrote:

Thanks for your reply jcbollinger!

I think that this could actually be a bug.

After reading your response I edited my manifest to only install the first package. I then went in and used pacman manually and noticed a pattern: The packages that were getting this error displayed "optional dependencies" after pacman ran. The packages with no optional dependencies installed fine through puppet. I'm wondering if somehow that display of text is breaking whatever confirmation-of-installation check puppet does.

Perhaps so.  Puppet's code is often tricky to follow, but it appears that when the pacman provider attempts to install a package, it executes the command

/usr/bin/pacman --noconfirm --noprogressbar -Sy <resource name>

in the "C" locale, captures the standard output in a file, and afterwards returns the full output as a (byte) string.  (Or it uses a slightly different command if you specify the 'source' parameter to install from a local file.)

I didn't check the wider scope to see what it ultimately does with the output, but it's reasonable to suppose (especially in light of the error message) that it passes it to an output routine.  I speculate that your pacman is generating non-ASCII output, and Puppet is failing the resource when it is therefore unable to log that output (because Ruby 1.8 is not very clueful about character encoding).

If I have guessed correctly, then that's a pretty significant bug (though that's an indication that my guess may be wrong): puppet should not fail resources on account of being unable to log the output.
 

I glanced at the source of pacman.rb, but I'm not a Ruby guy and couldn't figure where the problem could be. I'm thinking it might be higher up than pacman.rb.

See above.  Puppet providers can be a bit hard to follow because significant parts of them are either built dynamically or inherited from other places.

You will have seen in pacman.rb the command and options I described above.  It looks like you might be able to work around the bug by modifying pacman.rb to add 'q' to the pacman options (there appear to be three places to change).  If that solves the problem then that would be good support for my analysis above.

I urge you to file a bug on this issue, particularly if you can confirm, as it sounds like you can, that Puppet is indicating a resource failure where that resource actually succeeded.


John