Issue #1291 has been updated by luke.
Status changed from Accepted to Code Insufficient
This patch can't actually be working -- 'sort_by' doesn't modify the array, so
you're just not sorting the list at all.
You'd need to reassign the array, something like <code>@resolves =
@resolves.sort_by { |a| -a.length }</code>.
Also, this causes a few test failures:
<pre>
1)
NoMethodError in 'Facter::Util::Fact when adding resolution mechanisms should
create a new resolution instance'
undefined method `-@' for nil:NilClass
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `add'
/Users/luke/git/facter/spec/../vendor/gems/mocha-0.5.6/lib/mocha/class_method.rb:33:in
`sort_by'
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `each'
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `sort_by'
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `add'
/Users/luke/git/facter/spec/unit/util/fact.rb:48:
integration/facter.rb:5:
2)
NoMethodError in 'Facter::Util::Fact when adding resolution mechanisms should
instance_eval the passed block on the new resolution'
undefined method `-@' for nil:NilClass
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `add'
/Users/luke/git/facter/spec/../vendor/gems/mocha-0.5.6/lib/mocha/class_method.rb:33:in
`sort_by'
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `each'
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `sort_by'
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `add'
/Users/luke/git/facter/spec/unit/util/fact.rb:56:
integration/facter.rb:5:
3)
'Facter::Util::Fact when adding resolution mechanisms should re-sort the
resolutions by length, so the most restricted resolutions are first' FAILED
expected: [#<Mock:r2>, #<Mock:r1>, #<Mock:r3>],
got: [#<Mock:r1>, #<Mock:r2>, #<Mock:r3>] (using ==)
/Users/luke/git/facter/spec/unit/util/fact.rb:68:
integration/facter.rb:5:
4)
Mocha::ExpectationError in 'Facter::Util::Fact when returning a value should
return nil if the value is the empty string'
#<Mock:r1>.length() - expected calls: 0, actual calls: 1
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `add'
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `each'
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `sort_by'
/Users/luke/git/facter/spec/../lib/facter/util/fact.rb:46:in `add'
/Users/luke/git/facter/spec/unit/util/fact.rb:120:
integration/facter.rb:5:
</pre>
----------------------------------------
Bug #1291: Facter is using the NIS domain name instead of DNS domain name in
some cases
http://projects.reductivelabs.com/issues/show/1291
Author: admin
Status: Code Insufficient
Priority: Normal
Assigned to: luke
Category: library
Target version:
Complexity: Unknown
Keywords:
It looks like the code around:
* http://reductivelabs.com/cgi-bin/facter.cgi/browser/trunk/lib/facter.rb#L692
is looking for the DNS domain name, however that line invokes the "domainname"
command, which at least the Debian GNU/Linux and AIX man pages make clear
returns the NIS domain name (the Solaris man page is convoluted but seems to
say that as well).
In any case, at my site we have a historical NIS domainname that is totally
different from our DNS domainname, so this makes things confusing. There are
also cases where this would just break things (e.g. we have box.foo.com and
box.bar.com both in the NIS domain baz.com, so the first puppetized machine
would get a SSL cert for box.baz.com, and the second one would have problems)
On Debian there is the dnsdomainname command, however the only thing I've found
that works consistantly on all of my site's myriad operating system/version
combinations is to do a double lookup (e.g. get the host's IP address, and then
perform a lookup of that IP address); that way at least you'll get whatever
nsswitch.conf or equivalent thinks your IP address resolves to, which is usualy
what you'll be using when doing any debugging, and which is usually also
resolvable by the other machines on the network.
----------------------------------------
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://reductivelabs.com/redmine/my/account
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" 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-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---
