On Thu, 2020-08-27 at 15:44 +0200, Kamil Paral wrote:
On Sat, Aug 22, 2020 at 2:12 AM Adam Williamson
> === 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
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
> 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
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
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net