Puppet users - Feb 2012 - strange service behaviour in kickstart chroot

This is a simple test code, named as ''a.pp'':

service { ''cups'':
  enable => false,
}

During RHEL kickstart process, I tried to run the above after doing "chroot
/mnt/sysimage"

If ''chkconfig --list cups'' shows cups is on, no mater how many
time you ran
"puppet apply a.pp", it always seems to see nothing for cups service,
nothing happened.

If ''chkconfig --list cups'' shows cups is not on, no matter how
many times
ran "puppet apply a.pp", it keeps trying to enable it all the time
with the
following picture:

notice: /Stage[main]//Service[cups]/enable: enable changed
''false'' to ''true''

Any way to fix the above?

-- 
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 Feb 14, 2:59 am, hai wu <haiwu...@gmail.com>
wrote:
> This is a simple test code, named as ''a.pp'':
>
> service { ''cups'':
>   enable => false,
>
> }
>
> During RHEL kickstart process, I tried to run the above after doing
"chroot
> /mnt/sysimage"
>
> If ''chkconfig --list cups'' shows cups is on, no mater how
many time you ran
> "puppet apply a.pp", it always seems to see nothing for cups
service,
> nothing happened.
>
> If ''chkconfig --list cups'' shows cups is not on, no
matter how many times
> ran "puppet apply a.pp", it keeps trying to enable it all the
time with the
> following picture:
>
> notice: /Stage[main]//Service[cups]/enable: enable changed
''false'' to ''true''
>
> Any way to fix the above?

I doubt Puppet is behaving as you describe with the manifest you
presented.  Puppet is behaving exactly as it would if you had
specified "enable => true".  In your real manifest, do you perhaps
have single or double quotes around "false"?  If so, remove them.
Also, since a chroot is involved, verify that you''re actually feeding
Puppet the manifest file you think you''re feeding it.


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.

There are no single or double quotes. That is the exact file I manually run
inside chroot environment during kickstart phase. I am kickstarting RHEL6U2
server, and in kickstart ssh access is turned on, so I could ssh into
chroot environment, and do "chroot /mnt/sysimage". When I manaully run
this
code:

service {''cups'':
  enable => true,
}

It would keep saying this all the time:

# puppet apply a.pp
notice: /Stage[main]//Service[cups]/enable: enable changed
''false'' to ''true''
notice: Finished catalog run in 0.23 seconds

This is causing me headache, no matter how many times I tried to run puppet
during kickstart phase, it would not converge, it would always try to
enable those services which are already enabled.

But if I ran the same a.pp on another server that''s already kickstarted
(not chroot), then things are working as expected. The above would only
show up once if cups service is not enabled.

The only thing I could see if during kickstart, the RHEL6U2 server is in
selinux permissive mode, while after kickstarting, it is in selinux disable
mode. But this should still work inside selinux permissive mode. I am using
Puppet 2.7.9.

On Tue, Feb 14, 2012 at 8:30 AM, jcbollinger
<John.Bollinger@stjude.org>wrote:
>
>
> On Feb 14, 2:59 am, hai wu <haiwu...@gmail.com> wrote:
> > This is a simple test code, named as ''a.pp'':
> >
> > service { ''cups'':
> >   enable => false,
> >
> > }
> >
> > During RHEL kickstart process, I tried to run the above after doing
> "chroot
> > /mnt/sysimage"
> >
> > If ''chkconfig --list cups'' shows cups is on, no
mater how many time you
> ran
> > "puppet apply a.pp", it always seems to see nothing for cups
service,
> > nothing happened.
> >
> > If ''chkconfig --list cups'' shows cups is not on, no
matter how many times
> > ran "puppet apply a.pp", it keeps trying to enable it all
the time with
> the
> > following picture:
> >
> > notice: /Stage[main]//Service[cups]/enable: enable changed
''false'' to
> ''true''
> >
> > Any way to fix the above?
>
>
> I doubt Puppet is behaving as you describe with the manifest you
> presented.  Puppet is behaving exactly as it would if you had
> specified "enable => true".  In your real manifest, do you
perhaps
> have single or double quotes around "false"?  If so, remove them.
> Also, since a chroot is involved, verify that you''re actually
feeding
> Puppet the manifest file you think you''re feeding it.
>
>
> 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.
>
>
-- 
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.

I tried the following by uninstalling puppet client rpm inside
kickstart chroot environment, and reinstalling the following puppet
agent rpm, and all of them are failing in the same way:

puppet-2.6.9-2.el6.noarch.rpm
puppet-2.7.9-1.el6.noarch.rpm
puppet-2.7.10-1.el6.noarch.rpm

On 2/14/12, hai wu <haiwu.us@gmail.com> wrote:
> This is a simple test code, named as ''a.pp'':
>
> service { ''cups'':
>   enable => false,
> }
>
> During RHEL kickstart process, I tried to run the above after doing
"chroot
> /mnt/sysimage"
>
> If ''chkconfig --list cups'' shows cups is on, no mater how
many time you ran
> "puppet apply a.pp", it always seems to see nothing for cups
service,
> nothing happened.
>
> If ''chkconfig --list cups'' shows cups is not on, no
matter how many times
> ran "puppet apply a.pp", it keeps trying to enable it all the
time with the
> following picture:
>
> notice: /Stage[main]//Service[cups]/enable: enable changed
''false'' to
> ''true''
>
> Any way to fix the above?
>
-- 
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.

Further troubleshooting shows that this is likely caused by ''chkconfig
cups'' command does not run well in kickstart chroot environment:

# chkconfig cups
cannot determine current run level

While the same command is working fine in a normal RHEL6 environment.
This is the file "puppet/provider/service/redhat.rb" where puppet is
using the output from "chkconfig cups" to check whether the service is
enabled or not, but since in chroot kickstart environment, there''s not
runlevel information, that command is failing.

Any ideas?

If not, I will have to file a bug report on this. It is not possible
to run puppet apply in kickstart chroot enviornment to converge the
configuration, no matter how many times you are going to run it. The
workaround is to run puppet apply one more time when the server comes
up after kickstarting, which is not ideal.

On 2/14/12, hai wu <haiwu.us@gmail.com> wrote:
> I tried the following by uninstalling puppet client rpm inside
> kickstart chroot environment, and reinstalling the following puppet
> agent rpm, and all of them are failing in the same way:
>
> puppet-2.6.9-2.el6.noarch.rpm
> puppet-2.7.9-1.el6.noarch.rpm
> puppet-2.7.10-1.el6.noarch.rpm
>
> On 2/14/12, hai wu <haiwu.us@gmail.com> wrote:
>> This is a simple test code, named as ''a.pp'':
>>
>> service { ''cups'':
>>   enable => false,
>> }
>>
>> During RHEL kickstart process, I tried to run the above after doing
>> "chroot
>> /mnt/sysimage"
>>
>> If ''chkconfig --list cups'' shows cups is on, no mater
how many time you
>> ran
>> "puppet apply a.pp", it always seems to see nothing for cups
service,
>> nothing happened.
>>
>> If ''chkconfig --list cups'' shows cups is not on, no
matter how many times
>> ran "puppet apply a.pp", it keeps trying to enable it all the
time with
>> the
>> following picture:
>>
>> notice: /Stage[main]//Service[cups]/enable: enable changed
''false'' to
>> ''true''
>>
>> Any way to fix the above?
>>
>
-- 
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.

I think this is confirmed now.

In kickstart chroot in RHEL6, ''runlevel'' would return this
output: "unknown".

If I change the binary ''/sbin/runlevel'' file with a shell
script after
backing it up first:

# cat /sbin/runlevel
echo "N 3"

Then everything is fine.

Also by replacing /var/run/utmp with similar file from another working
RHEL6U2 server, runlevel command is happy as well.

