[Pkg-utopia-maintainers] Proposal to add patches to netcfg (#682737)

Wed Sep 26 23:27:17 UTC 2012

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.sorina at 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20120927/b8db7dde/attachment-0001.pgp>