Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Udev and systemd to merge
Posted Apr 3, 2012 22:31 UTC (Tue) by tpetazzoni (subscriber, #53127)
Posted Apr 3, 2012 22:41 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Posted Apr 3, 2012 23:07 UTC (Tue) by mezcalero (subscriber, #45103)
Posted Apr 3, 2012 23:14 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
BTW, I actually wouldn't mind if something cleaned up the mess that is /etc/network in Debian and /etc/sysconfig/network* in RHEL/CentOS.
Posted Apr 4, 2012 9:06 UTC (Wed) by Aissen (subscriber, #59976)
BTW, NetworkManager should have been the one fixing this "mess" (not sure it really is a mess). Apparently it didn't work, otherwise some people wouldn't have written connman :-)
Posted Apr 4, 2012 9:52 UTC (Wed) by hadess (subscriber, #24252)
Connman was written because somebody was allergic to NetworkManager's use of GObject. No other reasons that I know of.
Posted Apr 4, 2012 10:22 UTC (Wed) by cortana (subscriber, #24596)
NetworkManager is actually becoming pretty awesome. It's great to be able to e.g., quickly configure my laptop for "internet connection sharing" with just a few clicks.
For the foreseeable future, I'm sticking with ifupdown on my servers though. I'm not opposed to NM taking over there; the fact that it actually checks to see whether the configurations it enacts were successfully applies means that in theory it can be much more reliable than ifupdown, which just runs ip/dhclient, etc., without checking their exit statuses. It's just not as obvious how to configure it without a GUI (there's no man page for the per-connection configuration files in /etc, nor is there any obvious replacement for ifupdown's hook scripts).
Posted Apr 4, 2012 10:52 UTC (Wed) by lindi (subscriber, #53135)
Posted Apr 4, 2012 13:46 UTC (Wed) by drag (subscriber, #31333)
Generally what you'd want to do for network-manager is to put your scripts into /etc/NetworkManager/dispatcher.d in the typical "if [ "$2" = "up" ]; then" style format.
To get the best benefits out of NetworkManager you want to disable all the 'legacy' configuration plugins and use keyfile. That way you can edit all your network configurations using a 'ini' file format in /etc/NetworkManager/system-connections/
The advantage to this is that you can support a much more diverse amount of network connection types with better granularity then you can through traditional distro-specific configs.
The spec for the settings can be found..
For managing it through the command line use 'nmcli'.
I wish Gnome would provide a better documentation and examples for people using network manager on a server, but oh well.
Posted Apr 4, 2012 15:04 UTC (Wed) by mathstuf (subscriber, #69389)
Thanks for that link. It really needs to be mentioned in the nmcli man pages.
Posted Apr 4, 2012 17:59 UTC (Wed) by mgedmin (subscriber, #34497)
I can barely manage to figure out how to list available networks ('nmcli dev wifi', really?).
Posted Apr 4, 2012 18:43 UTC (Wed) by tzafrir (subscriber, #11501)
Last time I asked, I was told adding such a thing was not a good idea (which is why the bug report is not in the NM bugzilla).
Posted Apr 4, 2012 18:52 UTC (Wed) by drag (subscriber, #31333)
Posted Apr 4, 2012 12:45 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
Most of my network configuration ends up in pre-up and post-down scripts.
Posted Apr 4, 2012 23:16 UTC (Wed) by rleigh (subscriber, #14622)
Posted Apr 4, 2012 15:01 UTC (Wed) by mathstuf (subscriber, #69389)
Unfortunately, a feature (though I consider it a bug) which is a blocker for me is still present.
Basically, I'd like to be able to set a wireless network as "flaky" so that if the connection drops, NM silently retries in the background continually instead of dropping the connection and *then* trying to reconnect. NM-aware applications tend to freak out if this happens every 5 minutes or so. Another use case is when moving around and one network is out of range temporarily in the presence of another known network (personal wireless, which is vastly preferred, versus campus wireless in my case). Going between floors takes me out of range of the my wireless, but the end points are both within range. I'd like to be able to tell NM that, but AFAIK, it will drop the connection, pick up the campus wireless and then not drop it when my wireless comes back into range because the campus connection is still there.
Of course, being able to create connections with nmcli would be nice too (unless it's a recent change, I haven't found out how to give it passwords and such for new wireless networks and instead have to launch nm-applet to create the connection which can then be managed with nmcli).
Currently, I just use ifcfg scripts for connections and wpa_supplicant.conf for wireless network configuration.
There's a bug open somewhere for it, but I can't find it right now.
Posted Apr 4, 2012 16:40 UTC (Wed) by drag (subscriber, #31333)
You edit your own keyfile and then copy it to /etc/NetworkManager/system-connections/. NetworkManager watches that directory and should pick up on changes to configs automatically.
Although it's usually easier to use the nm-applet to make something so you have a config to work on when you want to make changes in the future.
Posted Apr 4, 2012 16:46 UTC (Wed) by mathstuf (subscriber, #69389)
Posted Apr 5, 2012 16:49 UTC (Thu) by scientes (guest, #83068)
can i share over ethernet, as opposed to just wireless? If so, I guess I missed that functionality, I had alot of pain trying to do it myself while still having networkmanager work.
Posted Apr 6, 2012 12:20 UTC (Fri) by cortana (subscriber, #24596)
Posted Apr 6, 2012 14:39 UTC (Fri) by Eckhart (guest, #74500)
Posted Apr 6, 2012 19:44 UTC (Fri) by scientes (guest, #83068)
as someone that has basic understanding of the networking, and has done this manually, this makes perfect sense, the other way you talk of is confusing, and would be way less capable.
If it wasn't for ipv4 exhaustion, sharing your internet connection could as simple as turning on ipv4 packet forwarding. (now there is also address allocation issues, so DHCP) the complexity, and ever difference between upstream, and downstream, somes from Network Address Translation.
Posted Apr 6, 2012 20:02 UTC (Fri) by cortana (subscriber, #24596)
Posted Apr 6, 2012 20:23 UTC (Fri) by scientes (guest, #83068)
sure maybe the language needs to be made clearer, "share Internet to this interface?"
Posted Apr 6, 2012 20:37 UTC (Fri) by cortana (subscriber, #24596)
Posted Apr 6, 2012 20:39 UTC (Fri) by khim (subscriber, #9252)
It's my internet connection I want to share, so I naturally expect to set its interface, the upstream one, to 'share with other computers'; the upstream connection is what I'm sharing, and is therefore be the object in the sentence "Share my internet connection with other computers".
Well, it'll be nice psychology study which will show just why Joe Average gets the facts backward, but this logic is obviously quite strange.
Let's forget about network, routing, packets, etc. Suppose my neighbour lost electrical power and I, ever the helpful guy, want to share my grid power connection with him (electrical grid, not Internet).
Now, I have two choice:
1. I can go find out where and how my own house itself is connected to grid and try to change that global connection. I can even succeed and survive (if I'm lucky).
2. I can change my local connection configuration: just plug extension cord to my wall socket and attach appliances of my neighbour to it.
Somehow when electrical grid is concerned everyone automatically assumes solution #2 is right, but for Internet they want go and try to change WAN#1 (their WAN connection)? WHY? What's so special about Internet?
P.S. This phenomenon is quite obviously present because Microsoft tries to “help” here. It ALSO makes no sense to change WAN configuration when you share it even in Windows, but hey, if people en masse want to do this strange thing then this is how it should be done. As a result when you share network connection you must “alter” WAN connection, but this is illusion. When you try to “share” WAN connection in Windows WAN connection is not changed at all. Instead Windows goes and silently changes LAN connection behind your back.
The end result is essentially the same as with Linux, but with a twist: in simple cases everything “just works”, but in complex cases you must imagine these behind the scenes changes and do complex dance (Ok, I need to change this network in this and that way, but this is impossible to do so I need to create fictive temporary network and change THIS, then I can delete it because it's unneeded and I can fix THAT and but this well mean that networks will be disconnected but this can be fixed later…) I hate that.
Posted Apr 6, 2012 20:54 UTC (Fri) by scientes (guest, #83068)
#2. The Linux way of electricity networking does exist in your 2nd electrical example, its called a Widow-maker or other similarly ominous names. (for good reason)
Posted Apr 6, 2012 21:25 UTC (Fri) by khim (subscriber, #9252)
The Linux way of electricity networking does exist in your 2nd electrical example, its called a Widow-maker or other similarly ominous names. (for good reason)
Widow-maker is used to attach to the upstream, to “WAN” power grid (this is what you “naturally expect” for some reason). This is Windows way.
In Linux you share your wall outlets (you local in-house “LAN” electric network) instead.
the entire concept of LAN vs. WAN only propagates this confusion
Why? WAN == WIDE area network (think city-level or even wider electrical network), LAN == LOCAL area network (think you own tiny in-house network with dozen or two plugs and few appliances). If you want to share electricity with someone you most definitely will do it using your local network (unless you have some serious reasons to use thing which is called Widow-maker or other similarly ominous names).
Posted Apr 6, 2012 14:32 UTC (Fri) by Eckhart (guest, #74500)
This is perfectly possible with NetworkManager. Just create a wired connection, set method to Shared, and NetworkManager will start a DHCP server on your wired connection.
Posted Apr 4, 2012 15:28 UTC (Wed) by jond (subscriber, #37669)
Indeed, "it's entirely optional" would be closer to the truth.
Posted Apr 4, 2012 16:05 UTC (Wed) by Aissen (subscriber, #59976)
Posted Apr 6, 2012 14:49 UTC (Fri) by Eckhart (guest, #74500)
Can you please explain the systemd "full integration" "drama"?
(both "full integration" and "drama")
Posted Apr 6, 2012 15:26 UTC (Fri) by Aissen (subscriber, #59976)
I said "full integration" because systemd is already in debian (http://packages.qa.debian.org/s/systemd.html ), it's just not the default init. So it's integrated, but not fully since not all daemons have systemd unit files.
Posted Apr 6, 2012 16:53 UTC (Fri) by Eckhart (guest, #74500)
Posted Apr 4, 2012 21:23 UTC (Wed) by iabervon (subscriber, #722)
Second system effect?
Posted Apr 4, 2012 0:33 UTC (Wed) by Pc5Y9sbv (guest, #41328)
But seriously, maybe we really need a higher level set of event and process control abstractions from the kernel, rather than building some weird monolithic macro-micro-kernel architecture (kitchensinkd on top of Linux kernel)?
Posted Apr 4, 2012 4:45 UTC (Wed) by iabervon (subscriber, #722)
Posted Apr 4, 2012 8:24 UTC (Wed) by nowster (subscriber, #67)
Posted Apr 4, 2012 12:28 UTC (Wed) by njs (guest, #40338)
Posted Apr 4, 2012 15:27 UTC (Wed) by jond (subscriber, #37669)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds