On Aug 19, Christoph Anton Mitterer <cales...@scientia.net> wrote:
> Where do I see the main problems of NM?
NM, as a design goal, is not supposed to be able to manage every possible configuration.
I see no reason do /discourage/ it use: it has important use cases where it works well, the problem is just the people who are making hard to not install it when it is not appropriate for the job.
> Or will we just mothball ifupdown silently and slowly (as it's replaced
> by NM).
As explained, NM is not a general ifupdown replacement.
On Sun, 2012-08-19 at 19:26 +0200, Christoph Anton Mitterer wrote:
[...]
> 1) In parts it has some security issues.
> - At least the default setting seems to be that any user can connect to
> any network.
[...]
According to README.Debian:
To allow users to connect to the NetworkManager daemon they have to be in the
group "netdev".
> - At least the network connections from /etc/network/interfaces are
> exported to the normal user, even if that user cannot read that file.
> A typical example is that I put in network connections that the normal
> user should not be able to enable, or even connections that require
> credentials in /etc/network/interfaces.
> So NM should only export a connection, if the user would be able to read
> the necessary config files.
The capability to *use* credentials is separate from the capability to
*read* the credentials.
(Also, the design choice to read credentials from a file that is world-
readable by default is incredibly stupid, and you may wish to report
bugs on the packages that do that.)
> 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.
I don't think that was the original intent at all. However it is
gradually being extended to manage more types of device.
[...]
> 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.
> - 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.
> If someone want's a system wide IPsec connection, that should e.g. go to
> strongswan's /etc/ipsec.conf.
You seem to be asking for an awful lot of integration work within NM
itself, which means divergence from upstream.
> 3) ifupdown integration is really bad
> ifupdown is really a good framework, it offers hooks and and is properly
> integrated in many packages.
ifupdown *was* a good framework, but Linux moved on. ifupdown doesn't
know anything about interface state. It doesn't know whether hooks
succeeded and it can't check for failures because that would be an
incompatible change (#547587).
Yes, we have a large investment in ifupdown. But the result is still
not good, and we don't get much help with this from other distributions.
[...]
> 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.
If you say 'disable wireless', why are you surprised that it does what
you say? I think it uses rfkill because that may save more power.
> 4) upstream more or less doesn't want to support these scenarios...
> 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 and
I suspect so.
> everything is handled Apple™ like: hide-everything, don't support
> advanced setups.
I don't think this is the direction upstream is going in. Instead, it's
adding more support for advanced setups.
[...]
> So what are the opinions of the others? Will we continue to live with
> the current disease? Are the alternatives better integrated? Could we
> get discourage NMs use if necessary?
> Or will we just mothball ifupdown silently and slowly (as it's replaced
> by NM).
I would really like to see Debian developers working to improve Network
Manager so it can replace ifupdown. For example, improving the command
line interface and support for various types of software devices.
Unfortunately, I don't have the spare time to make much of a
contribution to that myself. (I do install ifupdown hooks as part of
ethtool, so I'll have to think about those.)
Ben.
-- Ben Hutchings
I say we take off; nuke the site from orbit. It's the only way to be sure.
❦ 19 août 2012 20:32 CEST, Ben Hutchings <b...@decadent.org.uk> :
>> 1) In parts it has some security issues.
>> - At least the default setting seems to be that any user can connect to
>> any network.
> [...]
> According to README.Debian:
> To allow users to connect to the NetworkManager daemon they have to be in the
> group "netdev".
But also:
Alternatively you can install the "consolekit" package which will
grant access for all locally logged in users.
But all this can be changed by altering the appropriate file in
/etc/dbus-1/system.d.
-- Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)
Ben Hutchings <b...@decadent.org.uk> wrote:
> > 3) ifupdown integration is really bad
> > ifupdown is really a good framework, it offers hooks and and is
> > properly integrated in many packages.
> ifupdown *was* a good framework, but Linux moved on. ifupdown doesn't
> know anything about interface state.
Why should it? It's a configuration tool, not a monitoring one. If
monitoring is needed, a different tool can be developed which would
perfectly integrate into ifupdown... but nobody has needed that yet?
> It doesn't know whether hooks succeeded and it can't check for
> failures because that would be an incompatible change (#547587).
It can, and compatibility isn't a matter here, it's just a question of
bringing other packages to a state they should have been in already.
Also, as you don't know the stuff behind ifupdown development, please
don't make such statements, okay? We're in the freeze now, so the work
on ifupdown is limited to fixing RC bugs for a while, but this doesn't
mean new stuff won't be developed to make ifupdown better.
On Sunday, August 19, 2012 13:26:46, Christoph Anton Mitterer wrote:
> Hey.
> I hope this won't become too much of a rant, but IMHO we long ago
> crossed the point where something (well actually many things) would have
> needed to be seriously done.
> My grandparents always warned me about UNIX programs written in capital
> letters ;-).
> Seriously... I have nothing against a high level daemon that manages
> underlying network control systems (ifupdown, vpnc, ppp, strongswan,
> openswan, openvpn) but not the way NM does it, especially as it doesn't
> work correctly at all edges and ends.
> Until "recently" all that wasn't a big problem, because one was easily
> able to simply not install NM, but nowadays more and more packages start
> to depend on it (of those I know, most notably gnome-core) or at least
> use it's functionality to determine whether one is online or not.
[…]
The first suggestion I have is to look at Wouter Verhelst's 'ipcfg' project [1], which he gave a talk about on the last day of DebConf12 [2], and which is currently a work-in-progress, thus making it a good time for this kind of input. His plan for the project addresses many of the typical complaints about NM, as well as other network managers, and I think he's got some very interesting ideas and thoughts about the problems you've described.
Related note: I likewise repeatedly have confusion over how to deal with testing Network Status from within shell scripts for doing operations that require network access. As a "for instance" a common suggestion for keeping GPG keys up to date is to set a 'gpg --referesh-keys' operation as a cron job, which doesn't make sense to do if the device the script is run on is offline, especially if you want to log the output from the command. The conclusion I've come to is that there needs to be a standard way for programs in Debian to know whether the local environment has network access, but that right now this is something that doesn't currently exist and is also not covered in Debian Policy. :-(
I've likewise repeatedly been frustrated by packages that try to pull in NM as a dependency, and there has been repeated discussion here in [debian-devel] on this topic as well. I've used NM, learned to hate it, and today absolutely refuse to allow it to be installed. Reason: I too tried the "solution" of "just disable it in the startup script" just to have THAT bite me in the ass every time NM gets upgraded. I'd personally like to see the NM package in Debian come with an /etc/default/network-manager file [like wicd has] so that a user has a way of disabling NM in a way that won't get "fixed" upon upgrades. Until then, when it comes to my own systems, it and any package that depends on it looses. [Come to think of it, the right thing for me to do is to open up a Wishlist bug for this -- so I'll be doing that today.]
Please take over the netconf project and start implementing that
design in C, that would be much more productive than any new thread
about the current and previous deficiencies of NetworkManager.
-- To UNSUBSCRIBE, email to debian-devel-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/CAKTje6HqspWEZqrh64FN0BoEU-X2yKABLW-eHG=x14FMs7Q...@mail.gmail.com
On Mon, Aug 20, 2012 at 7:59 AM, Chris Knadle wrote:
> require network access. As a "for instance" a common suggestion for keeping
> GPG keys up to date is to set a 'gpg --referesh-keys' operation as a cron
I prefer this option for keeping my GPG keyring up to date:
-- To UNSUBSCRIBE, email to debian-devel-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/CAKTje6HvE3J_noPruGiTdd-_sBVXzG4eQzwaR324dydZ4tB...@mail.gmail.com
On 20.08.2012 02:07, Christoph Anton Mitterer wrote:
> But when I e.g. put WPA credentials into /e/n/interfaces and made the
> file specifically readable by root and user foo only, then it still
> exports that connection to all other users (e.g. being logged on
> locally; at least per default).
That is simply not true.
NM doesn't by default export any WPA secrets in /e/n/i to any user.
I'm not sure if you don't know any better or if you just want to spread FUD.
Michael
-- Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
On 20.08.2012 02:18, Christoph Anton Mitterer wrote:
> On Mon, 2012-08-20 at 02:13 +0200, Michael Biebl wrote:
>> That is simply not true.
>> NM doesn't by default export any WPA secrets in /e/n/i to any user.
>> I'm not sure if you don't know any better or if you just want to spread FUD.
> I specifcally wrote "export _connection_" and not "credentials"...
> meaning that it allows to open a connection, that might be intednded to
> be usable by only some users ...and I also gave some ideas that even
> that could be an issue....
Apparently it is still not clear to you: NM by *default* does not export
any wireless connections from /e/n/i to *any* user by the simple fact
that managed=false by *default*.
> So no,... don't want to spread FUD ;)
So my inital point still stands.
In your first paragraph you write "I hope this won't become too much of
a rant"
What follows is a lot of misconceptions and biased views and you
conclude with "Will we continue to live with the current disease?".
I won't bother following up as I'm really tired of all this BS on
debian-devel regarding NM lately. Sorry.
My guess is, that this will be another of those pointless NM bashing
threads, where nothing useful comes out of it. Actually I'm not sure
what the point of this thread is, but it definitely managed to piss me
off, the maintainer of network-manager, and I'm not going to further
participate.
Michael
-- Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
-- To UNSUBSCRIBE, email to debian-devel-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120820020757.GA2...@gaara.hadrons.org
On Sunday, August 19, 2012 20:41:47, Michael Biebl wrote:
[…]
> I won't bother following up as I'm really tired of all this BS on
> debian-devel regarding NM lately. Sorry.
> My guess is, that this will be another of those pointless NM bashing
> threads, where nothing useful comes out of it. Actually I'm not sure
> what the point of this thread is, but it definitely managed to piss me
> off, the maintainer of network-manager, and I'm not going to further
> participate.
I'm sorry you're feeling hurt from the NM criticism. I'm confident that nobody had any intent of hurting your feelings.
Whatever opinions I or others my have about NM are about the software is mostly about the software that comes from upstream -- which has nothing to do with you directly, so /please/ try not to take this personally. Also this thread started mainly about *other* packages that pull in network-manager as a dependency, which doesn't even have to do with the network-manager package itself. NM is just one part of a larger "meta issue" going on concerning coordination /between/ various packages.
There's a natural tendency to have an emotional attachment and pride one's work. In the case of Debian packaging the maintainer gets to have a lot of input on how the package gets installed and might have /some/ control over the software's default behavior, but to a large extent it seems to me the maintainer only has minimal control over how the software actually works, because that comes from upstream and it's specifically /not/ the packager's task to implement major design changes to it.
I therefore think taking criticism about the /software itself/ that a maintainer packaged /personally/ is a harsh self-judgment, especially if there's not much a maintainer can actually /do/ about the perceived design failings that the software might have. This reminds me of the the "Serenity Prayer" [1] mantra used during meetings of Alcoholics Anonymous (AA).
The part of this that I think is non-obvious is that one's emotions and reaction are actually a choice. For instance, my experience is that if someone outright criticizes me directly with the obvious intent of /trying/ to hurt my feelings, /that/ is often far easier to dismiss than if someone criticizes the output of my efforts /without/ any obvious intent to make it hurt. This is a good thing as otherwise I would be allowing someone else to /control/ my emotions and my reaction. But the extension of this is even more interesting -- that I am /responsible/ for my emotions as as well as my reaction, because they are both my choice. (There's an interesting 10-minute video [2] discussing some of these issues which I think is worth watching.)
Finally, I want to make it clear that none of the above is meant as criticism of any kind -- it's meant purely as an attempt to help.
But we will keep it a looonnng time in Debian otherwise, we won't be
able to propose a working desktop environment.
-- printk("ufs_read_super: fucking Sun blows me\n");
2.0.38 /usr/src/linux/fs/ufs/ufs_super.c
On Sun, Aug 19, 2012 at 07:59:00PM -0400, Chris Knadle wrote:
> The first suggestion I have is to look at Wouter Verhelst's 'ipcfg' project
> [1],
Thanks :-)
> which he gave a talk about on the last day of DebConf12 [2], and which is
> currently a work-in-progress, thus making it a good time for this kind of
> input. His plan for the project addresses many of the typical complaints about
> NM, as well as other network managers, and I think he's got some very
> interesting ideas and thoughts about the problems you've described.
It's nowhere near ready yet, however. Last week was the first time I
managed to do anything on ipcfg since debconf (hey, I have a life, too).
_Maybe_ I'll get this to a somewhat working state for Jessie, but that's
by no means certain.
-- The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
-- To UNSUBSCRIBE, email to debian-devel-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120820065624.GA4...@grep.be
On Sun, Aug 19, 2012 at 07:59:00PM -0400, Chris Knadle wrote:
>Related note: I likewise repeatedly have confusion over how to deal with
>testing Network Status from within shell scripts for doing operations that
>require network access. As a "for instance" a common suggestion for keeping
>GPG keys up to date is to set a 'gpg --referesh-keys' operation as a cron job,
>which doesn't make sense to do if the device the script is run on is offline,
And how do you want to do this check? Even if ethtool says, the interface is up, this doesn’t mean, your DSL router has a WAN connection running.
And if it has, it doesn’t mean you can reach the keyserver.
So you can use something like „fping -q <keyserver>”, if the keyserver is pingeable. Any other check is not really usefull.
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
integration.
> 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
long.)
> 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.)
No.
> - 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
earlier?
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.
On Monday, August 20, 2012 03:29:05, Stephan Seitz wrote:
> On Sun, Aug 19, 2012 at 07:59:00PM -0400, Chris Knadle wrote:
> >Related note: I likewise repeatedly have confusion over how to deal with
> >testing Network Status from within shell scripts for doing operations that
> >require network access. As a "for instance" a common suggestion for
> >keeping GPG keys up to date is to set a 'gpg --referesh-keys' operation
> >as a cron job, which doesn't make sense to do if the device the script is
> >run on is offline,
> And how do you want to do this check? Even if ethtool says, the interface
> is up, this doesn’t mean, your DSL router has a WAN connection running.
> And if it has, it doesn’t mean you can reach the keyserver.
> So you can use something like „fping -q <keyserver>”, if the keyserver is
> pingeable. Any other check is not really usefull.
Basically you've got the idea of what I'm doing.
~/bin/gpg-refresher
-------------------
# (this setting pulled in from a config file)
PING_LOCATION=www.yahoo.com #(actual location should = keyserver location)
#
ping -c 3 $PING_LOCATION > /dev/null
if [ "$?" -ne "0" ]; then
exit
fi
gpg --refresh-keys -o - 2>&1 | fgrep -v -e "requesting key" \
-e " not changed" -e "Total number processed: " -e " unchanged: " \
-e " keys processed so far" -e " next trustdb check due at" \
| egrep -v -e "refreshing .* keys from " \
-e "key .* not found on keyserver" \
-e "^gpg: depth: .*" -e " trust model$"
-- Chris
--
Chris Knadle
Chris.Kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
Christoph Anton Mitterer <cales...@scientia.net> writes:
> On Sun, 2012-08-19 at 19:41 +0200, Marco d'Itri wrote:
>> NM, as a design goal, is not supposed to be able to manage every >> possible configuration.
> Well but then it shouldn't be kind of a default package.
No it shouldn't. And it isn't either. gnome-core is not default.
> And yes, I
> know, strictly speaking it's neither required nor essential.
> But as I mentioned before, more and more uses it... and one usually
> get's it already with gnome-core.
Except for GNOME, what other unrelated packages depends on NM?
The GNOME dependencies are deliberately broken to bring in as much cruft
as possible, but GNOME is neither required nor default so what's the
problem? Why do you install gnome-core if you don't want the resulting
package mess?
> And to be honest, I don't think that it's impossible that NM would
> integrate well with ifupdown (and the others).
I believe it already does. Any problems with this integration should be
reported as bugs.
Neither NM nor ifupdown is currently capable of dealing with every
possible networking setup (NM fails on complex static configurations,
ifupdown fails on dynamic stateful configurations). And I expect this
is how it will be for the foreseeable future. At least that's how I
understand the current scopes of those packages.
Debian need *both*, and any efforts in this area should be put into
making them interoperate.
Never mind wireless lan where you've got a well defined kernel API. Try
to configure a modern 3G/LTE modem using ifupdown, and you will see the
usefulness of a framework like NM and it's companion ModemManager. Yes,
there are of course bugs and missing features. But let's fix them then.
NM upstream is very active and easy to co-operate with.
And before someone asks: There won't be any "standard wireless
extensions" for wan connections. That sort of thing is just not
considered appropriate for the kernel anymore. Drivers export the device
native control channel(s), and leave the rest of the job for userspace
libraries. This means that you will need something like ModemManager,
oFono or similar to provide a common device independent application
interface.
Bjørn
-- To UNSUBSCRIBE, email to debian-devel-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uj1kegq....@nemi.mork.no
On Aug 20, Stephan Seitz <stse+deb...@fsing.rootsland.net> wrote:
> On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote:
> >Never mind wireless lan where you've got a well defined kernel API. Try
> >to configure a modern 3G/LTE modem using ifupdown, and you will see the
> Is this something different from an UMTS usbstick? I plug it in, get
Often they are, you can learn way more than you ever wanted to know about this by quickly looking at the modemmanager sources. Next?
-- ciao,
Marco
Stephan Seitz <stse+deb...@fsing.rootsland.net> writes:
> On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote:
>>Never mind wireless lan where you've got a well defined kernel API. Try
>>to configure a modern 3G/LTE modem using ifupdown, and you will see the
> Is this something different from an UMTS usbstick?
No.
> I plug it in, get a
> /dev/ttypUSB0 and do a „pon umts”. No need for NM and Co.
Sure. But you didn't actually configure the device here, did you? And
you didn't notice that the device fell back from LTE to UTMS. Or that
it suddenly started roaming to the network on the other side of the
border. Etc.
You didn't even notice that the connection failed because the PIN code
was wrong. Or did you? OK, then your chat script has started looking
like a small ModemManager application...
Oh, yeah, and of course /dev/ttyUSB0 wasn't the AT port. It was the
QCDM port so the chat script just timed out.
The connections provided by these devices are dynamic by nature, and
they typically have management protocols supporting notifications from
device to host. You may of course ignore this and state that the device
"works" in a static configuration, but most users will want some
monitoring daemon allowing them to make intelligent decisions based on
current available devices and networks. A little like what
wpa_supplicant does for wireless LANs. That's what ModemManager
provides.
But yes, if „pon umts” is enough for you then you don't need NM (or even
ifupdown - pppd and vim will do).
By modern 3G/LTE modem I mean a device supporting CDC MBIM or a vendor
specific management protocol like QMI. The firmware of most of these
devices will export a basic AT command set and support PPP on one or
more serial ports, but that only supports a very limited usage pattern
IMHO. And when it comes to LTE, also limited speed. Some vendors
implement AT commands for initiating "NDIS" connections, but these are
exceptions and are likely to go away over time as more and more devices
get a "intented for Windows 8" label or somthing like that. And it
didn't work with your "pon" in any case.
Bjørn
-- To UNSUBSCRIBE, email to debian-devel-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq6liwmw....@nemi.mork.no
also sprach Paul Wise <p...@debian.org> [2012.08.20.0154 +0200]:
> Please take over the netconf project and start implementing that
> design in C,
Or get it working properly with Python, make use of the simplicity
of interpreted languages until the design is actually proven to
work, and then rewrite it…
On Mon, 2012-08-20 at 00:04 +0200, Andrew Shadura wrote:
> Hello,
> On Sun, 19 Aug 2012 19:32:03 +0100
> Ben Hutchings <b...@decadent.org.uk> wrote:
> > > 3) ifupdown integration is really bad
> > > ifupdown is really a good framework, it offers hooks and and is
> > > properly integrated in many packages.
> > ifupdown *was* a good framework, but Linux moved on. ifupdown doesn't
> > know anything about interface state.
> Why should it? It's a configuration tool, not a monitoring one. If
> monitoring is needed, a different tool can be developed which would
> perfectly integrate into ifupdown... but nobody has needed that yet?
People talk about how ifupdown works well with other configuration
tools, unlike Network Manager. But it doesn't, it only knows how to
undo the configuration specified in /etc/network/interfaces.
Ben.
-- Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg
> People talk about how ifupdown works well with other configuration
> tools, unlike Network Manager. But it doesn't, it only knows how to
> undo the configuration specified in /etc/network/interfaces.
ifupdown should be the only way to configure network interfaces. Debian
should get rid of NM, ifconfig, ip, and all the other heretic programs
that break ifupdown.
Mike
-- To UNSUBSCRIBE, email to debian-devel-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120820142118.GA22...@glandium.org
> Please take over the netconf project and start implementing that
> design in C, that would be much more productive than any new thread
> about the current and previous deficiencies of NetworkManager.
Or just file bugs against ifupdown, the (new) upstream seems to be
pretty active these days.
-- To UNSUBSCRIBE, email to debian-devel-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503259B9.1040...@bzed.de
On Mon, Aug 20, 2012 at 04:21:18PM +0200, Mike Hommey wrote:
> On Mon, Aug 20, 2012 at 02:51:27PM +0100, Ben Hutchings wrote:
> > What I mean is that this still happens:
> > People talk about how ifupdown works well with other configuration
> > tools, unlike Network Manager. But it doesn't, it only knows how to
> > undo the configuration specified in /etc/network/interfaces.
> ifupdown should be the only way to configure network interfaces. Debian
> should get rid of NM, ifconfig, ip, and all the other heretic programs
> that break ifupdown.
Unfortunately they are needed by ifupdown itself. So instead we need
to have a mechanism in the kernel to refuse network configuration
that's not done by a child process of ifupdown. Then you will have
to put all network configuration in ifupdown hook scripts. Routing
daemons will not be supported, but they only cause confusion anyway.
Ben.
-- Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
-- To UNSUBSCRIBE, email to debian-devel-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120820155253.GF29...@decadent.org.uk
Have you all minded that there are several *different* use cases?
* Laptop user going here and there, sometimes with Wireless, sometimes with cable, sometimes with USB stick
* Desktop user with home ADSL
* Server with several connections
Each use case has its own needs, and its own best tools.
