GNOME Bugzilla – Bug 776276
[RFE] NetworkManager connections should support generic user-data key-value strings
Last modified: 2020-11-12 14:29:40 UTC
It would be useful to allow the user to attach arbitrary data to connections. The data should be in form of string-string dictionaries. I think the value could be any valid utf8 string ('\0' terminated). A key in addition should be one or more path segments (delimited by '.') followed by a name. Empty path or name is not allowed. E.g. org.freedesktop.nm-applet.my-value-1 With the path being "org.freedesktop.nm-applet" and the name "my-value-1" let's also restrict the valid characters in the key to [a-zA-Z0-9_-+/=]. Note that this contains all the characters to encode path-segments or the name in base64 (but the path-segmenents or name are not in base64 encoding from NetworkManager's point of view). NetworkManager would entirely ignore any user-data fields. They exist only for users to attach arbitrary data to connections. Note that the key's path cannot be empty, to enforce namespacing of the values. Users are encouraged to restrict themself to their own namespace. Usage example: - nm-connection-editor stores the value for "No CA certificate is required" outside of the connection in the users gsettings. It could instead store the flag inside the connection: "org.freedesktop.nm-applet.ca-cert-required" = "0" - a user could tag connections for example with "my.tag" = "office" "my.tag" = "home" then he could for example have a dispatcher scripts: TAG="$(nmcli -m tabular -t -f user.my.tag connection show uuid "$CONNECTION_UUID")" if [[ "$TAG" == office ]]; then ... The uses are really unlimited. As in the example above, nmcli should unpack the keys, that is: $ nmcli connection show $NAME ... user.my.tag: "office" user.freedesktop.nm-applet.ca-cert-required: "0" $ nmcli connection modify $NAME user.my.tag "office"
> libnm: add NMSettingUser +static gboolean +compare_property (NMSetting *setting, + NMSetting *other, + const GParamSpec *prop_spec, + NMSettingCompareFlags flags) + [...] + g_hash_table_iter_init (&iter, priv->data); + while (g_hash_table_iter_next (&iter, (gpointer *) &key, (gpointer *) &value)) { + if (!g_hash_table_lookup_extended (pri2->data, key, NULL, (gpointer *) &valu2)) + return FALSE; + if (!nm_streq (value, valu2)) + return FALSE; + } When the property is NM_SETTING_USER_DATA, I think we should not chain up? -- +static void +get_property (GObject *object, guint prop_id, + GValue *value, GParamSpec *pspec) +{ + [...] + case PROP_DATA: + data = _create_data_hash (); + if (priv->data) { + g_hash_table_iter_init (&iter, priv->data); + while (g_hash_table_iter_next (&iter, (gpointer *) &key, (gpointer *) &val)) + g_hash_table_insert (data, (gpointer) key, (gpointer) val); A copy of @key and @val should be added to the new hash table. -- +static void +set_property (GObject *object, guint prop_id, + const GValue *value, GParamSpec *pspec) +{ Why existing keys/values are checked and not the ones to be inserted. Also, this looks wrong: + g_hash_table_iter_init (&iter, priv->data); + while (g_hash_table_iter_next (&iter, (gpointer *) &key, (gpointer *) &val)) + g_hash_table_insert (priv->data, (gpointer) key, (gpointer) val); + break; -- + /* ---ifcfg-rh--- + * property: data + * variable: NM_USER_DATA_KEY*(+), NM_USER_DATA_VAL*(+) + * description: User data for the connection profile. + * ---end--- + */ Can this be moved to the commit that adds ifcfg-support? The NMSettingUser API looks good to me. I have still to look at the rest of commits about meta-data support in nmcli.
fixed all and repushed.
merged patch https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=4ec7dd987e5f05dd0889f2d417c93a605b15be46 The functionality is not yet there, it blocks on nmcli changes. This only adds the settings class so that the libnm API gets into 1.8.0 early. It will be enabled later.
Cool branch. Just spotted an issue: @@ -851,22 +851,14 @@ parse_output_fields (const char *fields_str, for (i = 0; fields_array[i].name; i++) { if (strcasecmp (left, fields_array[i].name) == 0) { - const NmcOutputField *valid_names = fields_array[i].group_list; const NmcSettingInfo *setting_info = fields_array[i].setting_info; idx = i; - if (!right && !valid_names && !setting_info) { + if (!right && !setting_info) { found = TRUE; break; } - if (valid_names) { - for (j = 0; valid_names[j].name; j++) { - if (!right || strcasecmp (right, valid_names[j].name) == 0) { - found = TRUE; - break; - } - } - } else if (setting_info) { + if (setting_info) { for (j = 1; j < setting_info->properties_num; j++) { if (!right || strcasecmp (right, setting_info->properties[j].property_name) == 0) { found = TRUE; I think this breaks "nmcli -f ip4.address connection show <conn>" and every field where the property is an active group one. parse_output_fields() is called also by nmc_active_connection_details() and receives "nmc_fields_con_active_details_groups" as const NmcOutputField fields_array[]
additional fixes merged, including proper keyfile + ifcfg-rh support. master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=0b6490f3d88c58597f288b63ed7e6d51ca21f2bf nm-1-8: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=fd6f4b0ef8bec0569d2227f67d77a161ca916858 still missing is nmcli support.
Since there still is no support from nmcli, have a look at the python example instead: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python/gi/setting-user-data.py?id=c905ee94f09e76db917a684a2fb44d83886475f5
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).