Hi everyone! KiBi, thanks for forwarding the email and being so persistent about this issue.
Sorina, thanks a lot for this nice work and sorry that it took so long for me to answer. On 26.09.2012 22:46, Cyril Brulebois wrote: > Sorina - Gabriela Sandu <sandu.sor...@gmail.com> (16/09/2012): >> Hello! >> >> In #682737 [1] is stated that netcfg writes configuration for wireless >> interface in /etc/network/interfaces and therefor Wi-Fi card is not >> managed by Network-Manager. #682737 is by far not the only bug report related to this whole issue. #606268 is a rather old one (by joeyh), with quite a few duplicates. I guess I have to say a word or two here: If NM finds a configuration for a network interface in /etc/network/interfaces, it marks that interface as "unmanaged" and refuses to configure that device. The basic idea here is to not step on ifupdown's toes and avoid that two networking configuration tools try to manage the same interface at the same time. As d-i writes an /e/n/i configuration for the default network interface, this had the unpleasant side effect, that after a standard (desktop) installation, the main network interface was not managed by NM and marked as unmanaged (and thus offline). The workaround we used so far, is to munge /e/n/i in network-manager's postinst upon the first installation. The script that is run there is called /usr/lib/NetworkManager/ifblacklist_migrate.sh. It tries to comment out inteface configurations which are plain DHCP and have no further options. The reason for that is, that NM doesn't handle all of ifupdown's funky configuration options, like up/down commands, etc. Even though we tried to restrict that munger to the bare minimum and handle the simplest case, it is still buggy, like e.g. [1] or [2] shows. That ifblacklist_migrate.sh script is not generally loved and rightfully so, I'd like to get rid of it myself (or at least not run it automatically anymore). So far I refused to do that, as this would have meant that the NM installation on basically every system would have been broken/crippled, as NM would not actually manage the main network interface. For that, I very much welcome your proposed patch, Sorina, and I think this is the right way to address this issue. d-i runs is a much more confined environment and can make better decisions about what to do with the network configuration. >> For that matter, I would like to propose a patch to add support for >> netcfg to write a Network Manager config file and modify the >> finish-install script so that it copies to target either the nm-config >> file or a full /e/n/i config, according to a reasonable default and >> user's choice. This also contain a new question, >> netcfg/target_network_config, which is asked with a medium priority in >> finish-install, the default being also determined in the finish >> install, such as: Makes sense, in general. I do wonder though, if we actually need a new medium priority question. Due to it's priority it won't be shown unless you use an expert install. Maybe a simple pre-seeding option is sufficient. What about non-Linux ports? Would the question show up there, too? In it's current form the question is of limited value, imho. A few ideas how we possibly could improve that later. >> - if NM is installed, default = NM configuration Specifically, that means, /e/n/i will only contain the "lo" configuration and d-i will generate an NM connection in /etc/NetworkManager/system-connections/. Agreed, this is the most simple case and I think the right thing to do. No user interaction required. >> - if NM is not installed and the install was over wired, default = /e/n/i >> config If a user does a minimal installation and later install a desktop environment, he will run into the same issue again, that the device will be marked as unmanaged by NM. As NM is most useful on laptops with dynamic network configurations, I wonder if we can could use this information and pop up the dialog in that case, even for a non-expert installation. Or, as an alternative or in addition, change the default: - if NM is not installed and the install was over wired and the laptop-task is installed, default = NM configuration - if NM is not installed and the install was over wired, default = /e/n/i config Another, related idea, would be to simply network-manager in the laptop-task. With d-i generating a configuration for NM this would work rather nicely, I think. Joeyh, any opinion on that? >> - if NM is not installed and the install was over wireless, default = >> do not configure network Could be a bit confusing if the configuration is simply gone after the installation, but generally I agree. We could write a NM configuration in any case, but I guess some users would complain about that, if they later don't use NM. Again, maybe for this particular case we could bump the priority of the question and show it even for non-expert installations in this case (I'm not sure if that is easily possible). >> All the related changes can be found in people/sorina/write_config >> branch [2]. Also, a image containing all the changes can be found at >> [3]. The config file for NM is written according to the specifications >> here [4]. >> >> What do you think about this? Do you believe it could be used at the moment? I've did a few test-installation in various configurations, and your iso image worked rather nicely. I did test: 1/ installation over wired connection, with NM (desktop task), DHCP 2/ installation over wired connection, with NM (desktop task), static IP configuration 3/ expert install, installation over wired connection, with NM (desktop task), static IP configuration 4/ installation over wireless, with NM 5/ installation over wireless, without NM A few comments: a/ The issue of the additional libuuid dependency came up. Since this code will be Linux only anyway (due to NM being Linux only), you can just read a UUID from /proc/sys/kernel/random/uuid b/ File permissions. Yes, those files need to be 600, root owned, as they can contain secrets like, VPN pass phrases, WPA or WEP keys. So ideally create those files with those permissions directly. c/ Generating NM configurations is definitely useful and the keyfile format has been rather stable. So I don't share Joeyh's concern here. d/ We should ensure to not show the dialog for non-Linux ports. Some minor, more specific comments regarding the keyfile generation: e/ If you have the DNS search information, you can add that to the [ipv4] (or v6) section by adding a dns-search=foo.com;bar.org; line. When NM activates this connection, /etc/resolv.conf will then have a corresponding "search" configuration. f/ Naming of wireless connections: I'd suggest to just drop the "Auto " prefix. This is what upstream has been doing with NM 0.9.x. Just name the file/id after the ESSID. g/ For DHCP over ethernet type connections, you don't need to explicitely create a connection configuration. NM will automatically try that anyway and provides a default configuration. h/ Naming of wired connections: You chose "Wired connection 1" iirc. I would suggest marking this string translatable, since this will show up in the UI. i/ The final question can be a bit confusing. It says: "Please choose what kind of network configuration you want to have on your system after the installation process is complete." If I chose the "Network Manager" option I personally would expect after reading this, that selecting this option will mean my network is configured by Network Manager. What you mean though, is what type of configuration files should be generated. Maybe this could be rephrased somehow with a short recommendation when to use what, NM = dynamic network configurations, ifupdown = static configuration @Andrew: I know you added the CONFIGURE_INTERFACES/EXCLUDE_INTERFACES configuration options so ifblacklist_migrate.sh no longer needs to mangle /e/n/i. Unfortunately, this just means I need to mangle another configuration file. What's worse, /etc/default/networking is a conffile. And policy forbids that conffiles may be changed by maintainer scripts [3] ยง10.7.3. So unfortunately I can't use that interface. Ideally, ifupdown would provide a small helper tool, let's call it ifcfg, where I would simply need to call "ifcfg disable $interface" from within the NM maintainerscripts. This would also mean /etc/default/networking must not be marked as conffile but be managed via other means. I guess we should discuss that in a separate bug report / thread / mailing list. Just wanted to bring this up, as this is related to this topic. Ok, this has become a rather long email already, so I'll just finish here. I would really like to see this work land in d-i, btw. Maybe with some refinements to the way we present the question. As soon as that lands in d-i, I personally plan to no longer run the /usr/lib/NetworkManager/ifblacklist_migrate.sh automatically. I will either remove it completely or try to fix [1][2] and use a debconf prompt (probably with default off). I'm sure Christian will hate me for that, when I introduce new translations that late :-) But this issue has been one of the major complaints against NM so I'd really like to see that fixed. Cheers, Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656584#111 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688355 [3] http://www.debian.org/doc/debian-policy/ch-files.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
