From: Sam Roberts <sroberts@...>
Date: 2005-01-17T09:22:29+09:00
Subject: bug -- resolv.rb dies when "domain" in resolv.conf has no arg

Example input:

-- domain.rb --
domain 
nameserver 1.2.3.4
--

What happens with an unpatched resolv.rb is:

[ensemble] ~/p/ruby/zeroconf $ ruby18 -rresolv -rpp -e '(r=Resolv::DNS::Config.new("./domain.conf")).lazy_initialize; pp r'
/usr/local/lib/ruby/1.8/resolv.rb:921:in `split': private method `scan' called for nil:NilClass (NoMethodError)
        from /usr/local/lib/ruby/1.8/resolv.rb:788:in `lazy_initialize'
        from /usr/local/lib/ruby/1.8/resolv.rb:788:in `map'
        from /usr/local/lib/ruby/1.8/resolv.rb:788:in `lazy_initialize'
        from /usr/local/lib/ruby/1.8/resolv.rb:761:in `synchronize'
        from /usr/local/lib/ruby/1.8/resolv.rb:761:in `lazy_initialize'
        from -e:1

Please don't tell me the resolv.conf synatx is invalid - these files are
automatically created by OS X's network system. Also, resolv.rb accepts
an empty nameserver and an empty search command without problems.

-- search.rb --
search
nameserver 1.2.3.4
--

Patch to fix this:

Index: 1.8-resolv.rb
===================================================================
--- 1.8-resolv.rb	(revision 5)
+++ 1.8-resolv.rb	(working copy)
@@ -734,7 +734,7 @@
             when 'nameserver'
               nameserver += args
             when 'domain'
-              search = [args[0]]
+              search = args[0, 1]
             when 'search'
               search = args
             end
===================================================================

Without this patch, @search becomes [nil] when domain had no arguments,
causing death later.

This can be tested with:

ruby18 -r1.8-resolv -rpp -e '(r=Resolv::DNS::Config.new("./search.conf")).lazy_initialize; pp r'
ruby18 -r1.8-resolv -rpp -e '(r=Resolv::DNS::Config.new("./domain.conf")).lazy_initialize; pp r'

You can see the behaviour before/after the patch.

Note that search (before) and domain (now, instead of dieing) with no
arguments both surpress the automagical choice of a search path based on
Socket.hostname. I believe this to be the correct behaviour, because it
seems reasonable to want to surpress the lookup (as a config option),
and because this is how the OS X C library resolver behaves.

Thanks,
Sam