I have added environment = production to all hosts puppet.conf file, but still get the same intermittent errors.
I seem to be able to trigger this issue by. 1) Restarting Apache, so passenger and puppetmasterd are refreshed 2) Confirming there are no rack processes by running passenger-status 3) Executing puppetrun on one of the clients. This will always give error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find class hosts in namespaces general at /etc/puppet/ default/roles.pp:5 on node opsynxsr0097.aus.optiver.com If i then check rack processes with passenger-status i see 1 process has started. I can then rerun puppetrun on the same client and it process its run fine. So it seems as though passenger is slow to respond to first client request. I wondering if at high activity time if it is also being overloaded and that is why im getting the issue on intermittent hosts? Any ideas or experience on something like this Nigel? Thanks for your help. On May 15, 11:08 am, Nigel Kersten <[email protected]> wrote: > On Fri, May 14, 2010 at 5:11 PM, josbal <[email protected]> wrote: > > Hi Nigel, > > > Yes i am using environments. I have a production (default) > > environement and a testing environment. > > > All my hosts us the production environment currently. > > > Here is what my puppetmasterd puppet.conf file looks like: > > > [main] > > # Where Puppet stores dynamic and growing data. > > # The default value is '/var/puppet'. > > vardir = /var/lib/puppet > > > # The Puppet log directory. > > # The default value is '$vardir/log'. > > logdir = /var/log/puppet > > > # Where Puppet PID files are kept. > > # The default value is '$vardir/run'. > > rundir = /var/run/puppet > > > # Where SSL certificates are kept. > > # The default value is '$confdir/ssl'. > > ssldir = $vardir/ssl > > > # Manifest Files for production servers > > manifest = /etc/puppet/default/site.pp > > modulepath = /etc/puppet/default/modules > > > pluginsync = true > > factpath = $vardir/lib/facter > > > [puppetd] > > # The file in which puppetd stores a list of the classes > > # associated with the retrieved configuratiion. Can be loaded in > > # the separate ``puppet`` executable using the ``--loadclasses`` > > # option. > > # The default value is '$confdir/classes.txt'. > > classfile = $vardir/classes.txt > > > # Where puppetd caches the local configuration. An > > # extension indicating the cache format is added automatically. > > # The default value is '$confdir/localconfig'. > > localconfig = $vardir/localconfig > > > # Allow puppetrunner to start catalogue run. > > listen = true > > > # Reporting for catalogue run. > > report = true > > > [puppetmasterd] > > reports = store > > storeconfigs = true > > dbadapter = mysql > > dbname = puppet > > dbuser = puppet > > dbpassword = puppet > > dbserver = localhost > > dbsocket = /var/lib/mysql/mysql.sock > > > ssl_client_header = SSL_CLIENT_S_DN > > ssl_client_verify_header = SSL_CLIENT_VERIFY > > > # Testing Environment > > [testing] > > > # Manifest Files for testing environment > > manifest = /etc/puppet/testing/site.pp > > modulepath = /etc/puppet/testing/modules > > > Do you mean if im using production environment i should put > > environment=production in to the client puppet.conf file, rather then > > let puppet select that environment as the default? > > So my experience may not be useful here, as I've come across some bugs when > you have one environment specified in the config file and another > environment is returned by a fact called 'environment'. I haven't had time > to nail them down into a bug report, and since I worked out external node > providers can access the client facts, I'm going to move towards the > provider setting the environment. > > Anyway, does this get resolved if you pass --environment production on the > command line or put it in the client config file? If so, then we're > probably both tickling the same bug. > > I don't see an actual production environment defined there though... > > > > > > > > > On May 15, 1:55 am, Nigel Kersten <[email protected]> wrote: > > > On Thu, May 13, 2010 at 7:55 PM, josbal <[email protected]> > > wrote: > > > > Have you found a solution to this problem? I am having the same issue > > > > after upgrading to puppet 0.25.4 and passenger. > > > > > The error message im getting is: Error 400 on SERVER: Not authorized > > > > to call find on /file_metadata/hp_psp/opsywnsr0099.aus.optiver.com.pem > > > > Could not retrieve file metadata for > > > > puppet:///hp_psp/opsywnsr0099.aus.optiver.com.pem > > > > > This will intermittently be reported on client's puppet runs and then > > > > the next run may work correctly. > > > > > Any help with this would be appreciated. > > > > Are you both using environments? How are you specifying the client > > > environment? If you specify it on the command line or in the config file > > > (assuming you aren't already) does this problem go away? > > > > > On Apr 11, 9:57 pm, Mark Nelson <[email protected]> wrote: > > > > > Hello > > > > > > I am using the following software - > > > > > > *Operating System: > > > > > > *Scientific Linux SL release 5.3 (Boron), Scientific Linux is a > > rebuild > > > > > of Redhat Enterprise > > > > > > *Ruby version:* > > > > > > ruby-shadow-1.4.1-7.el5.x86_64 > > > > > ruby-irb-1.8.5-5.el5_3.7.x86_64 > > > > > grub-0.97-13.2.x86_64 > > > > > ruby-libs-1.8.5-5.el5_3.7.x86_64 > > > > > ruby-rdoc-1.8.5-5.el5_3.7.x86_64 > > > > > ruby-1.8.5-5.el5_3.7.x86_64 > > > > > ruby-augeas-0.3.0-1.el5.x86_64 > > > > > ruby-ldap-0.9.7-3.el5.x86_64 > > > > > > *Puppet Version: > > > > > > *puppet-0.25.4-1.el5.noarch > > > > > puppet-server-0.25.4-1.el5.noarch > > > > > > I am getting an "Error 400 message" when I try to download a file > > from > > > > > the puppet server I'm getting the following error when running puppet > > > > > --test -dv > > > > > > err: //dns/File[/etc/resolv.conf]: Failed to retrieve current state > > of > > > > > resource: Error 400 on SERVER: Not authorized to call find on > > > > > /file_metadata/common/etc/resolv.conf Could not retrieve file > > metadata > > > > > for puppet://puppet/common/etc/resolv.conf: Error 400 on SERVER: Not > > > > > authorized to call find on /file_metadata/common/etc/resolv.conf at > > > > > /etc/puppet/manifests/classes/dns.pp:8 > > > > > > Running the puppermasterd in debug mode produces the following error > > > > > message > > > > > > info: mount[files]: allowing * access > > > > > err: Not authorized to call find on > > /file_metadata/common/etc/resolv.conf > > > > > > Both the client and the server are running on the same machine. > > There > > > > > are references to similar issues in puppet 0.25.1 I'm not sure if > > these > > > > > issues are fixed in 0.25.4 > > > > > > My configuration files are as follows - > > > > > > *Auth.conf * > > > > > > # inconditionnally allow access to all files services > > > > > # which means in practice that fileserver.conf will > > > > > # still be used > > > > > path /file > > > > > allow * > > > > > > *Fileserver.conf > > > > > > *[files] > > > > > path /etc/puppet/files > > > > > #allow *.int.tardis.cx > > > > > allow * > > > > > #deny *.examp > > > > > > Thanks > > > > > > Mark. > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Puppet Users" group. > > > > To post to this group, send email to [email protected]. > > > > To unsubscribe from this group, send email to > > > > [email protected]<puppet-users%2bunsubscr...@google > > > > groups.com> > > <puppet-users%2bunsubscr...@google groups.com> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/puppet-users?hl=en. > > > > -- > > > nigel > > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > [email protected]<puppet-users%2bunsubscr...@google > > groups.com> > > . > > > For more options, visit this group athttp:// > > 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 [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<puppet-users%2bunsubscr...@google > > groups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/puppet-users?hl=en. > > -- > nigel > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" 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 > athttp://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 [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-users?hl=en.
