Am trying to debug a weird issue...It seems that my custom facts generated when puppet agent is run against my test master are not the same as when run against my prod master. What could explain that? A bit more specifically, my custom facts are generated by the fact: http://www.devco.net/archives/2008/04/17/easy_per-machine_custom_facts_for_puppet.php I changed one line to allow for whitespace in the keys and values, like this: var = $1.strip and val = $2.strip if line =~ /^(.+)=(.+)$/ I synced up the configs between my test and prod masters, so everything should be the same... Still, when I run an agent against my test server I get correct facts, key1: val1... against prod master I get some buggy "key1 ": val1 I even removed all whitespace from my facts.txt, that the facts are generated out of, run the agent many times, still same behavior. Any idea what could be the cause? am sure its something left over for my earlier attempts.. but what? Thanks a lot. Mohamed. -- 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 removed my call to strip(), and somehow the old buggy facts still appear:
The custom fact that generates extra custom facts:
bash-3.00# cat /var/opt/csw/puppet/lib/facter/host_facts.rb
if File.exists?(''/GU/facts.txt'')
File.open(''/GU/facts.txt'').each do |line|
var = nil
value = nil
var = $1 and val = $2 if line =~ /^(.+)=(.+)$/
if var != nil && val != nil
Facter.add(var) do
setcode { val }
end
end
end
end
bash-3.00# cat /GU/facts.txt
gu_environment=unset
gu_app_oracle_rac=unset
gu_app_oracle_oem=unset
gu_app_gdoc=unset
gu_app_banner=unset
gu_app_bboard=unset
the buggy facts:
bash-3.00# cat /etc/mcollective/facts.yaml|grep gu_
"gu_app_bboard ": unset
gu_app_oracle_rac: unset
gu_app_gdoc: unset
"gu_app_oracle_oem ": unset
gu_app_banner: unset
"gu_environment ": unset
Any pointers highly appreciated.
Thanks.
On Sun, Apr 17, 2011 at 9:29 PM, Mohamed Lrhazi <lrhazi@gmail.com>
wrote:> Am trying to debug a weird issue...It seems that my custom facts
> generated when puppet agent is run against my test master are not the
> same as when run against my prod master. What could explain that?
>
> A bit more specifically, my custom facts are generated by the fact:
>
http://www.devco.net/archives/2008/04/17/easy_per-machine_custom_facts_for_puppet.php
>
> I changed one line to allow for whitespace in the keys and values, like
this:
>
> var = $1.strip and val = $2.strip if line =~ /^(.+)=(.+)$/
>
> I synced up the configs between my test and prod masters, so
> everything should be the same... Still, when I run an agent against my
> test server I get correct facts, key1: val1... against prod master I
> get some buggy "key1 ": val1
>
> I even removed all whitespace from my facts.txt, that the facts are
> generated out of, run the agent many times, still same behavior.
>
> Any idea what could be the cause? am sure its something left over for
> my earlier attempts.. but what?
>
> Thanks a lot.
> Mohamed.
>
--
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.
This was driving me nuts... I did an rm -rf /var/lib/puppet, on a
client machine, and after a rerun of puppet agent, the buggy facts
appear again.
when I run the agent against the test master, no buggy facts... and
then it hit me that I am using stored configs, and the facts are in
mysql db, but why would that effect the facts as generated on the
clients?
I dropped the puppet db and restarted the master, and viola! buggy
facts gone... almost, they still reappear as I must have one or two
nodes who are still generating them, but will fix soon.
anyone understand what I am talking about? :) What exactly is
happening? what I call buggy fact ar the once with extra whitespace in
them:
mysql> select concat(''['',name,'']'') from
fact_names where name like ''%gu_%'';
+------------------------+
| concat(''['',name,'']'') |
+------------------------+
| [gu_app_baner ] |
| [gu_app_banner] |
| [gu_app_bboard] |
| [gu_app_gdoc] |
| [gu_app_oracle_oem] |
| [gu_app_oracle_rac] |
| [gu_env] |
| [gu_environment] |
| [gu_host] |
+------------------------+
9 rows in set (0.00 sec)
On Sun, Apr 17, 2011 at 9:45 PM, Mohamed Lrhazi <lrhazi@gmail.com>
wrote:> I removed my call to strip(), and somehow the old buggy facts still appear:
>
> The custom fact that generates extra custom facts:
>
> bash-3.00# cat /var/opt/csw/puppet/lib/facter/host_facts.rb
> if File.exists?(''/GU/facts.txt'')
> File.open(''/GU/facts.txt'').each do |line|
> var = nil
> value = nil
>
> var = $1 and val = $2 if line =~ /^(.+)=(.+)$/
>
> if var != nil && val != nil
> Facter.add(var) do
> setcode { val }
> end
> end
> end
> end
>
> bash-3.00# cat /GU/facts.txt
> gu_environment=unset
> gu_app_oracle_rac=unset
> gu_app_oracle_oem=unset
> gu_app_gdoc=unset
> gu_app_banner=unset
> gu_app_bboard=unset
>
> the buggy facts:
> bash-3.00# cat /etc/mcollective/facts.yaml|grep gu_
> "gu_app_bboard ": unset
> gu_app_oracle_rac: unset
> gu_app_gdoc: unset
> "gu_app_oracle_oem ": unset
> gu_app_banner: unset
> "gu_environment ": unset
>
>
> Any pointers highly appreciated.
> Thanks.
>
> On Sun, Apr 17, 2011 at 9:29 PM, Mohamed Lrhazi <lrhazi@gmail.com>
wrote:
>> Am trying to debug a weird issue...It seems that my custom facts
>> generated when puppet agent is run against my test master are not the
>> same as when run against my prod master. What could explain that?
>>
>> A bit more specifically, my custom facts are generated by the fact:
>>
http://www.devco.net/archives/2008/04/17/easy_per-machine_custom_facts_for_puppet.php
>>
>> I changed one line to allow for whitespace in the keys and values, like
this:
>>
>> var = $1.strip and val = $2.strip if line =~ /^(.+)=(.+)$/
>>
>> I synced up the configs between my test and prod masters, so
>> everything should be the same... Still, when I run an agent against my
>> test server I get correct facts, key1: val1... against prod master I
>> get some buggy "key1 ": val1
>>
>> I even removed all whitespace from my facts.txt, that the facts are
>> generated out of, run the agent many times, still same behavior.
>>
>> Any idea what could be the cause? am sure its something left over for
>> my earlier attempts.. but what?
>>
>> Thanks a lot.
>> Mohamed.
>>
>
--
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 4/18/2011 12:38 AM, Mohamed Lrhazi wrote:> This was driving me nuts... I did an rm -rf /var/lib/puppet, on a > client machine, and after a rerun of puppet agent, the buggy facts > appear again. > when I run the agent against the test master, no buggy facts... and > then it hit me that I am using stored configs, and the facts are in > mysql db, but why would that effect the facts as generated on the > clients? > I dropped the puppet db and restarted the master, and viola! buggy > facts gone... almost, they still reappear as I must have one or two > nodes who are still generating them, but will fix soon. > > anyone understand what I am talking about? :) What exactly is > happening? what I call buggy fact ar the once with extra whitespace in > them: > > mysql> select concat(''['',name,'']'') from fact_names where name like ''%gu_%''; > +------------------------+ > | concat(''['',name,'']'') | > +------------------------+(Is baner vs banner part of the issue here?)> | [gu_app_baner ] | > | [gu_app_banner] |It looks like you''re getting hit by the... let''s call it a quirk that mysql doesn''t consider trailing whitespace in equality tests. This means that when the database is checked to see if fact name ''gu_app_baner'' exists, the entry for ''gu_app_baner '' causes the query to return true. Here''s a demonstration: mysql> create table names (`name` varchar(255) NOT NULL); Query OK, 0 rows affected (0.07 sec) mysql> insert into names values ("foo "); Query OK, 1 row affected (0.00 sec) mysql> select concat(''['',name,'']'') from names where name = "foo"; +----------------------+ | concat(''['',name,'']'') | +----------------------+ | [foo ] | +----------------------+ 1 row in set (0.02 sec) Beyond that, I have no idea what other impacts the trailing space would cause within puppet. For what it''s worth, postgresql doesn''t display this behavior. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC -- 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.
That definitely explains the db part.. I still have no clue why the puppet agent ganerated facts would be effected by the database on the master though. Thanks a lot. On Mon, Apr 18, 2011 at 9:39 AM, Frank Sweetser <fs@wpi.edu> wrote:> On 4/18/2011 12:38 AM, Mohamed Lrhazi wrote: >> >> This was driving me nuts... I did an rm -rf /var/lib/puppet, on a >> client machine, and after a rerun of puppet agent, the buggy facts >> appear again. >> when I run the agent against the test master, no buggy facts... and >> then it hit me that I am using stored configs, and the facts are in >> mysql db, but why would that effect the facts as generated on the >> clients? >> I dropped the puppet db and restarted the master, and viola! buggy >> facts gone... almost, they still reappear as I must have one or two >> nodes who are still generating them, but will fix soon. >> >> anyone understand what I am talking about? :) What exactly is >> happening? what I call buggy fact ar the once with extra whitespace in >> them: >> >> mysql> select concat(''['',name,'']'') from fact_names where name like >> ''%gu_%''; >> +------------------------+ >> | concat(''['',name,'']'') | >> +------------------------+ > > (Is baner vs banner part of the issue here?) > >> | [gu_app_baner ] | >> | [gu_app_banner] | > > It looks like you''re getting hit by the... let''s call it a quirk that mysql > doesn''t consider trailing whitespace in equality tests. This means that > when the database is checked to see if fact name ''gu_app_baner'' exists, the > entry for ''gu_app_baner '' causes the query to return true. Here''s a > demonstration: > > mysql> create table names (`name` varchar(255) NOT NULL); > Query OK, 0 rows affected (0.07 sec) > > mysql> insert into names values ("foo "); > Query OK, 1 row affected (0.00 sec) > > mysql> select concat(''['',name,'']'') from names where name = "foo"; > +----------------------+ > | concat(''['',name,'']'') | > +----------------------+ > | [foo ] | > +----------------------+ > 1 row in set (0.02 sec) > > Beyond that, I have no idea what other impacts the trailing space would > cause within puppet. > > For what it''s worth, postgresql doesn''t display this behavior. > > -- > Frank Sweetser fs at wpi.edu | For every problem, there is a solution that > WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken > GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC > > -- > 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. > >-- 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.