Re: unable to get /etc/resolv.conf and /etc/network/interfaces configured properly in wheezy
On Wed, Aug 21, 2013 at 4:28 PM, Bob Proulx <bob@proulx.com> wrote:
> Tom H wrote:
>> On Tue, 20 Aug 2013 18:17:11 -0600, Bob Proulx wrote:
>> > Tom H wrote:
>> >> Mark Copper wrote:
>> >>> Tom H wrote:
>> >>>> You have "allow-hotplug eth0:0" without an "iface eth0:0 ..." line.
>
> I think the problem was the other way around. It was allow-hotplug
> eth0:0 when it should have been eth0:1.
>
>> >>> I think I do, but why is it necessary? I thought it was only for
>> >>> dynamic changes. and this server never needs them.
>> >>
>> >> "iface ..." defines the interface and "allow-hotplug ..." allows
>> >> udev to hotplug it. Without "iface ...", "allow-hotplug ..." is of
>> >> no use. You must have meant to have "allow-hotplug eth0:1", not
>> >> "allow-hotplug eth0:0".
>> >
>> > Right. allow-hotplug is for udev. auto is for static boot. The
>> > presence of "auto" should work at boot time since eth0:1 was listed in
>> > the first auto line.
>>
>> I wasn't clear. The "allow-hotplug eth0:0" line's of no use without
>> an "iface eth0:0 ..." line.
>
> Right. But the interface described is eth0:1 and that is there and
> also has an auto line. Twice.
>
> Let's face it, the file was a little bit generally messed up. The
> indention was confusing. It needed some cleanup. I know we both
> understand the file format. We are just quibbling over which
> direction of mistake was made which isn't too interesting given that
> both mistake possibilities were not intended.
>
>> >>> strange, but it's in the wiki.
>> >>
>> >> I'm sorry. I've just looked at the wiki and I didn't know that there
>> >> was a new (?) iproute configuration style.
>> >
>> > I think that is a new ifupdown configuration style. It was ifupdown
>> > that changed. AFAIK iproute is the same.
>> > s/iproute/ifupdown/
>> > For reference see:
>> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717878
>> > And:
>> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717887
>>
>> No time for the references right now but thanks. I'll check them out
>> some time between now and Sunday... :)
>>
>> I _AGAIN_ wasn't clear; sorry.
>>
>> I meant that now that ifupdown is using iproute's "ip" rather than
>> net-tools' "ifconfig" and "route", it can now assign more than one
>> ip address to a nic without appending ":X" to the nic's name.
>
> Yes.
>
> $ strings /sbin/ifup | grep -c '\<ip\>'
> 42
>
> $ strings /sbin/ifup | grep '\<ip\>' | head
> ip link set dev %iface% down
> ip link set dev %iface% up
> ip tunnel del %iface% /sbin/ip
> ip tunnel add %iface% mode %mode% remote %endpoint% [[local %local%]] [[ttl %ttl%]]
> ip link set %iface% up [[mtu %mtu%]]
> ip addr add %address%/%netmask% dev %iface% [[peer %dstaddr%]] [[ ip route add default via %gateway% ]]
> ip addr add %address%[[/%netmask%]] [[broadcast %broadcast%]] [[peer %pointopoint%]] [[scope %scope%]] dev %iface% label %iface%
> ip link set dev %iface% [[mtu %mtu%]] [[address %hwaddress%]] up
>
> $ strings /sbin/ifup | grep '\<ifconfig\>'
> ifconfig %iface% down
>
> Older Debian:
>
> $ strings /sbin/ifup | grep -c ifconfig
> 10
>
> It uses 'ip' now.
>
> Bob
How this worked out for me:
Data center provided KVM over IP. I was able to restore
/etc/network/interfaces to "proper" form for ifconfig and restart
networking. (Cool.)
As an aside, right there in the networking chapter of the debian
manual under "The basic syntax of /etc/network/interfaces" is says in
no uncertain terms, **Warning** Do not define duplicates of the
"iface" stanza for a network interface in /etc/network/interfaces!
Something I clearly violated in aping the new IP-related syntax.
The strange thing was that it didn't shut down the entire card. The
(master) nameserver kept working fine whilst port 22 was unavailable.
So I was unable to pull back to my old server in this botched
transition.
The other amusing thing (in hindsight!) was how far afield I got from
the actual root of my problem. In the 5 years since I set it up, the
Perl module LWP::UserAgent ssh handling moved away from Net::SSL to
IO::Socket::SSL. So requests were hanging, and seeing (IPv6 related)
resolution errors logged from named and no nameservers in
/etc/resolv.conf, I was off and running in a totally erroneous
direction. Ah, well.
However, I am deeply appreciative of the information offered in this
thread. I don't understand it all yet, but I have learned a lot that
has helped with other nagging problems.
Mark
Reply to: