On Wed, Aug 21, 2013 at 4:28 PM, Bob Proulx <b...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAM-_Jt=hibztiyc5q5bcfd3m8ca6ar0jfz2rjkce4b8ospj...@mail.gmail.com