Re: Network Manager does not find system wide connections

[Hadmut Danisch <hadmut danisch de>]

Dan Williams wrote:
>> Many packets for debian/ubuntu  are designed for the four phases of
>> the ifup/down system of debian for pretty good reasons.
>>     
>
> It depends; reasons change, and so do implementations.  Nothing is set
> in stone.
>   

Ah, I see. debian and ubuntu will change their main concepts just
to please network manager...



> Completely wrong.  NetworkManager is *NOT* a Red Hat tool.  Novell has
> contributed immensely to it, as have quite a few others from other
> distributions.  It just happens that I am paid by Red Hat to spend 110%
> of my time working on NetworkManager.
>
> Nobody else has made that commitment.  If some other company or person
> decided to invest time in NetworkManager, then that person or companies
> goals would also obviously be reflected in the feature set of the final
> product.
>   

So network manager is designed to not fit very well into other
distributions?


> So lets add some cold hard facts to the discussion.  What things are
> people doing in pre-down scripts?
>   

    * Any kind of logout, e.g. release dynamic dns entries, properly
      shut down connections that are kept alive during the online state
    * cleanly shutting down VPN connections and tunnels
    * network logoffs, e.g. deregistration from firewalls to prevent
      that someone else uses the user's permissions still bound the IP
      address
    * Anything that needs to be done with network interfaces that don't
      exist anymore after taking them down, e.g. read the counters
    * Doing jobs that need the network connection to be present, e.g.
      empty the mail queue
    * Porperly shutting down daemons with services bound to that
      particular network interface or internet address



>   
>> Beyond the dispute whether two or four phases should be supported,
>> Network Manager
>> does not pass the required Information to the up/down scripts.
>>     
>
> See below.  What other information do you need?  Is there some reason
> the tools you're running in these phases cannot use D-Bus for network
> even notifications if they are already running as a service somewhere?
> If they are not running as a service, then yes, a one-shot script-based
> approach may be more appropriate.
>   

Using dbus to fetch information in such a basic application is a
completely wrong
way. dbus is not very well documented. When trying to fetch debugging
data to
find the problem in my cause I could not find a detailed description
about how
to fetch attributes from dbus, and it would be a nightmare to do it in a
shell script
(and too slow as well). Documentation is poor and incomplete.

requiring each single one of the phase scripts fetch information over
dbus is
simply very, very bad design. If five scripts need that informations
then every
single one should fetch data over dbus even if the network manager already
has them but does not pass for 'religious reasons'?

Under debian/ubuntu there is a standard about which data the phase scripts
expect, and not all of these data can be found on dbus.

Needed:

    * The environment variables as set by the ifupdown program
    * The parameters set by users to use extra functionality provided by
      the phase scripts. Configured in /etc/network/interfaces for every
      connection type
    * Any parameters passed by the DHCP server






>   
>> Expecting the scripts to retrieve details with a given UUID over dbus is
>> error prone and
>> bad design, and it does not make the script run any faster.
>>     
>
> The UUID is already passed to the scripts, and has been for a long time.
> As are all the IPv4 details, and the DHCPv4 lease details if any.  What
> version of NM are you using?
>   
0.7.1~rc4.1.cf199a964-0ubuntu2


>
> Tools before NetworkManager didn't work for a more dynamic environment
> (especially wifi), thus we created NetworkManager.  I certainly don't
> want a pile of shell glued together with duct-tape and chewing-gum,
> which is what most of the previous networking system were.  
This is a pretty good approach.

But unfortunately it takes much more to write a good program.

Besides the fact that network manager's programming style is poor
(too complex, lack of docs, comments, and debugging, names of little or
no use,
difficult and time consuming to read), it suffers from a main problem:

Network manager is written like one of those many little tools and gadgets
for a desktop and extremely interweaved with the desktop environment and
it's complex functionalities. You can write a tool for sticky notes or a
timer for
your cup of tea in that way, things that are related to the user only,
but you cannot
write a program that controls the communication interfaces this way.

You cannot even precisely describe how nm finds its interfaces and
configurations,
and where to start debugging if something goes wrong. The way nm is
driven over
the dbus is one of the most silly methods to drive network interfaces
I've ever seen.

You can certainly add the functionality to a network managing daemon to
inform
other programs through dbus that something with the network has changed.
But never ever build a system relevat program in a way that it depends on
things like dbus or notifications and needs a running desktop to be
configured.

Networking must be able to work even in single user mode in a simple
terminal
with a shell session and must not depend on anything else.

Or in other words: Network Manager is too much like Windows and too
little like Unix.

regards
Hadmut