I seem to be having a similar problem. See this thread...
http://groups.google.com/group/puppet-users/browse_thread/thread/271f6f6522524207/c90596d1823a1bbf We're also using Mongrel, and while the values aren't empty, they are plain wrong, at least for $puppetversion. The server and the client both have puppet 2.7.3, and $puppetversion is expanding to 0.25.5 when run through Mongrel. If I stop mongrel on the server, and run the puppet master in standalone mode, it resolves to '2.7.3'. Doug. On Aug 15, 11:15 am, "John T. Guthrie" <jguth...@book.com> wrote: > On Fri, 2011-08-12 at 14:31 -0400, John T. Guthrie wrote: > > On Thu, 2011-08-11 at 17:45 -0500, Nan Liu wrote: > > > On Thu, Aug 11, 2011 at 4:59 PM, John T. Guthrie <jguth...@book.com> > > > wrote: > > > Thank you very much for the quick response. > > > > > Hello all, > > > > > I am running puppet 2.7.1 with mongrel and an apache proxy. I have been > > > > seeing an issue where it appears that the puppetmaster is completely > > > > ignoring any facts that are sent to it. > > > > > When a client connects, any configuration that relies on facts shows > > > > those variables as being empty strings. (I have been testing this with > > > > a simple notify resource that prints out the IP address and the FQDN. > > > > Both of these are coming up as empty strings.) If I check the list of > > > > facts for a node through the REST API, it comes up as an empty list. > > > > Moreover, /var/lib/puppet/facts is persistently empty. This has been > > > > happening with every client that I have checked. > > > > Can you show your puppet manifests? Are you using $::ipaddress $::fqdn? > > > Here is the manifest code that I have been using for testing: > > > notify { > > "Echo-IP": > > message => "IP = $ipaddress", > > withpath => true; > > "Echo-fqdn": > > message => "FQDN = $fqdn", > > withpath => true; > > } > > > And here is the resulting output when I run puppetd --test: > > > notice: /Stage[main]/Subversion::Server/Notify[Echo-fqdn]/message: FQDN = > > notice: /Stage[main]/Subversion::Server/Notify[Echo-fqdn]/message: defined > > 'message' as 'FQDN = ' > > info: /Stage[main]/Subversion::Server/Notify[Echo-fqdn]: Scheduling refresh > > of (completed_Subversion::Server) > > notice: /Stage[main]/Subversion::Server/Notify[Echo-IP]/message: IP = > > notice: /Stage[main]/Subversion::Server/Notify[Echo-IP]/message: defined > > 'message' as 'IP = ' > > info: /Stage[main]/Subversion::Server/Notify[Echo-IP]: Scheduling refresh > > of (completed_Subversion::Server) > > > So no, I'm not using the $::ipaddress form of the facts. Should I be? > > I take it that this is a change since 0.24 or 0.25. (When I was last > > working with puppet.) > > > When I change one of the resources to read: > > > "Echo-IP": > > message => "IP = $::ipaddress", > > withpath => true; > > > I still get the same result: > > > notice: /Stage[main]/Subversion::Server/Notify[Echo-IP]/message: IP = > > notice: /Stage[main]/Subversion::Server/Notify[Echo-IP]/message: defined > > 'message' as 'IP = ' > > info: /Stage[main]/Subversion::Server/Notify[Echo-IP]: Scheduling refresh > > of (completed_Subversion::Server) > > > > > If run a packet capture on the puppetmaster paying attention to the > > > > puppetmaster ports, then I definitely see the puppetmaster receive the > > > > facts in b64_zlib_yaml format. I can even decode the facts string and > > > > get the correct set of facts. So the puppetmaster is definitely > > > > receiving the facts. However, in the same packet capture, I see the > > > > puppetmaster return json for resources as if it had not received any > > > > facts at all. > > > > > I have even gone so far as to blow away my entire /var/lib/puppet > > > > directory (except for the ssl), and try starting fresh to no avail. > > > > > Does anyone have any suggestions for how I can fix this? I am attaching > > > > my puppet.conf in case that will help. Thanks in advance for any advice > > > > that anyone has. > > > > Use this tip and see what puppet facts you are getting back on master: > > > >http://www.puppetcookbook.com/posts/see-all-client-variables.html > > > When I check this, no facts show up. Only variables that I have set > > manually or variables set by the server, like $serverip. > > > > The facts you get from the client should also reside in > > > $vardir/yaml/facts, and you can examine them to see what you have. > > > On the puppet master: > > # ls -l /var/lib/puppet/yaml > > total 4 > > drwxr-xr-x 2 puppet puppet 4096 Aug 11 15:48 node/ > > # ls -ld /var/lib/puppet/facts > > drwxr-xr-x 2 puppet puppet 4096 Aug 11 15:32 /var/lib/puppet/facts/ > > #ls -l /var/lib/puppet/facts > > total 0 > > > On the puppet client: > > # ls -l /var/lib/puppet/yaml > > ls: /var/lib/puppet/yaml: No such file or directory > > # ls -l /var/lib/puppet/facts > > total 0 > > > From what I can see, facts aren't being stored anywhere. > > > > Thanks, > > > > Nan > > > Thank you very much for all of your help so far. > > > Sincerely, > > > John Guthrie > > jguth...@book.com > > Hello all, > > I just tried this on an old testing machine that was running puppet > 2.7.0. (The above was on 2.7.1) I have confirmed again that the puppet > master is receiving the facts on the wire, however at some point they > are being discarded. I spent several hours this last week going through > code trying to find where they were disappearing to no avail. Could > someone please give me a pointer to where in the code, the puppet master > reads the catalog request off of the wire, so I can start tracing it's > data path through the code? (Or if someone has a better idea for doing > this, I'd be open to that too.) > > Thank you very much. > > John Guthrie > jguth...@book.com > > This electronic mail message contains information that (a) is or > may be CONFIDENTIAL, PROPRIETARY IN NATURE, OR OTHERWISE > PROTECTED > BY LAW FROM DISCLOSURE, and (b) is intended only for the use of > the addressee(s) named herein. If you are not an intended > recipient, please contact the sender immediately and take the > steps necessary to delete the message completely from your > computer system. > > Not Intended as a Substitute for a Writing: Notwithstanding the > Uniform Electronic Transaction Act or any other law of similar > effect, absent an express statement to the contrary, this e-mail > message, its contents, and any attachments hereto are not > intended > to represent an offer or acceptance to enter into a contract and > are not otherwise intended to bind this sender, > barnesandnoble.com > llc, barnesandnoble.com inc. or any other person or entity. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
