network-admin does not do as much damage as it did before, but
unfortunately it still does some damage.
I have a simple laptop system: just the "lo" interface and a Wi-Fi
interface. I have a number of logical interfaces defined
in /etc/network/interfaces for the different networks that I connect to
and I can configure my Wi-Fi interface as these logical interfaces using
ifup. I also have several ppp logical interfaces defined but I don't
often use ppp interfaces any more.
# ifconfig |grep '^[^ ]'
lo Link encap:Local Loopback
wlanp_0 Link encap:Ethernet HWaddr 00:07:0E:B3:89:8E
# ifconfig -a |grep '^[^ ]'
lo Link encap:Local Loopback
wifi0 Link encap:UNSPEC HWaddr
00-07-0E-B3-89-8E-00-00-00-00-00-00-00-00-00-00
wlanp_0 Link encap:Ethernet HWaddr 00:07:0E:B3:89:8E
# cat /etc/network/run/ifstate
lo=lo
wlanp_0=decis-wireless-dhcp
# grep ^iface /etc/network/interfaces
iface lo inet loopback
iface decis-wired-static inet dhcp
iface decis-wireless-dhcp inet dhcp
iface ppp-Xircom-Mtl inet ppp
iface ppp-LT-DenHaag inet ppp
gnome-system-tools's network-admin module can't handle this simple case.
First I back up my networking configuration files because I know from
experience what n-a likes to do to them. Then I start up n-a and enter
the root password. For ten seconds I look at an entirely greyed-out
window and begin to wonder whether or not it has frozen. Finally a list
appears in the "Connections" pane:
Modem connection
The interface ppp0 is not configured
Wireless connection
The interface wifi0 is not configured
It is true that the ppp0 interface is not configured. It doesn't exist
on my system right now because I am not running a pppd. I decide not to
investigate network-admin's handling of PPP interfaces right now.
It is more or less true that wifi0 is not configured. I have a Cisco
Aironet card driven by the airo and airo-cs drivers. These drivers
create two network interfaces when they load: "wifi0" and "eth0". I
have configured ifrename to change the latter name to "wlanp_0". The
latter is configured; the former isn't really a different device. I
don't really mind the fact that wifi0 appears in the listing, but where
is wlanp_0?
OK, next I try something simple and easy -- I try changing the hostname
from 'thanatos' to 'thanatos1'. I answer affirmatively the question
whether or not I really want to do this. The program freezes for a
while and then, unexpectedly, exits. Has it crashed, or what? Let's
look at my configuration files.
# diff network/interfaces_PREGST network/interfaces
# diff hostname_PREGST hostname
1c1
< thanatos
---
> thanatos1
OK so far.
# diff -u hosts_PREGST hosts
--- hosts_PREGST 2005-06-19 17:54:43.000000000 +0200
+++ hosts 2005-06-24 10:36:30.000000000 +0200
@@ -1,4 +1,4 @@
-127.0.0.1 localhost.localdomain localhost
+127.0.0.1 localhost.localdomain localhost thanatos thanatos1
127.0.1.1 thanatos
192.168.1.1 lubbers
@@ -26,17 +26,17 @@
# 217.12.6.29 rc1.vip.ukl.yahoo.com
# DECIS
-130.161.177.97 sbs
+130.161.177.97 sbs
130.161.177.119 npi9f5253
# The following lines are desirable for IPv6 capable hosts
# (added automatically by netbase upgrade)
-fe00::0 ip6-localnet
-ff00::0 ip6-mcastprefix
-ff02::1 ip6-allnodes
-ff02::2 ip6-allrouters
-ff02::3 ip6-allhosts
+fe00::0 ip6-localnet ip6-localnet
+ff00::0 ip6-mcastprefix ip6-mcastprefix
+ff02::1 ip6-allnodes ip6-allnodes
+ff02::2 ip6-allrouters ip6-allrouters
+ff02::3 ip6-allhosts ip6-allhosts
# The following lines are desirable for IPv6 capable hosts
# (added automatically by netbase upgrade)
@@ -45,9 +45,3 @@
# The following lines are desirable for IPv6 capable hosts
# (added automatically by netbase upgrade)
-::1 ip6-localhost ip6-loopback
-fe00::0 ip6-localnet
-ff00::0 ip6-mcastprefix
-ff02::1 ip6-allnodes
-ff02::2 ip6-allrouters
-ff02::3 ip6-allhosts
#$*%$! The program has made a mess of my very simple and
straightforward /etc/hosts file! My existing hostname was on the
127.0.1.1 line; g-s-t has put the new hostname in as an alias for
localhost.localdomain instead. It has left the old hostname in on the
127.0.1.1 line. And most bizarrely of all it has _added_ the _old_
hostname in as an alias for localhost.localdomain!
It has replaced some tabs with spaces, unnecessarily.
It has stupidly duplicated host names on a group of lines beginning with
fe00::0.
It has deleted another group of lines for IPv6.
I see that the program has also touched /etc/host.conf. It didn't occur
to me to back _that_ file up. Why is network-admin touching that file?
It shouldn't.
I restore my configuration files from backups.
My next test is to see what happens when I change the DNS configuration
via network-admin. I have resolvconf installed, so /etc/resolv.conf is
a symlink to /etc/resolvconf/run/resolv.conf. I delete a nameserver
address and add an item to the "search" list and click OK. The program
pauses and then exits, and I am left again with a mangled hosts file
and, now, an altered /etc/resolvconf/run/resolv.conf file. Well, I am
relieved that network-admin has not deleted the symlink. I run
"resolvconf -u" to regenerate resolv.conf.
Once again network-admin has uselessly updated the ctime
on /etc/hosts.conf and also on /etc/hostname.
I restore my configuration files from backups. So far
my /etc/network/interfaces has remained intact. Time to take the big
risk. I don't have the option of modifying the configuration of wlanp_0
so I decide to see what happens if I assign an address to wifi0.
To my relief, network-admin only makes a small change.
# diff interfaces_PREGST interfaces
86a87,91
>
> iface wifi0 inet static
> address 127.0.2.2
> netmask 255.255.0.0
> gateway 127.0.2.1
That, at least, is an improvement. Because network-admin seems no
longer to mangle /etc/network/interfaces, I am closing #268334.
In conclusion, network-admin is less dangerous than before. It still
mangles the hosts file.
I would advise that network-admin not touch the hosts file at all when
updating the hostname or when the user makes any changes other than
editing the hosts database via the Hosts tab. As discussed recently[0]
on debian-boot, there is no good reason why the system hostname (a UNIX
feature predating DNS) should be resolvable as if it were a domain name.
A few programs expect that the hostname can be so resolved, but those
programs are buggy and bug reports have been filed against some of them.
More importantly, Debian does not support the resolving of system
hostname completely and cannot support it completely unless significant
new features are implemented. Given in addition that network-admin
totally botches its support for managing the resolvability of the system
hostname via /etc/hosts, I think that there is more than enough reason
to drop that support.
[0]http://lists.debian.org/debian-boot/2005/06/msg00758.html
--
Thomas Hood <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
