Mark Copper wrote:
> Bob Proulx wrote:
> >> Neither worked after a networking reload/restart.
> >
> > Just to clarify. You are on the system console. You are not working
> > over the network to the machine, right? You can restart networking as
> > you need?
>
> the machine is remote. remote hands are available to me (but
> communication can be a problem since I don't have a remote console
> available).
Ugh. I feel your pain. So you should be careful with the setup.
I recommend playing with a local victim machine first. Be familiar
with the changes you wish to make. Then after having them worked
through locally then you can transfer that configuration to the remote
machine. It is safer.
> >> Previously, my file followed this format for multiple IP addresses on
> >> a single nic like this (cf
> >> https://wiki.debian.org/NetworkConfiguration):
> >>
> >> auto eth0 eth0:1
> >>
> >> iface eth0 inet static
> >> address 192.168.1.42
> >> netmask 255.255.255.0
> >> gateway 192.168.1.1
> >> dns-nameservers 8.8.8.8
> >>
> >> auto eth0:1
> >> allow-hotplug eth0:0
> >> iface eth0:1 inet static
> >> address 192.168.1.43
> >> netmask 255.255.255.0
> >
> > The indention in the above is confusing. The indention does not
> > matter to the programs. But it is bad indention for humans reading
> > it. Always put the "auto", "allow-hotplug", "iface" lines at the same
> > left indention. Then for humans it is nice to indent additional lines
> > associated with the "iface" line. And you have "auto eth0:1" set
> > twice. And you have eth0:1 set to allow-hotplug but you don't have
> > eth0 set to allow-hotplug.
>
> sorry---these stanzas were just cut and pasted from the wiki and
> intended only to show the original grammar used.
Those lines do not appear with the above indention in the wiki page
you pointed to. Perhaps from a different wiki page? Or perhaps when
you cut and pasted them you had trouble with the paste?
To be clear the wiki example for the old way is:
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.42
netmask 255.255.255.0
gateway 192.168.1.1
auto eth0:0
allow-hotplug eth0:0
iface eth0:0 inet static
address 192.168.1.43
netmask 255.255.255.0
auto eth0:1
allow-hotplug eth0:1
iface eth0:1 inet static
address 192.168.1.44
netmask 255.255.255.0
And for the new way:
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.42
netmask 255.255.255.0
gateway 192.168.1.1
iface eth0 inet static
address 192.168.1.43
netmask 255.255.255.0
iface eth0 inet static
address 192.168.1.44
netmask 255.255.255.0
And if you look back in the history of the page you will see an example
for the older version that uses "up" and "down" commands to run "ip"
as an external command to assign secondary IP addresses.
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.42
netmask 255.255.255.0
gateway 192.168.1.1
up ip addr add 192.168.1.43/24 dev eth0 label eth0:0
down ip addr del 192.168.1.43/24 dev eth0 label eth0:0
up ip addr add 192.168.1.44/24 dev eth0 label eth0:1
down ip addr del 192.168.1.44/24 dev eth0 label eth0:1
Personally I find that way simpler and looks nicer. Then there is
never a problem with interfaces and virtual interfaces getting out of
sync with each other. There is only ever one real interface and the
rest are simply slaved off of it. But others don't like it and like
the implementation of many virtual interfaces. And now in the current
version of ifupdown it knows itself how to handle this, apparently.
(I haven't tried it myself. But the maintainer wrote the new doc on
it that way so I assume it works that way.)
> >> but both /etc/init.d/networking reload and restart had separate
> >> problems besides not solving my resolv.conf problem.
> >
> > Problems such as?
>
> "restart" always generates the warning contained in
> /etc/init.d/networking.
> I've never actually had a problem with it,
> but I did not want to disallow one here.
What warning?
> "reload" warned that "eth0:1" was not brought up though apparently
> it was. "ifconfig" indicated it was up but the entry was
> truncated---and the interface show no functional impairment.
The ifconfig program may have problems with the new kernel interface.
I will quote from:
http://www.shorewall.net/Shorewall_and_Aliased_Interfaces.html
The traditional net-tools contain a program called ifconfig which is
used to configure network devices. ifconfig introduced the concept of
aliased or virtual interfaces. These virtual interfaces have names of
the form interface:integer (e.g., eth0:0) and ifconfig treats them
more or less like real interfaces.
The ifconfig utility is being gradually phased out in favor of the
ip utility which is part of the iproute package. The ip utility does
not use the concept of aliases or virtual interfaces but rather
treats additional addresses on an interface as objects in their own
right. The ip utility does provide for interaction with ifconfig in
that it allows addresses to be labeled where these labels take the
form of ipconfig virtual interfaces.
So you should look at interface status using 'ip' these days. The
ifconfig program does what it does but if other programs and kernel
interfaces do something different then ifconfig is getting left
behind. (shrug)
> >> auto eth0
> >> allow-hotplug eth0
> >> iface eth0 inet static
> >> address 192.168.1.42
> >> netmask 255.255.255.0
> >> gateway 192.168.1.1
> >> dns-nameservers 8.8.8.8
> >
> > All okay. Should start upon hotplugging. Should start at boot.
> >
> >> iface eth0 inet static
> >> address 192.168.1.43
> >> netmask 255.255.255.0
> >
> > This is missing "allow-hotplug eth0:1", "auto eth0:1", or both of those.
> > You will want to add one or both of those.
>
> That's exactly what makes the new grammar different!
Oops. You are right. I missed that you had slid over into the new
grammar. Sometimes we read what we expect to read and not what is
there. Sorry.
> >> Networking seemed OK reloading and restarting, but, sadly, not so when
> >> rebooting, apparently.
Should work on reboot too. Would definitely be good to test all on a
local victim machine. There may be a bug in the new way. It may be
Sid Unstable only and not available in Wheezy Stable. I don't know.
> > Suggestion 3:
> > Set up a local caching nameserver. This has many advantages. Every
>
> bind is running. is that be the reason why only 127.0.0.1 was in
> resolv.conf?
Yes. This is probably a confusing point. But if you have a local
caching nameserver then /etc/resolv.conf will only ever contain the
local address 127.0.0.1. (Or 0.0.0.0 in other cases.) Any DNS
nameservers configured will go into the caching nameserver
configuration.
In the case of resolvconf it places this information in the runtime
directory /var/run/bind/named.options. Look in that file and you will
see your configured nameservers. But the bind package maintainer
hasn't been very responsive of late years. Unfortuntely the bind
package and resolvconf do not play well together automatically due to
deficiencies in the bind9 packaging. Fortunately it is easy to edit
the bind9 configuration for it. Change the include statement from one
to the other and that is it.
> ...
> I don't understand this yet. will read docs.
I think it is likely that it has been working for you all along. It
was putting the information in the right place for having a local
caching nameserver installed.
> but syslog contained entries recording inability to
> resolve domain names.
That will be a separate problem. Try experiments and verify. I
usually use the bind9-host package's "host" command. But dig works
too. I find host easier to use since it involves less typing.
$ host localhost.
localhost has address 127.0.0.1
localhost has IPv6 address ::1
$ host www.debian.org
www.debian.org has address 128.31.0.51
www.debian.org has address 140.211.15.34
Does that work? If not please post the errors.
Bob
Attachment:
signature.asc
Description: Digital signature