After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 776276 - [RFE] NetworkManager connections should support generic user-data key-value strings
[RFE] NetworkManager connections should support generic user-data key-value s...
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: IP and DNS config
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on: 776279
Blocks:
 
 
Reported: 2016-12-19 14:29 UTC by Thomas Haller
Modified: 2020-11-12 14:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Thomas Haller 2016-12-19 14:29:34 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"
Comment 1 Beniamino Galvani 2017-03-28 10:09:32 UTC
> 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.
Comment 2 Thomas Haller 2017-03-28 11:24:48 UTC
fixed all and repushed.
Comment 3 Thomas Haller 2017-03-28 13:01:47 UTC
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.
Comment 4 Francesco Giudici 2017-03-28 13:38:58 UTC
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[]
Comment 5 Thomas Haller 2017-05-06 13:00:52 UTC
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.
Comment 6 Thomas Haller 2018-05-15 12:31:37 UTC
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
Comment 7 André Klapper 2020-11-12 14:29:40 UTC
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).