src/nm-dispatcher.c was passing the connection's D-Bus path to the
dispatcher, which was then ignoring it. Meanwhile,
test-dispatcher-envp was passing a fake D-Bus path with the wrong name
(which didn't actually matter since
nm_dispatcher_utils_construct_envp() ignored it anyway).
Fix it so that the path gets exposed as CONNECTION_DBUS_PATH, and
adjust the tests for that.
If we have ENABLE_GTK_DOCS, but not BUILD_SETTING_DOCS, nm-settings.5
nm-settings-keyfile.5 and nm-settings-ifcfg-rh.5 would not be installed.
(It happened on RHEL 7 build, due to missing BuildRequires: pygobject3-base)
Since libnm-core secret-flags properties are now enum-typed rather
than just being uints, we can now actually recognize them when
generating docs, rather than just assuming that every property whose
name ends in '-flags', but isn't in NMSettingDcb, is a secret-flags
property.
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
docs/api/settings-spec.xml was accidentally not getting disted,
because gtk-doc.make explicitly removes all DISTCLEANFILES from
distdir. However, it doesn't actually make sense for the settings docs
files to be in DISTCLEANFILES anyway; they were put there rather than
CLEANFILES (IIRC) so that "make clean" in a tarball build wouldn't
delete them and break things. But the right fix is to just make them
only be in CLEANFILES when BUILD_SETTING_DOCS is true, and not ever
get deleted otherwise.
Also adjust the build rules to ensure that the generated docs don't
get rebuilt in tarball builds, since that can cause problems when
building from a read-only source tree, etc.
Meanwhile, in an unrelated but also fatal bug, configure.ac's check
for if the generated docs were already present never got updated for
the cli/src -> clients/cli move, and so even if we had been disting
settings-spec.xml, configure would still think that the tarball didn't
have all of the generated docs in it, so SETTING_DOCS_AVAILABLE would
be set false and none of the generated docs would get used.
https://bugzilla.gnome.org/show_bug.cgi?id=740035
Synopsis:
nmcli agent { secret | polkit | all }
The command runs separate NetworkManager secret agent or session polkit agent, or both.
It is useful when
- no other secret agent is available (such as GUI nm-applet, gnome-shell, KDE applet)
- no other polkit agent is available (such as polkit-gnome-authentication-agent-1,
polkit-kde-authentication-agent-1 or lxpolkit)
https://bugzilla.gnome.org/show_bug.cgi?id=739568
It is useful for running nmcli without --ask option, i.e. non-interactively.
Example contents of the file:
wifi.psk: s e c r e t 12345
802-1x.password:kili manjaro
802-1x.pin:987654321
It can be used to display connection secrets (passwords). When used, it will
get secrets for the connection profile and merge it into the connection's
settings before displaying it.
Example:
nmcli con show -s hotel-wifi
Only default (infrastructure) mode connections can be created and as it's not
possible to write mode=ap connections with ifcfg-rh plugins, they can't be
switched to mode=ap.
This makes NetworkManager independent of <polkit/polkit.h>
development headers and libpolkit-gobject-1.so library.
Instead communicate directly with polkit using its DBUS
interface.
PolicyKit support is now always compiled in. You can control
polkit authorization with the configuration option
[main]
auth-polkit=yes|no
If the configure option is omitted, a build time default
value is used. This default value can be set with the
configure option --enable-polkit.
This commit adds a new class NMAuthManager that reimplements the
relevant DBUS client parts. It takes source code from the polkit
library.
https://bugzilla.gnome.org/show_bug.cgi?id=734146
Signed-off-by: Thomas Haller <thaller@redhat.com>
man/nm-settings-keyfile.xml is generated via an XSLT stylesheet applied to
libnm-util/nm-keyfile-docs.xml. Then a manual page is generated from the XML.
Certain build configurations (like --enable-gtk-doc
--disable-introspection) were broken with respect to nm-setting-docs.
Fix this. Also, we don't require just gobject-introspection, we need
pygobject specifically as well.
To ensure that NetworkManager does not block needlessly for events
which have no scripts, require scripts that respond to blocking
events to opt into the action.
The script is called synchronously from NetworkManager so it can handle
asynchronicity itself. The long-term plan is to incorporate the script
partially into the new plugin and partially into a dnssec-trigger
library which will be used instead of dnssec-trigger daemon.
https://bugzilla.gnome.org/show_bug.cgi?id=699810
Acked-By: Thomas Haller <thaller@redhat.com>
Acked-By: Dan Williams <dcbw@redhat.com>
This allows setting bridge MAC either on command-line
nmcli con add type bridge con-name mybridge mac 11:22:33:44:55:66
or provide it when asked
nmcli -a con add type bridge con-name mybridge
Interpret the configuration option main.debug and the
environment variable NM_DEBUG as a comma separated list
of debugging options (parsed with g_parse_debug_string()).
Currently only the option "RLIMIT_CORE" is supported, to set
the core dump size to unlimited.
Signed-off-by: Thomas Haller <thaller@redhat.com>
In case of DHCP4, DHCP6 and/or SLAAC, delay "startup complete" until
both IPv4 and IPv6 are ready. This especially has an effect on
nm-online/NetworkManager-wait-online.service, which blocks until
configuration of both IPv4 and IPv6 is ready.
We queue a pending_action when automatic configuration starts and
remove it again, when we receive an address. Before, "startup complete"
was reached when either one of the two IP protocols was configured.
https://bugzilla.redhat.com/show_bug.cgi?id=1086906
Signed-off-by: Thomas Haller <thaller@redhat.com>
