wired ethernet disabled between reboots, was: when startup delays become bugs

[Dan Williams]

On Tue, 2013-05-21 at 14:02 -0600, Chris Murphy wrote:
> On May 21, 2013, at 1:09 PM, Dan Williams <dcbw at redhat.com> wrote:
> >>> 
> >>> 
> >>> But this bug has brought me to a plethora of buggy behavior in the Gnome Settings Network panel, so maybe the misery was worth it.
> >> 
> >> *THIS*. *This* kind of thing is why NetworkManager remains unusable
> >> for production network configuratoin. The very powerful and flexible
> >> shell scripting written into the /etc/sysconfig/network-scripts
> >> infrastructure is neither pro0perly displayed by nor manageable by the
> >> NetworkManager gui's. It is not even a good GUI becuase it violates
> >> over half of the open source GUI guidelines published by Eric Raymond
> >> in his essay on GU's, "The Luxury of Ignorance".
> > 
> > I'd be very interested to know how, exactly, the network-scripts are
> > "neither properly displayed nor manageable".  What options in the
> > scripts do you not find in the GUI?
> 
> I think he's talking about buggy behavior rather than lake of parity. I have mind to file bugs on what I've experienced but the summary is:
> 
> 1. Connect Automatically may work as designed, but it's a flawed design. It makes no sense to have an admin user enable a network through the Gnome shell toolbar icon (Network icon, flip the switch from Off to On), reboot, and then have no network. The widespread convention for all other such UI switches is that they're sticky. I don't have to go make them behave sticky by checking something five layers deep. Something I wouldn't have even considered exists as it's apparently unique, I've never encountered an automaticity option on Windows or OS X. It's a bizarre convention. Off means off, make that sticky through reboots. On means on, make that sticky through reboots.

If you're talking about the GNOME Shell on/off switch next to wired
interfaces, that was implemented in the Shell for the sake of
consistency with other interface types, but has no backing in the
NetworkManager core.  We'd need additional changes to support some kind
of sticky on/off function for wired/bond/bridge/vlan/infiniband like we
currently have for wifi/wimax/wwan.

> 2. The two buttons on the reset page, don't do anything. I click them, nothing happens. Only if I add one or more new profiles do those buttons do anything.

Which "reset" page do you mean here?  gnome-control-center?
nm-connection-editor?  Something else?

> 3. The naming convention of the interfaces is confusing. Sometimes it's ifcfg-en5s0 and sometimes ifcfg-p5p1 for the same interface and I don't know why. And even something in the network stack gets confused, while anaconda with a cable unattached install creates one settings file, isn't later honored until I rename it as p5p1 or whatever.

Interface naming is all udev, nothing to do with NetworkManager.

> It's is sorta like no one has used this and bothered to file bugs on the behavior. Myself included. It's just a lot of really negative user experience, with a lot of testing and bugs to be file to describe the wonky behaviors.
> 
> 
> >  And if so, please state *which*
> > GUI, whether that's GNOME control center, nm-connection-editor, or KDE's
> > network panel.
> 
> Gnome > Settings > Network

Ok, so the issues are with the GNOME control center network panel, not
specifically the NM core daemon?

> >  Also note the NetworkManager daemon and API usually
> > provides the full range of functionality, customization, knobs,
> > twiddles, properties, etc, and it's up to the GUIs to figure out what to
> > display.  There's also nmcli, which we're furiously working on to expose
> > everything admins may need without a GUI.
> 
> Maybe someone can explain to me the use case for ONBOOT= where its value isn't tied to the current network state. I wasted an inordinate,  unreasonable amount of time trying to figure this out before I realized what was going on.

Hmm, not sure what you mean by "isn't tied to current network state".
ONBOOT=yes means "automatically attempt to connect to this network",
while ONBOOT=no means "I'll tell you went to connect to this network".
ONBOOT of course is a somewhat historical name, but that's what's been
used since the beginning of time to mean "do something automatically",
either at boot or via the ifup/ifdown hotplug functionality from the
udev rules that we used to install.

> An necessarily this relates to anaconda because it's setting up the weird behavior only for cabled ethernet connections lacking a cable at the time of the install. Yet it doesn't work this way for WiFi. It's inconsistent.

This has been discussed to death over the years, actually, because for
various security reasons, if you don't install over the network, this
may mean you don't actually want network connections immediately enabled
when you reboot, to minimize your network-facing risk until you've
configured things.  IIRC.

Dan