Sounds like a RedHat bug??



On 2/14/12, hai wu <haiwu.us@gmail.com> wrote:
> Further troubleshooting shows that this is likely caused by
''chkconfig
> cups'' command does not run well in kickstart chroot environment:
>
> # chkconfig cups
> cannot determine current run level
>
> While the same command is working fine in a normal RHEL6 environment.
> This is the file "puppet/provider/service/redhat.rb" where puppet
is
> using the output from "chkconfig cups" to check whether the
service is
> enabled or not, but since in chroot kickstart environment, there''s
not
> runlevel information, that command is failing.
>
> Any ideas?
>
> If not, I will have to file a bug report on this. It is not possible
> to run puppet apply in kickstart chroot enviornment to converge the
> configuration, no matter how many times you are going to run it. The
> workaround is to run puppet apply one more time when the server comes
> up after kickstarting, which is not ideal.
>
> On 2/14/12, hai wu <haiwu.us@gmail.com> wrote:
>> I tried the following by uninstalling puppet client rpm inside
>> kickstart chroot environment, and reinstalling the following puppet
>> agent rpm, and all of them are failing in the same way:
>>
>> puppet-2.6.9-2.el6.noarch.rpm
>> puppet-2.7.9-1.el6.noarch.rpm
>> puppet-2.7.10-1.el6.noarch.rpm
>>
>> On 2/14/12, hai wu <haiwu.us@gmail.com> wrote:
>>> This is a simple test code, named as ''a.pp'':
>>>
>>> service { ''cups'':
>>>   enable => false,
>>> }
>>>
>>> During RHEL kickstart process, I tried to run the above after doing
>>> "chroot
>>> /mnt/sysimage"
>>>
>>> If ''chkconfig --list cups'' shows cups is on, no
mater how many time you
>>> ran
>>> "puppet apply a.pp", it always seems to see nothing for
cups service,
>>> nothing happened.
>>>
>>> If ''chkconfig --list cups'' shows cups is not on,
no matter how many
>>> times
>>> ran "puppet apply a.pp", it keeps trying to enable it all
the time with
>>> the
>>> following picture:
>>>
>>> notice: /Stage[main]//Service[cups]/enable: enable changed
''false'' to
>>> ''true''
>>>
>>> Any way to fix the above?
>>>
>>
>
-- 
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 Feb 14, 8:41 am, hai wu <haiwu...@gmail.com>
wrote:
> There are no single or double quotes. That is the exact file I manually run
> inside chroot environment during kickstart phase. I am kickstarting RHEL6U2
> server, and in kickstart ssh access is turned on, so I could ssh into
> chroot environment, and do "chroot /mnt/sysimage". When I
manaully run this
> code:
>
> service {''cups'':
>   enable => true,
>
> }
>
> It would keep saying this all the time:
>
> # puppet apply a.pp
> notice: /Stage[main]//Service[cups]/enable: enable changed
''false'' to ''true''
> notice: Finished catalog run in 0.23 seconds

So the manifest you now show is not the same as the one in your
original message.  I completely believe that you see the behavior your
describe with the manifest you present this time.  That completely
changes the issue.

> This is causing me headache, no matter how many times I tried to run puppet
> during kickstart phase, it would not converge, it would always try to
> enable those services which are already enabled.

It looks like you are running into a variation on this issue:
http://projects.puppetlabs.com/issues/2712

Basically, Puppet''s service management is a bit deficient in that it
interprets the "enable" parameter as applying to the *current*
runlevel (only).  Puppet does not yet offer a mechanism for managing
service enablement in specific runlevels.  Based on your later posts,
I gather that Puppet may have trouble in your case determining what
the current runlevel actually is; that seems likely to elicit poor
behavior in light of Puppet''s shortcomings here.

Yours seems a good, new use case for the requested feature, so I
encourage you to comment about it in the bug tracker and vote for the
issue (now more than two years old and defered across two Puppet major
versions).


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.