Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Once NetworkManager is stopped, the ifcfg files it created via nmtui\cockpit are incompatible with initscripts, since MASTER=UUID instead of MASTER=device_name
Previously, when creating a Team, Bridge, or Bond slave, NetworkManager wrote the Universally Unique Identifier (UUID) of the master connection to the ifcfg file. This was not compatible with the legacy network service that supports only using the device interface name. With this update, NetworkManager attempts to write a device name in addition to the connection UUID, and compatibility with the legacy network service has been improved.
Note that only UUID is used in case NetworkManager is not able to resolve the master connection into a device name. That is currently the case when slave connections are added before the master connection is saved in the nmtui tool.
the master can be either specified to be the name of an interface or it can be the UUID of another connection. Both is valid from NetworkManager's point of view.
nmtui currently only supports the latter.
It's a valid feature request to also support specifying the interface name. But note that nmtui by design does not support all options to keep the UI simpler. In those cases, nmcli is the expert tool that gives access to every option.
there is svUnsetValue(,) for svSetValueString(,,NULL)
Also, pre-setting all values to NULL and only setting them later is not nice. It's better unset values if-and-only-if they are not to be set.
E.g.:
#the master property
MASTER=bond0
TYPE=Ethernet
results on update in:
#the master property
TYPE=Ethernet
MASTER=bond1
if you only reset the value without clearing it you get:
#the master property
MASTER=bond1
TYPE=Ethernet
Also, unsetting the value unnecessarily, always marks the ifcfg-file as dirty, even if there is no change.
(In reply to Thomas Haller from comment #5)
>
> Also, pre-setting all values to NULL and only setting them later is not
> nice. It's better unset values if-and-only-if they are not to be set.
>
> ...
>
> Also, unsetting the value unnecessarily, always marks the ifcfg-file as
> dirty, even if there is no change.
hm, rethinking this, shvarFile should become more intelligent and handle such cases automatically. It could do so by keeping a backup copy of the originally read values and then:
- only actually store the file to disk if it really changed (maybe optionally,
by having a always_write option).
- it could avoid the reordering issue by merging the changes with the backup
copy.
- it could even remove all keys that were not explicitly touched. Thus, making
the shUnsetValue() calls uneccessary because it would drop all keys that
were not explicitly set. Preferably, not dropping them, but commenting them
out.
Comment 15Francesco Giudici
2017-02-21 17:33:30 UTC
I would just remove the comment here:
--- a/src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-connection.c
+++ b/src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-connection.c
@@ -340,10 +340,6 @@ commit_changes (NMSettingsConnection *connection,
char *ifcfg_path = NULL;
const char *filename;
- /* To ensure we don't rewrite files that are only changed from other
- * processes on-disk, read the existing connection back in and only rewrite
- * it if it's really changed.
- */
filename = nm_settings_connection_get_filename (connection);
if (filename) {
success = writer_update_connection (NM_CONNECTION (connection),
as the connection is no more read back here.
Then found a minor typo in a comment:
--- a/clients/tui/nmt-editor-page.c
+++ b/clients/tui/nmt-editor-page.c
@@ -116,8 +116,8 @@ nmt_editor_page_add_section (NmtEditorPage *page,
* nmt_editor_page_saved:
* @page: the #NmtEditorPage
*
- * This method is called when the user saves the connection. It givesa the
- * page a chance to do save its data outside the connections (such as
+ * This method is called when the user saves the connection. It gives
+ * the page a chance to save its data outside the connections (such as
* recommit the slave connections).
*/
Branch lgtm.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2017:2299