Re: Proposal to add patches to netcfg (#682737)
Hi
I'll try to explain some of the decision as I have been working with
Sorina on this patch.
Joey Hess <joeyh@debian.org> writes:
> Sorina - Gabriela Sandu wrote:
>> 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
>
> I notice this links network-manager to libuuid. Which is an amazingly
> bloated 124k here. That's being added to the d-i boot image.
When we added this code to netcfg during GSOC I first also feared that
and we even had our own very minimal UUID implementation at some point.
But we then found out that libuuid is already included in the initrd
because it's a dependency of util-linux-udeb (blkid) which is needed for
udev-udeb. So we decided to reuse this instead of adding more code.
Also in my amd64 build:
$ ls -lh ./tmp/netboot/tree/lib/libuuid.so.1
-rw-r--r-- 1 gaudenz gaudenz 19K Jun 23 11:06 ./tmp/netboot/tree/lib/libuuid.so.1
So here it's much smaller...
>
> AFAICS, the network-manager configuration saves the user from having to
> re-select the wireless network, and re-enter any passphrase that they
> already entered once in d-i. This seems a relatively minor improvement,
> after all users of mobile computers rather frequently have to pick wifi
> networks and enter passphrases.
IMO the major improvement of the proposed change is that wireless
configuration is no longer written into /e/n/i for systems that have
network manager installed. The addition of a working network-manager
configuration is a nice bonus. I don't see a reason not to do it if you
have all the information available. It's just a small convenience
improvement.
>
> Even without the libuuid bloat (which I'm sure could be worked around
> somehow.. for example c32468fe-00d6-11e2-8510-97e4f3a3dcc1 is a
> perfectly fine uuid I just generated that d-i is free to reuse ;)
> .. I wonder if tying d-i so tightly to network-manager configuration
> file format is worth saving the user that step. Even with a spec, this
> desktop stuff is a pile of sand, it changes at upstream's whim; do we
> really want d-i tied to it?
Do you have evidence that it's that bad or is this just your bad
feeling?
>
> I also doubt that the medium priority debconf question adds much value
> to the installer. Especially since it also increases the size of the
> boot media. Who is going to pick something other than the default?
> Only users proficient enough to easily edit /etc/network/interfaces
> after the install, and who are apparently already planning to do some
> form of sysadmin work after the install.
The main reason for the question was to make it preseedable. So for
example automated desktop installs could still choose ifupdown. Or if
you know that your configuration management is going to install
network-manager afterwards you can choose the network-manager
configuration depsite it nm not being installed at the moment. Or you
can choose to not configure anything because you have a complex post
install script doing network configuration.
>
> ----
>
> As to the code, I haven't looked at it in detail, but this seems
> a needlessly roundabout way to get the network-manager config file's
> mode locked down:
> http://anonscm.debian.org/gitweb/?p=d-i/netcfg.git;a=commitdiff;h=093e22856d04d4d93c08ae402874ac5ef59d2fb3;hp=1d698b6eeb5a8ab6120adc7389a540dd04e6aa47
>
> In particular, it fails open -- if the installer is turned off at
> just the wrong point, the system will boot up with a password in the
> file and the file mode 644. It would be much more sensible to create
> the file with mode 600 from the beginning.
Good point. I think this could be improved. On the other hand this is
still an improvement over the current situation where there is no
security at all.
>
> AFAICS, network-manager uses mode 600 for all connection files, even
> those without passwords. This makes me wonder if it has good reasons for
> doing so. Perhaps it considers other information in the files security
> sensative. Perhaps it sometimes modifies the files to add security
> sensative information, without changing their permissions.
Don't know but it does not hurt either to have them always 600.
Brian Potkin wrote:
>> I realise a default is only a default and the selection can be changed,
>> but I'm puzzled by the third option. Why treat a wireless install
>> differently from a wired install? It would expected that a user who has
>> chosen not to use a wired connection would still want connectivity after
>> booting into into the new system,
>
> On the one hand we have people installing a fixed machine that has
> only wifi connectivity. These do exist -- two examples I'm familiar with
> are a friend whose workplace uses wifi for industrial controllers on the
> factory floor, and a parent whose desktop machine is an eeePC with a
> wifi antenna.
>
> On the other hand, we have users who chose not to install a desktop
> environment but want their machine to migrate between networks when it's
> moved. These users are going to need to do some form of sysadmin work
> post-install, whether it's installing a desktop environment and wicd, or
> editing /etc/network/interfaces on each fresh network, or bringing up
> wifi connections by hand. So I can't see locking a default into
> /etc/network/interfaces causing them much bother.
IIRC we decided on this default before we added the code to change the
access mode of /e/n/i if it contains a password. The main reason for
defaulting to no configuration in this case was to avoid having
passwords in there. If people think it should default to ifupdown in
this case this can be changed.
Gaudenz
--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~
Reply to: