[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: can we (fully) release-goal decommissioning of trolls

Le dimanche 19 août 2012 à 19:26 +0200, Christoph Anton Mitterer a
écrit : 
> 1) In parts it has some security issues.
> - At least the default setting seems to be that any user can connect to
> any network.

This is untrue. Any *physically logged on* user can connect to any
network. For a desktop system this is clearly a reasonable default, and
it can be modified through PolicyKit.

> - At least the network connections from /etc/network/interfaces are
> exported to the normal user, even if that user cannot read that file.

This is also untrue. By default NM does not look at all at /e/n/i.

> 2) NM's design seems to be wrong.
> AFAIU (I didn't look into too much depth, though), NM is based on the
> design idea, that it replaces all network management and configuration
> from the respective distros.

This is a reasonable choice, given that most distros have very basic or
nonexistent network configuration (/etc/sysconfig/network-scripts
hahaha) and those who have a decent one were not designed for high level

> So when NM brings up a connection, it does not simply invoke some e.g.
> ifscheme wlan0-myHomeNet
> ifup wlan0
> but directly invokes wpa_supplicant.
> That's IMHO quite awful, as you loose all the proper integration of
> ifupdown by gaining nothing.

Because storing passphrases in the keyring is “nothing”. Because having
per-user networking priorities is “nothing”. (The list could be very

> Moreover it complicates the code, as now NM needs to come with its
> own /e/n/interfaces parsers (which will everytime the something changes
> there)

Mostly irrelevant. They are disabled by default because doing so is
broken by design.

> In my opinion, NM should:
> - export any connections from the real canonical places
> (e.g. /etc/network/interfaces, /etc/vpnc/*, /etc/ppp/peers/*
> and /etc/chatscripts/*, /etc/ipsec.conf and /etc/ipsec.d/*, etc. pp.)


> - only if a user doesn't find something there, a per user connection
> configuration should be set up.

Only interfaces not already managed by /e/n/i are started up by NM. How
is what you propose better?

> - I know, NM supports system wide configuration, too, but IMHO that
> should be dropped altogether and NM should also not try to edit the real
> canonical configuration.

Yeah sure, let’s replace a proper and global system configuration that
you can setup with the same GUI as per-user configuration with a bunch
of parsers that will always fail to do one of the 200 things they have
to manage. Weren’t you the one complaining about broken parsers 10 lines

Haven’t people learned ANYTHING about disasters such as webmin?

> 3) ifupdown integration is really bad

Which is why it is disabled by default. Not that it hurts much.

> Well this is similar to (2).
> a) NM (AFAIU) doesn't really use ifupdown for controlling, it merely
> parses /etc/network/interfaces

Which is bad design, as you pointed out yourself. And which is why this
feature should remain DISABLED.

> b) barely nothing from /etc/network/interfaces is supported, some bugs
> I've noticed:
>   - the dns-* options from resolvconf don't work at all
>   - wireless connections aren't exported if wpa-key-mgmt is not set
> (which there should be no need to in many cases), and for WPA-EAP it
> seems to generally not work.
>   - the same is the case with many advanced options (ap_scan, etc. pp.)

If you want to fix this broken set of features that is not enabled by
default, send patches.

> c) when NM is running, I cannot use ifup foo / ifdown foo / ifconfig
> <parameters>... well I can.. but then everything gets really messed up

So what? What actual problem does it cause?

> d) when I disable wireless in NM it really blocks it, so I can't use it
> with ifupdown. Now one can rfkill unblock then... but why? and even if
> one does...NM seems to get confused again.

Same question as c).

> 4) upstream more or less doesn't want to support these scenarios...

Of course, because *as you pointed out yourself*, the idea of parsing
system configuration is stupid and leads to bugs.

> Already many months ago, I've opened a Debian bug, that some /e/n/i
> connections are simply not shown by NM.
> Given that this is actually an upstream issue, I've reported this (and
> most other problems I've mentioned before, especially the poor ifupdown
> integration but also the ideas about adding support for all the
> canonical configurations) upstream.
> I guess the conclusion is: "this won't be implemented".
> It seems the "desired" scenario for NM is that /e/n/i is empty 

Yes. This is actually what happens on usual setups (one interface, DHCP
without any special options) upon NM installation.

> and
> everything is handled Apple™ like: hide-everything, don't support
> advanced setups.

Indeed it is not possible to support any combination of advanced setup
with a pre-defined set of configuration options accessible from a GUI.
Thank you, Captain Obvious.

> So,... at least I want to continue our wonderful ifupdown and also the
> other native tools (ppp, ipsec, etc. pp.) because these are what I need
> to use when I need to debug something or do something advanced.
> I'd blindly guess that many other would want that, too.

“wonderful” ifupdown… I guess some of us around here have other words to
describe it.

> So what are the opinions of the others? Will we continue to live with
> the current disease?

I think the disease mostly consists in old farts enjoying endless
threads where they spread misinformation (if not lies) about software
they don’t like because it was not developed as in the 80’s.

10 years ago, we had people complaining about ORBit. Then later they
complained about D-Bus and pmount. Recently it was about PulseAudio. Now
they don’t want to see their precious 30-year-old systemv and ifconfig
crap replaced.

These people are the disease. They are toxic to the community and tend
to polarize discussions against anything that is not designed according
to their wishes, while most of them of course never contribute anything
of value to the core system’s design. I’m sorry for their beliefs but
Debian should be a do-ocracy, not a theocracy.

 .''`.      Josselin Mouette
: :' :
`. `'

Reply to: