On Thu, 2020-08-27 at 15:44 +0200, Kamil Paral wrote: > On Sat, Aug 22, 2020 at 2:12 AM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> > wrote: > > > === Network requirements === > > > > Each of these requirements apply to both installer and installed system > > environments. For any given installer environment, the 'default network > > configuration tools' are considered to be those the installer documents > > as supported ways to configure networking (e.g. for anaconda-based > > environments, configuration via kernel command line options, a > > kickstart, or interactively in anaconda itself are included). > > > > ==== Basic networking ==== > > > > It must be possible to establish both IPv4 and IPv6 network connections > > using DHCP and static addressing. The default network configuration > > tools for the console and for release-blocking desktops must work well > > enough to allow typical network connection configuration operations > > without major workarounds. > > > I'm a bit confused here. If you specifically say "for the console and for > release-blocking desktops", does that mean it doesn't apply to the > installer? Because at the top you say it applies to both, but here it > sounds very specific. No, I didn't intend that, I was just making sure to cover both console and desktop. We can make it "for the console, for release-blocking desktops and for installer environments" if you like. > If it applies to the installer, does this mean that *all* ways to configure > this in the installer must work (i.e. kernel cmdline, kickstart, gui, tui)? > That seems quite demanding for a Basic criterion. That's kind of a tricky one, because I agree it's broad, but on the other hand there are situations where you kinda need each of them. You can't always have a monitor and a human to do it interactively in the install environment, and if you're retrieving a kickstart or the installer environment itself (after a PXE boot, say) over the network, you need the kernel cmdline case to work. So, I mean, it's difficult. We *could* split it across Basic and Final, but I can't immediately see a clear rationale for how to do that. Any ideas? I guess we could look at what the criteria require for things like kickstart and PXE boot and try to align them... > > Using the default network configuration tools for the console and for > > release-blocking desktops, it must be possible to establish a working > > connection to common OpenVPN, openconnect-supported and vpnc-supported > > VNC servers with typical configurations. > > > > Just out of curiosity, why isn't this "OpenVPN, openconnect and vpnc VPN > servers", but instead it is "-supported" for the latter two? Well, openconnect supports multiple different VPN servers. "OpenConnect is an SSL VPN client initially created to support Cisco's AnyConnect SSL VPN. It has since been ported to support the Juniper SSL VPN (which is now known as Pulse Connect Secure), and the Palo Alto Networks GlobalProtect SSL VPN." vpnc only really supports Cisco IPsec servers, but they aren't really called "vpnc VPN servers". vpnc is just the name of the third-party client for such VPNs that NetworkManager-vpnc wraps. So "vpnc-supported servers" seems more correct than "vpnc servers". Looking at https://wiki.gnome.org/Projects/NetworkManager/VPN , there are several other plugins my draft doesn't list. I'm not sure if any of them is common enough that we should block on it. Anyone have an idea about that? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
