Bug 836782 - NM flawed design needs changes
Summary: NM flawed design needs changes
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 17
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-01 09:51 UTC by udo
Modified: 2012-08-29 13:40 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-08-29 13:32:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description udo 2012-07-01 09:51:41 UTC
Description of problem:
After migrating a ferfectly working Fedora 16 box to Fedora 17 I found that the ethernet interface got a DHCP number instead of the configured static IP.
I found that  after dowing: ifdown eth0; ifup eth0 the desired static IP was assigned.
I concluded that NM was the fault.
I found that NM has an administration of its own.
I found that none of the existing correct configuration was migrated to this new situation.
I found that this NM administration has doubled info from the ifcfg-eth0 script.


Version-Release number of selected component (if applicable):
NetworkManager-0.9.4.0-9.git20120521.fc17.x86_64

How reproducible:
Upgrade.


Actual results:
See above

Expected results:
No doubling of configuration info, no change in configured behaviour 

Additional info:
We really need a much simpler version of NM without all the strange ideas but with the possibility to use a GUI to configure a network device; this simpler NM should NOT have a mind of its own.

Comment 1 Pavel Šimerda (pavlix) 2012-08-29 10:18:18 UTC
Please use descriptive summaries. This one is useless.

Please attach configuration files, logs, as much information as you can.

Comment 2 udo 2012-08-29 13:05:30 UTC
I corrected the situations and described what I could.
So I cannot currently easily reproduce the situation.

NM is a pain in the butt.
NM cannot cope with hardware without a static hardware address. (fact)
NM chooses not to trust udev which is THE place for device naming. (fact)
NM keeps a separate administration from teh 101% working network scripts, duplicating stuff for no reason. (the root cause for this bug) (fact!)

So no real logs are neded.just a chat with the main developer(s).
All these issues occur with simple wired connections. No wireless, no ppp, no ipv6-related issues.

Comment 3 Pavel Šimerda (pavlix) 2012-08-29 13:32:13 UTC
Please submit individual bug reports with steps to reproduce, observed behavior and expected behavior. Or write a blogpost on how NetworkManager sucks.

Comment 4 udo 2012-08-29 13:40:02 UTC
The source is there to prove these hard accusations.
If you let a dev run loose to create this Frankenstein then it was not my fault.

I forgot to mention the dependency-hell.


As you may understand I use this system daily.
So after upgrading I make it work ASAP.
Only afterwards, when IP works again, I can think about filing reports.
The other issues are longer standing and make one wonder about the design process.


Note You need to log in before you can comment on or make changes to this bug.