PDA

View Full Version : [ubuntu] How do the new network configuration tools work?



decoherence
April 29th, 2009, 05:36 PM
I'm wondering about the Network Connections tool (aka nm-connection-editor) in Jaunty. Specifically, where does it get its information? Where does it write to? I would've thought it used /etc/network/interfaces but evidently not -- it does not appear to read or write anything to that file. Is that expected behaviour?

I have also set up connection bridging for VBox using the Ubuntu community docs, if that makes any difference.

thanks for any insight,

UPDATE: after finding, much to my frustration, that almost no network manager tools have man pages, I finally did man NetworkManager (btw, whoever is responsible for the name, thank you for those capitals. i really NEEDED to hit my head against the keyboard that one extra time /sarcasm) which tells me I want to look in /etc/NetworkManager/system-connections. So are we just ignoring /etc/network/interfaces? Well not according to /etc/init.d/networking restart.... sigh. I'm at the point now where I think I just need to be re-educated about how this stuff works in Ubuntu these days. Having two systems to deal with networking is confusing me.

Anyone have any good NM resources for a guy who was content to simply edit his /etc/resolv.conf, bring up an interface with ifconfig and set a gateway with route? Furthermore, if I want to set up a bridge, what is the NM-blessed way to do this? Or is there one?

decoherence
April 30th, 2009, 02:13 PM
Well, now I have another problem which I believe is still related to this nm vs. init script dichotomy.

I found, after making a new connection in nm-connection-editor, that while I could get online, I couldn't get to any of our intranet sites by name. Internet sites all resolved fine. I confirmed, using nm-connection-editor, that the nameserver setting was correct. Then to further confirm I did


less /etc/resolv.conf

which output the line


# Generated by NetworkManager

And that's all. No nameservers, no nothing. Just this comment line telling me that NM did exactly nothing to this file. And yet internet sites were resolving fine. So what nameserver was it using? Did it or did it not write to /etc/resolv.conf? Is anybody else seeing this?

I manually entered the nameserver info in to /etc/resolv.conf and can now access our intranet sites.

Can some person smarter than me figure out what's actually happening based on the behaviour I describe? Can anyone suggest anything I might try that could shed some light on this?

Do you think it would be a good idea for tools that automatically edit text files like /etc/resolv.conf to date their edits? At least then I'd be able to tell when NM updated resolv.conf.

ADD: just a bit more confusion... I did


sudo find /etc/NetworkManager/ -exec grep 10.9.6.32 '{}' \;

and it came up empty. 10.9.6.32 is my nameserver. So if it wasn't in /etc/resolv.conf (initially) and it wasn't anywhere under /etc/NetworkManager, where the heck is it?

decoherence
April 30th, 2009, 06:17 PM
This is starting to turn in to a not-so-nice thread.

Here's the latest. I just tried to go to another one of our intranet pages and got the same 'host not found' error i was getting before. I immediately checked /etc/resolv.conf and found that, once again, it was empty of any information. Just that helpful line "# Generated by Network Manager" which would more accurately read "# Completely screwed up by Network Manager"

At this point I don't have any additional information to add. This is becoming more of a vent-thread but I'm still hopefully someone will come across it and say "oh yeah, me too!"

Here's some additional info.


$ sudo lshw -sanitize -C network
*-network
description: Ethernet interface
product: 82562V-2 10/100 Network Connection
vendor: Intel Corporation
physical id: 19
bus info: pci@0000:00:19.0
logical name: eth1
version: 02
serial: [REMOVED]
size: 100MB/s
capacity: 100MB/s
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=0.3.3.3-k6 duplex=full firmware=1.1-2 ip=[REMOVED] latency=0 link=yes module=e1000e multicast=yes port=twisted pair speed=100MB/s
*-network:0
description: Ethernet interface
physical id: 1
logical name: virbr0
serial: [REMOVED]
capabilities: ethernet physical
configuration: broadcast=yes driver=bridge driverversion=2.3 firmware=N/A ip=[REMOVED] link=yes multicast=yes
*-network:1
description: Ethernet interface
physical id: 2
logical name: vbox0
serial: [REMOVED]
size: 10MB/s
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=tun driverversion=1.6 duplex=full firmware=N/A link=no multicast=yes port=twisted pair speed=10MB/s
*-network:2 DISABLED
description: Ethernet interface
physical id: 3
logical name: pan0
serial: [REMOVED]
capabilities: ethernet physical
configuration: broadcast=yes driver=bridge driverversion=2.3 firmware=N/A link=yes multicast=yes
*-network:3
description: Ethernet interface
physical id: 4
logical name: br0
serial: [REMOVED]
capabilities: ethernet physical
configuration: broadcast=yes driver=bridge driverversion=2.3 firmware=N/A ip=[REMOVED] link=yes multicast=yes

----------------------------------------------

$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

-----------------------------

$ ls /etc/NetworkManager/system-connections/
Auto vbox0

-----------------------------

$ sudo cat /etc/NetworkManager/system-connections/Auto\ vbox0

[connection]
id=Auto vbox0
uuid=[REMOVED]
type=802-3-ethernet
autoconnect=true
timestamp=0

[ipv4]
method=manual
addresses1=10.9.11.97;16;10.9.1.1;
ignore-auto-routes=false
ignore-auto-dns=false
never-default=false

[802-3-ethernet]
speed=0
duplex=full
auto-negotiate=true
mac-address=[REMOVED]
mtu=0



If I do ifconfig, I'm shown a DHCP assigned IP (which is not the 10.9.11.97 address specified above)


$ ifconfig
br0 Link encap:Ethernet HWaddr 00:21:9b:0a:39:c7
inet addr:10.9.4.230 Bcast:10.9.255.255 Mask:255.255.0.0
inet6 addr: fe80::221:9bff:fe0a:39c7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1539092 errors:0 dropped:0 overruns:0 frame:0
TX packets:305059 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:516006103 (516.0 MB) TX bytes:68029844 (68.0 MB)

eth1 Link encap:Ethernet HWaddr 00:21:9b:0a:39:c7
inet addr:10.9.4.230 Bcast:10.9.255.255 Mask:255.255.0.0
inet6 addr: fe80::221:9bff:fe0a:39c7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1808968 errors:0 dropped:0 overruns:0 frame:0
TX packets:453008 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:630392866 (630.3 MB) TX bytes:88697452 (88.6 MB)
Memory:fdfc0000-fdfe0000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1135 errors:0 dropped:0 overruns:0 frame:0
TX packets:1135 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:101938 (101.9 KB) TX bytes:101938 (101.9 KB)

vbox0 Link encap:Ethernet HWaddr 9a:16:1a:33:3a:e2
inet6 addr: fe80::9816:1aff:fe33:3ae2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:5607 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

virbr0 Link encap:Ethernet HWaddr 96:3d:0b:a4:6d:61
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
inet6 addr: fe80::943d:bff:fea4:6d61/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:6390 (6.3 KB)


Can anyone spot anything? Could all of these extra bridge connections be the issue?

decoherence
April 30th, 2009, 07:44 PM
Okay, last post! Promise! Turns out those extra bridges from my kvm and vbox-ose experiments were the culprits.

I purged kvm and virtualbox-ose (I currently use Sun (Oracle?) xVM, aka non-free virtualbox) and now things seem to be more sane. nm-connection-editor actually displays my interfaces and it is writing to /etc/resolv.conf again.

I had to rebuild the xVM kernel module. With that done, the system appears to be back in its glorious pre-Jaunty state.

Lessons? Two of 'em. 1. If you do heavy customization, be careful of upgrades. 2. Anything can be fixed (this was true when I ran Debian unstable for years on end. Nice to see the same thing holding true for Ubuntu.)

Oh, and three... THREE lessons! When faced with a seemingly strange problem, putting your thoughts down is a big help. And four... AMONGST our lessons... amongst our lessonry... are such elements as heavy customization.... I'll come in again.

Fin.