On platforms where text consoles are a common a text-based network configuration utility is required. Most other tasks that require GUI configuration are fine running in VNC except for obviously the network.
Previous versions of system-configuration-network-tui used to be provided but F18 no longer ships s-c-network or s-c-n-tui.
My understanding is that NM was supposed to have a text offshoot but it currently does not.
I would think ppc64 and 390 are impacted and possibly some ARM footprints.
Adding Phil as he asked me to write this bug to generate some discussion.
That is supposedly now fixed with the latest nm-cli in the latest NM version according to Stephen Gallagher.
Thanks & regards, Phil
I think we are still waiting on something here. If anyone can suggest how we can test whatever was added, I'm happy to do so.
In any case, what's important now than fixing the problem.
The question is:
We know we are planning configuration support in nmcli to be available at some future point. It does not currently exist (only planned, no code). So,
Is a text-base network configuration wizard a fundamental feature that must be in 7.0GA, as opposed to the feature page scoped answer of 7.x?
If so, either:
- Someone needs to maintain s-c-n-tui in RHEL until this support exists. I don't care who.
- Someone needs to write something new to bridge the gap until this support exists. I don't care who, but I find it really strange to intentionally write new throwaway code.
- Someone needs to shift resources to get the nmcli configuration scoped and written for 7.0. Again, I don't care who.
But in all cases, it requires someone to *commit* to helping. Saying 'not it' is not helping.
My main concern are scenarios where network configuration is not done (or needed to be done) within anaconda. One such scenario is a minimal-based install off of media. When the system comes up, it won't be configured for networking unless it's a lease-based network. And because F18 now really wants/enforces people to us NM for network configuration, it's not apparent on how to do this and the utility that is commonly used has been removed – and hence, functionally, we have regressed. Other scenarios exist. My belief is this would impact architectures like ppc64, 390, and ARM and possibly virtual environments for x86.
My two cents is that a text-base dialog is certainly needed for 7.
Nils Philippsen from my team will maintain the package for Fedora and RHEL now as long as we'll need it.
I'll send out owner change requests to for bz and our tooling so we should be able to get it all done in the next few days.
Thanks & regards, Phil
Unfortunately, s-c-network is marked orphan/deprecated in pkgdb, it won't let me take over ownership. Whom do I need to poke to get this resurrected?
Other than that I guess it's a matter of ripping out or disabling the GUI, then merging the rest into the main package with the appropriate dance of obsoletes/conflicts. Is that what you guys had in mind?
Baude - note that with NM, it still supports the exact same ifcfg file syntax that the old network script does. So in the meantime, writing a config file such as ifcfg-em1:
Nils: open a new review request per the policy at https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers
If you link the review request here, I'll try and get it taken care of.
(In reply to comment #12)
> The question is:
> We know we are planning configuration support in nmcli to be available at
> some future point. It does not currently exist (only planned, no code). So,
> Is a text-base network configuration wizard a fundamental feature that must
> be in 7.0GA, as opposed to the feature page scoped answer of 7.x?
Is the planned code a wizard / navigable app, or just limited to nmcli manual invocation? I do think that the default expectation should be that network configuration on headless servers over either local or remote text mode should be preserved, especially from one RHEL to the next.
> If so, either:
> - Someone needs to maintain s-c-n-tui in RHEL until this support exists. I
> don't care who.
> - Someone needs to shift resources to get the nmcli configuration scoped and
> written for 7.0. Again, I don't care who.
Going back to the wizard question: is the nmcli work just covering the functional gap, or will it address usability too? If it just covers the functionality we need but only at CLI level, that still doesn't count as equivalent usability.
I've sent a mail to email@example.com and created a re-review request here: bug #879365