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. 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. Thank you very much. John Guthrie jguthrie@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Aug 11, 2011 at 4:59 PM, John T. Guthrie <jguthrie@book.com> wrote:> 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?> 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 The facts you get from the client should also reside in $vardir/yaml/facts, and you can examine them to see what you have. Thanks, Nan -- 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.
Is your config facts_terminus=yaml for a reason? Usually its ''facter''. ken. On Thu, Aug 11, 2011 at 10:59 PM, John T. Guthrie <jguthrie@book.com> wrote:> 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. > > 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. > > Thank you very much. > > John Guthrie > jguthrie@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+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- "Join us for PuppetConf, September 22nd and 23rd in Portland, OR: http://bit.ly/puppetconfsig" -- 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 Thu, 2011-08-11 at 17:45 -0500, Nan Liu wrote:> On Thu, Aug 11, 2011 at 4:59 PM, John T. Guthrie <jguthrie@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.htmlWhen 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, > > NanThank you very much for all of your help so far. Sincerely, John Guthrie jguthrie@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thanks for the quick response. That was something more out of desperation. I saw something on the page with regarding the inventory service that facts_terminus would cause it to get facts from a yaml repository. I am having the same issue regardless of whether I use facts_terminus = yaml or the default of facts_terminus = facter. Thanks very much. John Guthrie jguthrie@book.com On Thu, 2011-08-11 at 23:48 +0100, Ken Barber wrote:> Is your config facts_terminus=yaml for a reason? Usually its ''facter''. > > ken. > > On Thu, Aug 11, 2011 at 10:59 PM, John T. Guthrie <jguthrie@book.com> wrote: > > 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. > > > > 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. > > > > Thank you very much. > > > > John Guthrie > > jguthrie@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 <jguthrie@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 > jguthrie@book.comHello 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 jguthrie@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.