On May 21, 2013, at 5:03 PM, Dan Williams <d...@redhat.com> wrote: > On Tue, 2013-05-21 at 14:02 -0600, Chris Murphy wrote: >> 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.
OK. I'm glad to read acknowledgement that wired and wireless behaviors are inconsistent, in the Gnome UI context. > >> 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? Gnome > Settings > Network > Gear button > Reset panel: Reset and Forget buttons. The problem is the lack of, and different, feedback with a default profile vs two profiles. > >> 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? The issue is with Gnome Settings, and anaconda's behavior which has changed from F18 to F19. In F18, it sets ONBOOT=on even if a cable isn't attached at the time of the installation. For F19, it sets ONBOOT=off if a cable isn't attached at the time of the installation. The resulting experience in Gnome is inconsistent with Fedora 18, and I'll continue to argue the expectation of a majority of desktop users including admins. >> >> 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". I now understand the relationship between ONBOOT= and the Gnome > Settings > Network > Gear button > Identity > Connect Automatically checkbox. But that understanding postdates the unf'ng believable irritation I experienced setting the Gnome menu bar Wired setting to On, rebooting and not having a network connection. The Connect automatically checkbox is deeply buried, and doesn't effectively communicate itself as the solution to the problem experienced. My expectation is the network state (on vs off) at boot would be tied to its state at the time the user initiated reboot/poweroff. Obviously that's the wrong expectation, but it is the expectation and the UI doesn't dissuade this expectation. In fact it's reinforced because of how anaconda worked in F18. And it's reinforced because of how wireless behaves. > 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. Onboot is more descriptive than automatically, actually. But ONBOOT wasn't the first, second, or fortieth UI object I came into contact with. This is a Gnome and anaconda issue. And actually from anaconda 19.25 to 19.28 there's a change in behavior. With .25, if a cable wasn't connected but a NIC was identified, anaconda's 2nd page is a network connection page, with a Configure button which reveals a window with a set of tabs, one of which includes an option to connect automatically (unchecked, unlike in F18 which it is checked). But in .28 this page doesn't appear at all. So the user has no chance of becoming aware of why the Wired network connection isn't a sticky setting, unless they go exploring multiple layers of Gnome Settings, and just happens to guess that Connect Automatically has something to do with enabling a NIC at boot time. It's too far a leap. > >> 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. Ok except a.) this isn't how it worked in F18. A b.) this isn't how it works in F18 or F19 if the connection is wireless. Wireless networks, overwhelmingly more prone to security risks, have automatic connections after OS installation even if they weren't available at install time; and yet wired networks, in the same scenario, have automatic connections disabled. It really doesn't make sense. If you want to argue that wireless should also be proscribed on boot if it wasn't available at install time, at least that would be consistent. If I'm really concerned about my network being at risk, I'm not making a physical connection to that network until the proper OS settings have been set, or I've fumigated the network itself. I find the whole idea of ONBOOT=off behavior totally specious, still. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
