Re: [Puppet Users] Re: Exported resources applied on exporting host - EL7 only

[Trey Dockendorf]

And AH HA!  I did "grep -HnR "Firewall"
/etc/puppet/environments/production/modules/*/manifests/" and see the
problem, I'm using older version of puppetlabs-firewall that does
"Package['iptables-services'] -> Firewall <||>" for EL7.  I had not
pushed my fork to my "master", and what's worse is I'm the one who did
the PR to fix the autorequire :-X *face palm*.  Excuse my noise.

- Trey

> Alternatively, are you certain that there is no other Firewall<<| |>>
> collector somewhere in your manifests that might be picking up the rules at
> issue?
>
>
>
> John
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/3AaOJpPvGSI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/2880f45a-ae80-4ee2-99a2-a24a551961cc%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAN0oX1a4NT1LavNZAv7jv%3DaMBoctM5D06PN6fh5%3DkP3T9%3DxSXQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: puppetlabs_spec_helper 0.5.x breaks puppet-lint's ignore_paths ?

[Trey Dockendorf]

Thanks Jason.  I wasn't sure if there was some clever (and expected)
way to override what is set in puppetlabs_spec_helper and such user
error, or if this was a true bug.  Looks like a bug / regression.

- Trey

On Tue, Jul 1, 2014 at 10:06 AM, Jason Antman  wrote:
>  I'm also experiencing this issue. I've opened
> https://tickets.puppetlabs.com/browse/MODULES-1190 for it
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/MhrMGZU1-W4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/f1a1e6d6-345a-4605-a661-05415b2b5668%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAN0oX1Y70tiq%3DmFq4yNeHwvnZZB1CSscav-wF2PzNvHHpJvNvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: apache module class order issue with ENC

[Trey Dockendorf]

I was a bit vague in my report initially, will try to clarify.

The error about "undefined method >= for :undef" is due to using
version 1.0.1 of the module which did not have the fix for
MODULES-910.  The fact the value was :undef is the other issue.

The error "private method scan called on nil:NilClass" is indeed due
to the $apache_version being undefined, which should not be the case.
The bug I ran into on the stable version of the module would not have
occurred because if that value would have been correctly pulled from
$::apache::apache_version, the value would be 2.2 (CentOS 6.5).

I'm using only Foreman, no Hiera at this time.  Here is the relevant
lines outputted by Foreman:

---
classes:
  apache:
default_ssl_vhost: true
default_vhost: true
purge_configs: false
server_signature: 'Off'
server_tokens: Prod
trace_enable: 'On'
  apache::mod::ssl:
  apache::mod::wsgi:
wsgi_socket_prefix: /var/run/wsgi

Using puppetlabs-apache-1.0.1 and the above ENC output, I get the following

Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: undefined method `>=' for :undef:Symbol at
/etc/puppet/environments/production/modules/apache/manifests/mod/ssl.pp:35
on node web01.brazos.tamu.edu
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

(Yes I'm editing production by hand, but this infrastructure is still
non-production :-) )

This change was on the code from puppetlabs-apache-1.0.1 pulled from the forge.

--- production/modules/apache/manifests/mod/ssl.pp.orig 2014-06-24
09:36:57.085572966 -0500
+++ production/modules/apache/manifests/mod/ssl.pp  2014-06-24
09:38:28.356519037 -0500
@@ -1,8 +1,12 @@
 class apache::mod::ssl (
   $ssl_compression = false,
   $ssl_options = [ 'StdEnvVars' ],
-  $apache_version  = $::apache::apache_version,
 ) {
+
+  include ::apache
+
+  $apache_version  = $::apache::apache_version
+
   $session_cache = $::osfamily ? {
 'debian'  => '${APACHE_RUN_DIR}/ssl_scache(512000)',
 'redhat'  => '/var/cache/mod_ssl/scache(512000)',

The change above with the same ENC output results in no error.

Here's where things get interesting.  If I change my ENC output to
provide no parameters for apache::mod::wsgi, then I end up with all
variables using the $::apache:: reference being 'undef'.

ENC:

---
classes:
  apache:
default_ssl_vhost: true
default_vhost: true
purge_configs: false
server_signature: 'Off'
server_tokens: Prod
trace_enable: 'On'
  apache::mod::ssl:
  apache::mod::wsgi:

Error:

Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: Invalid relationship: File[wsgi.conf] { before => File[undef]
}, because File[undef] doesn't seem to be in the catalog
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

That seems like a bug in how Puppet is handling classes defined from an ENC.

Finally, if I go back to stock puppetlabs-apache-1.0.1 and define a
parameter for apache::mode::ssl ...

ENC:

---
classes:
  apache:
default_ssl_vhost: true
default_vhost: true
purge_configs: false
server_signature: 'Off'
server_tokens: Prod
trace_enable: 'On'
  apache::mod::ssl:
ssl_options:
- StdEnvVars
  apache::mod::wsgi:
wsgi_socket_prefix: /var/run/wsgi

NO ERRORS.

Thoughts?  It seems as though a class defined by an ENC with no
parameters is treated differently than a class defined with
parameters.  I'd expect and thought that a class with no parameters
was called in a similar was as doing "class { 'apache::mod::ssl': }".
Should this be filed as a bug against Puppet?

Thanks,
 - Trey


On Mon, Jun 23, 2014 at 8:47 AM, jcbollinger  wrote:
>
>
> On Sunday, June 22, 2014 12:43:20 AM UTC-5, treydock wrote:
>>
>> I'm attempting to use puppetlabs-apache with all my classes defined via
>> Foreman (1.5.1) with Puppet 3.4.3.  Servers are all CentOS 6.5.
>>
>> With puppetlabs-apache-1.0.1 when I applied both the apache class and
>> apache::mod::ssl class in Foreman I received this error on the server:
>>
>> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
>> undefined method `>=' for :undef:Symbol at
>> /etc/puppet/environments/production/modules/apache/manifests/mod/ssl.pp:36
>> on node web01.brazos.tamu.edu
>> Warning: Not using cache on failed catalog
>> Error: Could not retrieve catalog; skipping run
>>
>
>
> That error is simply complaining that one of the items being compared
> (presumably the $apache_version variable) was not numeric.  Note in
> particular that '2.2.0' is not numeric, whereas '2.2' is.
>
>
>>
>> I found the commit that changed how "apache_version" was handled and
>> deployed that and then I get:
>>
>
>
> Version numbers simply should not be compared via numeric comparison
> operators, so fixing the module to avoid that is certainly the right thing
> to do.  I have no clue what change you actually made, however.
>
>
>>
>> Error: Could not ret

Re: [Puppet Users] Re: Puppet under passenger constantly crashing

[Trey Dockendorf]

Sort of.  The normal Puppet+Passenger configuration still crashes, but
for some odd reason if I add the following to the Puppet config.ru
(after the --confdir and --vardir lines) the crashes stop...

ARGV << "--debug"
ARGV << "--trace"
ARGV << "--profile"
ARGV << "--logdest" << "/var/log/puppet/puppetmaster.log"

I made those changes to try and debug the problem with help on IRC
some time ago, and while the actual problem couldn't be found, those
options kept Passenger from crashing when running Puppet.  The full
config is at the end [1].

I have an almost identical Puppetmaster setup for a different
infrastructure, using same versions and same Puppet modules
(theforeman), that does not exhibit this behavior.  My hunch is that
this problematic Puppetmaster is suffering from configuration drift.
It was setup by hand a long time ago with various Rubygems installed
manually that are likely conflicting.  The system is now fully managed
but there are still some Rubygems installed that are not managed and
I've not taken the time to clean it up, but rather will eventually
rebuild this VM.

- Trey

[1]:
### Next part of the file is managed by a different template ###
## Module:   'puppet'
# a config.ru, for use with every rack-compatible webserver.
# SSL needs to be handled outside this, though.

# if puppet is not in your RUBYLIB:
# $LOAD_PATH.unshift('/opt/puppet/lib')

$0 = "master"

# if you want debugging:
# ARGV << "--debug"

ARGV << "--rack"

# Rack applications typically don't start as root.  Set --confdir and --vardir
# to prevent reading configuration from ~puppet/.puppet/puppet.conf and writing
# to ~puppet/.puppet
ARGV << "--confdir" << "/etc/puppet"
ARGV << "--vardir"  << "/var/lib/puppet"
ARGV << "--debug"
ARGV << "--trace"
ARGV << "--profile"
ARGV << "--logdest" << "/var/log/puppet/puppetmaster.log"

# NOTE: it's unfortunate that we have to use the "CommandLine" class
#  here to launch the app, but it contains some initialization logic
#  (such as triggering the parsing of the config file) that is very
#  important.  We should do something less nasty here when we've
#  gotten our API and settings initialization logic cleaned up.
#
# Also note that the "$0 = master" line up near the top here is
#  the magic that allows the CommandLine class to know that it's
#  supposed to be running master.
#
# --cprice 2012-05-22

require 'puppet/util/command_line'
# we're usually running inside a Rack::Builder.new {} block,
# therefore we need to call run *here*.
run Puppet::Util::CommandLine.new.execute

On Tue, Jun 10, 2014 at 6:59 AM, paul.gomersbach  wrote:
> Hi Treydock,
>
> Did you ever resolve this problem?
>
> Thanks!
>
> Op dinsdag 25 maart 2014 23:24:17 UTC+1 schreef treydock:
>>
>> As an update, I tried running 'puppet master --no-daemonize --debug' and
>> am seeing a segmentation fault running outside of passenger/apache...
>>
>> /usr/lib/ruby/site_ruby/1.8/puppet/parser/scope.rb:555: [BUG] Segmentation
>> fault
>> ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
>>
>> 
>>
>> /usr/lib/ruby/1.8/pathname.rb:287: [BUG] rb_gc_mark(): unknown data type
>> 0x10(0x935ce90) non object
>> ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
>>
>> This only seems occur most frequently when I run "puppet agent --test"
>> from the puppet master server.  Remote clients do not seem to crash puppet
>> master as frequently.
>>
>> On Tuesday, March 25, 2014 4:30:27 PM UTC-5, treydock wrote:
>>>
>>> I recently moved from manually configured Puppetmaster under passenger to
>>> fully managed using theforeman/puppet module.  Now I am experiencing
>>> constant crashes (every few minutes) of the passenger process that runs the
>>> puppetmaster.
>>>
>>> Host is CentOS 6.5 running Puppet 3.4.3.
>>>
>>> This is the entry I see in /var/log/httpd/puppet_error_ssl.log:
>>>
>>> [Tue Mar 25 16:25:26 2014] [error] [client 127.0.0.1] Premature end of
>>> script headers: production
>>>
>>> This is the entry I see in /var/log/httpd/error_log
>>>
>>> /usr/lib/ruby/site_ruby/1.8/puppet/parser/ast.rb:49: [BUG] rb_gc_mark():
>>> unknown data type 0x20(0x2e6b230) non object
>>> ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
>>>
>>> [ pid=28256 thr=139906534451168 file=ext/apache2/Hooks.cpp:841
>>> time=2014-03-25 16:25:26.86 ]: The backend application (process 32724) did
>>> not send a valid HTTP response; instead, it sent nothing at all. It is
>>> possible that it has crashed; please check whe.
>>>
>>> /etc/httpd/conf.d/passenger.conf:
>>>
>>> LoadModule passenger_module modules/mod_passenger.so
>>> 
>>>PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.19
>>>PassengerRuby /usr/bin/ruby
>>>PassengerTempDir /var/run/rubygem-passenger
>>> 
>>>
>>> /etc/httpd/conf.d/25-puppet.conf
>>> # 
>>> # Vhost template in module puppetlabs-apache
>>> # Managed by Puppet
>>> # 
>>>
>>> 
>>>   ServerName puppet
>>>
>>>   ## Vhost docroot
>>>   Docu

Re: [Puppet Users] puppet module permissions - librarian-puppet

[Trey Dockendorf]

I'm using 0022 on no both desktop and puppet master.

- Trey
On Apr 21, 2014 2:02 PM, "Robin Bowes"  wrote:

> What umask are you using?
>
> R.
> On 21 Apr 2014 19:18, "treydock"  wrote:
>
>> I have noticed lately that on my development system (OS X) and my
>> production Puppet master (CentOS 6.5) that when installing puppet modules
>> using librarian-puppet the permissions of some modules and files is very
>> restrictive to the point where the puppetmaster can't read the files.  Some
>> modules end up with all files being 0400, while some end up 0644 and some
>> 0664.  The files read-only to user are unable to be accessed by the
>> Passenger based Puppet master and the files that sometimes go from 0664 to
>> 0644 are creating a lot of noise in agent reports.
>>
>> Is there a "defacto" standard for the appropriate permissions, especially
>> for custom puppet providers/types/functions?  I've noticed that whatever
>> the permissions end up being on the master is what they get set to on the
>> clients.  I'm unsure if the permissions are being set by librarian-puppet,
>> the puppet module command, or some other mechanism.  The permissions are
>> always like this after a "bundle exec librarian-puppet install".  I've
>> since had to put a script in my librarian-puppet repo that executes a find
>> and modifies permissions, which does not seem right.
>>
>> Curious if anyone else has seen this or has suggestions for how to debug.
>>
>> Thanks
>> - Trey
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/bc4f86d5-0c65-4ec6-bc98-43f437a611e6%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/eFMjkVhBhZA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAJGKfwBxQ_OYmgq1UWbrwSHCTdxUd96epNC8AYiZm7D0VrkN3Q%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAN0oX1YEn7ked8gPTQFLGnWa__%2BaZnV7smbNYORESoKQr%3Dpw%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] facter's zpool_version errors using zfsonlinux

[Trey Dockendorf]

On May 7, 2013 4:48 AM, "Marc Fournier" 
wrote:
>
> Excerpts from treydock's message of 2013-05-06 20:04:16 +0200:
> > Has anyone run into an issue with zfsonlinux >= 0.6.1 failing to work
with
> > the Facter zpool_version fact?  I get the following error "Could not
> > retrieve zfs_version: undefined method `captures' for nil:NilClass"
which a
> > bug report [1] indicates was fixed.  I'm curious if it's a real issue.
 I
> > have a code change to contribute that has a seperate means of checking
> > zpool_version using "confine :kernel => "Linux"".  Should this be a new
bug
> > or attached to the other recent bug [1] ?
> >
> > Ran into with puppet-3.1.1 and facter-1.7.0
>
> Could you please open a new bug, and join the output of "zpool upgrade -v"
> and "zfs upgrade -v" on your system with zfsonlinux ?
>

Done, http://projects.puppetlabs.com/issues/20617


> > I believe the underlying problem is that the "zpool upgrade -v" in
> > zfsonlinux does not output the version number anymore.  Using a basic
> > "dmesg | grep 'ZFS:'" with the same "captures" line seems to work.  I
> > uploaded my module [2] with the proposed facter fact addition if someone
> > would like to confirm this.  I have only confirmed in vagrant tests,
> > haven't pushed to my Puppet master yet, but I saw the symptoms on my
live
> > systems.
>
> Basing facts on "dmesg | grep" seems quite fragile to me, as the messages
> will eventually get rotated away of the output of dmesg.
>
> Do you know if there are any other ways to get the zpool version, when
> using zfsonlinux ?

I couldn't find anything in /proc that had the zpool version, but did find
that the same parsing used to get the zfs_version fact works for
zpool_version.  However it may be a misleading fact because zfsonlinux
hardcodes zpool version to be 5000.

I can do a pull request for the changes to zpool_version.rb, but am unsure
if it's best to do a 'confine :kernel => "Linux"' to do the zpool upgrade
-v scan, or to modify the existing fact to use the same parsing method as
zfs_version.rb.


Thanks

- Trey

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

Re: [Puppet Users] Re: Catalog compile times > 40s - Puppet 2.7.18

[Trey Dockendorf]

On Dec 22, 2012 11:04 PM, "Michael Stahnke"  wrote:
>
> Puppet 3 has lots of performance improvements.  In many cases it's
> faster than 2.6.x was. Some of those fixes were back-ported to 2.7.20,
> but not all of them could be.
>
> For best performance, try out something in the Puppet 3 series.
>
>
>
> On Wed, Dec 19, 2012 at 8:30 AM, shurik  wrote:
> > Hi
> >
> > We are tried to update puppet master from 2.6.6 to 2.7.18 and saw
similar
> > picture. Catalog
> > compile time took ~60-120 seconds. Before this update compilation took
about
> > ~1-5 second.
> > After upgrade average CPU usage increased from 10-20% up to 20-40%,
during
> > some activity
> > (compilation?) ruby process puppetmasterd take 100% too.
> >
> > All, is there are some magic to solve or this is expected behaviour?
> >
> > Thanks!
> >
> > ---
> > Alexander
> >
> > On Saturday, December 15, 2012 10:23:49 PM UTC+4, treydock wrote:
> >>
> >>
> >>
> >> On Sunday, December 9, 2012 1:41:34 PM UTC-6, treydock wrote:
> >>>
> >>> I am finding that the puppetlabs-apache module is somehow adding 30-60
> >>> seconds onto a host's catalog compile time when the puppetmaster has
no
> >>> other hosts contacting or generating catalogs.  The Puppetmaster is
setup to
> >>> use Puppet-2.7.18 - Apache & Passenger.  RIght now only 2 hosts are
even
> >>> configured to use this new PM, the PM itself and a Foreman host.  With
> >>> neither hosts contacting the PM, and disabling the "include apache"
and
> >>> "require apache::mod::dev" in puppetlabs-passenger, I get "Config
retrieval:
> >>> 2.45".
> >>>
> >>> Catalogs had hostnames replaced, puppetmaster.tld is the CNAME for
Puppet
> >>> master and puppetmaster-host.tld is the actual hostname.
> >>>
> >>> Catalog: http://pastebin.com/V29JmB8J
> >>> # puppet agent --{summarize,test,debug,evaltrace,noop} | perl -pe
> >>> 's/^/localtime().": "/e'
> >>> 
> >>> Sun Dec  9 13:05:35 2012: notice: Finished catalog run in 2.43 seconds
> >>> Sun Dec  9 13:05:35 2012: Changes:
> >>> Sun Dec  9 13:05:35 2012: Events:
> >>> Sun Dec  9 13:05:35 2012: Total: 1
> >>> Sun Dec  9 13:05:35 2012:  Noop: 1
> >>> Sun Dec  9 13:05:35 2012: Resources:
> >>> Sun Dec  9 13:05:35 2012:   Out of sync: 1
> >>> Sun Dec  9 13:05:35 2012: Total: 22
> >>> Sun Dec  9 13:05:35 2012:   Skipped: 6
> >>> Sun Dec  9 13:05:35 2012: Time:
> >>> Sun Dec  9 13:05:35 2012: Resources: 0.00
> >>> Sun Dec  9 13:05:35 2012:Filebucket: 0.00
> >>> Sun Dec  9 13:05:35 2012:   Package: 0.00
> >>> Sun Dec  9 13:05:35 2012:  File: 0.00
> >>> Sun Dec  9 13:05:35 2012:  Firewall: 0.01
> >>> Sun Dec  9 13:05:35 2012:  Exec: 0.14
> >>> Sun Dec  9 13:05:35 2012:  Last run: 1355079935
> >>> Sun Dec  9 13:05:35 2012:Config retrieval: 2.45
> >>> Sun Dec  9 13:05:35 2012: Total: 2.61
> >>> Sun Dec  9 13:05:35 2012: Version:
> >>> Sun Dec  9 13:05:35 2012:Config: 1355077701
> >>> Sun Dec  9 13:05:35 2012:Puppet: 2.7.18
> >>>
> >>> Uncommenting "include apache" and "require apache::mod::dev" in
> >>> puppetlabs-passenger about 40 seconds are added to the compile time.
 I went
> >>> through disabled all modules and parameters, and found that enabling
the
> >>> passenger module alone with Apache included caused the huge delay.
> >>>
> >>> Catalog: http://pastebin.com/wwcKgX5b
> >>> # puppet agent --{summarize,test,debug,evaltrace,noop} | perl -pe
> >>> 's/^/localtime().": "/e'
> >>> 
> >>> Sun Dec  9 13:13:08 2012: notice: Finished catalog run in 2.23 seconds
> >>> Sun Dec  9 13:13:08 2012: Changes:
> >>> Sun Dec  9 13:13:08 2012: Events:
> >>> Sun Dec  9 13:13:08 2012: Total: 4
> >>> Sun Dec  9 13:13:08 2012:  Noop: 4
> >>> Sun Dec  9 13:13:08 2012: Resources:
> >>> Sun Dec  9 13:13:08 2012:   Out of sync: 4
> >>> Sun Dec  9 13:13:08 2012:   Skipped: 6
> >>> Sun Dec  9 13:13:08 2012: Total: 80
> >>> Sun Dec  9 13:13:08 2012: Time:
> >>> Sun Dec  9 13:13:08 2012:Filebucket: 0.00
> >>> Sun Dec  9 13:13:08 2012: Resources: 0.00
> >>> Sun Dec  9 13:13:08 2012:   Package: 0.00
> >>> Sun Dec  9 13:13:08 2012:  Firewall: 0.01
> >>> Sun Dec  9 13:13:08 2012:  File: 0.01
> >>> Sun Dec  9 13:13:08 2012: A2mod: 0.03
> >>> Sun Dec  9 13:13:08 2012:   Service: 0.07
> >>> Sun Dec  9 13:13:08 2012:  Exec: 0.14
> >>> Sun Dec  9 13:13:08 2012:  Last run: 1355080388
> >>> Sun Dec  9 13:13:08 2012:Config retrieval: 42.79
> >>> Sun Dec  9 13:13:08 2012: Total: 43.06
> >>> Sun Dec  9 13:13:08 2012: Version:
> >>> Sun Dec  9 13:13:08 2012:Config: 1355080261
> >>> Sun Dec  9 13:13:08 2012:Puppet: 2.7.18
> >>>
> >>>
> >>> The install is via RPM.  I'm using the Fedora SRPMs rebuilt for
CentOS 6.
> >>> The Puppet master has two environments, development and production
with this
> >>> a

[Puppet Users] Issue with "change from absent to present failed...no such file or directory"

[Trey Dockendorf]

I'm working on a DHCP module, modeled after this
https://github.com/camptocamp/puppet-dhcp .  Mine is just a much simpler
version as I don't manage multiple OSes in my environment.  However I cannot
get my subnet file to create, this is the error from debug I get

"err:
/Stage[main]/Fog_server/Dhcp::Subnet[10.1.0.1]/File[/etc/subnets/10.1.0.1.conf]/ensure:
change from absent to present failed: Could not set 'present on ensure: No
such file or directory - /etc/subnets/10.1.0.1.conf.puppettmp_5637 at
/etc/puppet/modules/dhcp/manifests/definitions/subnet.pp:18"

See below for the full output and my modules.

Been pulling my hair out for past day over this so any help is greatly
appreciated.

Thanks
- Trey


== modules/dhcp/manifests/init.pp ==
import "classes/*.pp"
import "definitions/*.pp"

class dhcp {
$dhcp_config_dir = "/etc/dhcp"

include dhcp::server
}

== modules/dhcp/manifests/classes/server.pp ==
class dhcp::server {

package {"dhcp":
ensure => present,
}

service {"dhcpd":
ensure  => running,
enable  => true,
require => Package["dhcp"],
}

file {"$dhcp_config_dir":
ensure  => directory,
source  => 'puppet:///dhcp/empty',
recurse => true,
purge   => true,
owner   => 'root',
group   => 'root',
mode=> '755',
require => Package['dhcp'],
}

file {"$dhcp_config_dir/subnets":
ensure  => directory,
source  => 'puppet:///dhcp/empty',
recurse => true,
purge   => true,
owner   => 'root',
group   => 'root',
mode=> '755',
notify  => Service['dhcpd'],
require => File["$dhcp_config_dir"],
}

file {"/etc/dhcpd.conf":
content => template("dhcp/dhcpd_conf.erb"),
ensure  => present,
require => Package["dhcp"],
notify  => Service["dhcpd"],
}

}

== modules/dhcp/manifests/definitions/subnets.pp ==
define dhcp::subnet (
$name=false,
$netmask=false,
$range_start=false,
$range_end=false,
$router=false,
$domain_name=false,
$dns_servers=false,
$pxe_opts=false) {

file {"/etc/subnets/$name.conf":
ensure  => present,
owner   => 'root',
group   => 'root',
content => template("dhcp/subnet_conf.erb"),
notify  => Service["dhcpd"],
require => File['/etc/dhcp/subnets'],
}
}

== manifests/roles.pp ==
class role_dhcp_server {
$my_role = "dhcp_server"

$dhcpd_domain_name = "tamu.edu"
$dhcpd_dns_servers = "0.0.0.0, 0.0.0.0"
$dhcpd_authoritative = true
$dhcpd_ddns_update = "interim"
$dhcpd_opts = [ 'allow booting', 'allow bootp', 'use-host-decl-names
on', 'ignore client-updates' ]

include dhcp

dhcp::subnet { "10.1.0.1":
name=> '10.1.0.1',
netmask => '255.255.255.0',
range_start => '10.1.0.10',
range_end   => '10.1.0.254',
router  => '10.1.0.1',
domain_name => 'tamu.edu',
dns_servers => "0.0.0.0, 0.0.0.0",
pxe_opts=> [ 'filename "pxelinux.0";' ],
}
}

== The error ==

# puppetd --test --debug -vvv
debug: Failed to load library 'ldap' for feature 'ldap'
debug: Puppet::Type::User::ProviderLdap: feature ldap is missing
debug: Puppet::Type::User::ProviderUser_role_add: file rolemod does not
exist
debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl does
not exist
debug: Puppet::Type::User::ProviderPw: file pw does not exist
debug: Failed to load library 'rubygems' for feature 'rubygems'
debug: Failed to load library 'selinux' for feature 'selinux'
debug: Puppet::Type::File::ProviderMicrosoft_windows: feature
microsoft_windows is missing
debug: /File[/var/lib/puppet/clientbucket]: Autorequiring
File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring
File[/var/lib/puppet/ssl/certs]
debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet]
debug: /File[/etc/puppet/namespaceauth.conf]: Autorequiring
File[/etc/puppet]
debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet]
debug: /File[/var/lib/puppet/state/last_run_summary.yaml]: Autorequiring
File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/state/last_run_report.yaml]: Autorequiring
File[/var/lib/puppet/state]
debug: /File[/var/log/puppet/http.log]: Autorequiring File[/var/log/puppet]
debug: /File[/var/lib/puppet/client_yaml]: Autorequiring
File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring
File[/var/lib/