On Wed, Jul 14, 2010 at 11:54 PM, Al Tobey <[email protected]> wrote:
> On Wed, Jul 14, 2010 at 11:44 PM, Matt Robinson <[email protected]> wrote:
>> Hi Al,
>> I know there was a bug with diffs that was fixed after RC1.  Have you tried
>> out the latest RC3?
>> http://puppetlabs.com/downloads/puppet/puppet-2.6.0rc3.tar.gz
>> or straight from the source http://github.com/reductivelabs/puppet
>> Let us know if that doesn't do anything for you.
>> Also, why are you using Puppet to manage your puppet.conf?  There may be a
>> use case for that so I'm curious, but my gut reaction is that it's a bad
>> idea.
>
> Mostly at this point it's just something I can have puppet manage on
> systems without messing with anything else since this is a new
> deployment.    Is there a better way to manage changes to puppet.conf?
>
> I'll install RC3 in the morning and give it another go.

I could swear I reproduced this under webrick on Monday, but now on
RC3 it looks like it only fails (404 in access.log for file_content)
when running in mod_passenger.   The issue seems to have been
resolved.

Thanks,
-Al

>> Matt
>>
>> On Tue, Jul 13, 2010 at 5:29 PM, Al Tobey <[email protected]> wrote:
>>>
>>> I started out a fresh puppet deployment hoping to use environments
>>> since I already have dev/test infrastructure I can match puppet
>>> environments to.   Right away, my puppet module broke, truncating
>>> puppet.conf to 0 bytes on every run, with the diff showing a diff
>>> against an empty file.     This is on CentOS 5 using Puppet 2.6.0rc1
>>> with two local patches to make my CA work.    Nothing is jumping out
>>> to me as a culprit in the logs besides the 404 on file_content.   If I
>>> flatten my configuration and remove the usage of environments, it
>>> works as expected and copies the file down from the server.
>>>
>>> I'm starting with 2.6.0 since this is a totally new deployment that
>>> won't go into production until after 2.6.1 is released.
>>>
>>> Any ideas?
>>>
>>> agent> puppet agent --server puppet.mydomain.com --logdest console
>>> --test --environment development -d
>>>
>>> master> cat /etc/puppet/puppet.conf
>>> [main]
>>>    vardir = /var/lib/puppet
>>>    logdir = /var/log/puppet
>>>    rundir = /var/run/puppet
>>>    ssldir = $vardir/ssl
>>>    templatedir = /etc/puppet/templates
>>>    environment = production
>>>    modulepath = /etc/puppet/modules
>>>    certificate_revocation = true
>>>    # these two options are implemented in local patches
>>>    localcacertdir = /etc/puppet/ca
>>>    certificate_revocation_shallow = true
>>>
>>> [production]
>>>    manifest = /etc/puppet/env/production/site.pp
>>>    modulepath = /etc/puppet/env/production/modules:/etc/puppet/modules
>>>    server = puppet.mydomain.com
>>>    trace = false
>>>    report = true
>>>
>>> [testing]
>>>    manifest = /etc/puppet/env/testing/site.pp
>>>    modulepath = /etc/puppet/env/testing/modules:/etc/puppet/modules
>>>    server = cwmops-puppet.mydomain.com
>>>    trace = false
>>>    report = false
>>>
>>> [development]
>>>    manifest = /etc/puppet/env/development/site.pp
>>>    modulepath = /etc/puppet/env/development/modules:/etc/puppet/modules
>>>    server = puppet.mydomain.com
>>>    trace = true
>>>    report = false
>>>
>>> [agent]
>>>    report = true
>>>
>>> [master]
>>>    environments = production, testing, development
>>>    ssl_client_header = SSL_CLIENT_S_DN
>>>    ssl_client_verify_header = SSL_CLIENT_VERIFY
>>>    storeconfigs = true
>>>    dbadapter = sqlite3
>>>    dblocation = /var/lib/puppet/storeconfigs.sqlite
>>>    reports = log
>>> #EOF
>>>
>>> master> cat /etc/puppet/env/development/modules/puppet/manifests/init.pp
>>> class puppet {
>>>    package {
>>>        puppet: ensure => installed;
>>>        openssl: ensure => installed;
>>>    }
>>>    file { "/etc/puppet/puppet.conf":
>>>        source => "puppet:///modules/puppet/puppet.conf",
>>>        owner => root,
>>>        group => root,
>>>        mode => 644
>>>    }
>>> }
>>> #EOF
>>>
>>> master> cat /etc/puppet/fileserver.conf
>>> [modules]
>>>        allow 10.0.0.0/8
>>> #EOF
>>>
>>> master> tail /var/log/httpd/access.log
>>> 10.0.0.1 - - [13/Jul/2010:16:08:26 -0700] "GET
>>>
>>> /development/catalog/testbox.mydomain.com?facts_format=b64_zlib_yaml&facts=...
>>> HTTP/1.1" 200 3437 "-" "-"
>>> 10.0.0.1 - - [13/Jul/2010:16:08:35 -0700] "GET
>>> /development/file_metadata/modules/puppet/puppet.conf HTTP/1.1" 200
>>> 316 "-" "-"
>>> 10.0.0.1 - - [13/Jul/2010:16:08:35 -0700] "GET
>>> /development/file_content//modules/puppet/puppet.conf HTTP/1.1" 404 55
>>> "-" "-"
>>> 10.0.0.1 - - [13/Jul/2010:16:08:35 -0700] "GET
>>> /development/file_metadata/modules/puppet/puppet.conf HTTP/1.1" 200
>>> 316 "-" "-"
>>> 10.0.0.1 - - [13/Jul/2010:16:08:36 -0700] "PUT
>>> /development/report/testbox.mydomain.com HTTP/1.1" 200 12 "-" "-"
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Puppet Developers" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected].
>>> For more options, visit this group at
>>> http://groups.google.com/group/puppet-dev?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-dev?hl=en.
>>
>

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

Reply via email to