Puppet users - Jul 2012 - Trouble installing packages with Puppet on Arch Linux

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'']

Any help is greatly appreciated!

Thanks in advance!

Cheers,
Matthew Rayfield 

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/UnEw_SqAgb4J.
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 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


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/xKGIUEzr_y0J.
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 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

On Monday, July 9, 2012 4:58:18 PM UTC-4, jcbollinger
wrote:
>
>
>
> 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
>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/fIRv-frG4dwJ.
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 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

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/sIeauv5nqQ4J.
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.