summaryrefslogtreecommitdiff
path: root/clients
Commit message (Collapse)AuthorAgeFilesLines
* clients: avoid compiler warning about redefining NDEBUG for qrcodegenThomas Haller2020-01-151-0/+1
| | | | | | | | [1/5] Compiling C object 'clients/common/913ef36@@nmc-base@sta/nm-client-utils.c.o'. ../clients/common/nm-client-utils.c:528: warning: "NDEBUG" redefined 528 | #define NDEBUG | <command-line>: note: this is the location of the previous definition
* libnm-core,cli: add VRF settingBeniamino Galvani2020-01-143-1/+30
| | | | | Add new VRF setting and connection types to libnm-core and support them in nmcli.
* cli: don't use GIOChannel to watch plain file descriptor for ↵Thomas Haller2020-01-131-7/+13
| | | | nmc_readline_helper()
* tui: don't use GIOChannel to watch plain file descriptor for key pressThomas Haller2020-01-131-14/+10
|
* all: use nm_g_unix_fd_source_new() instead of g_unix_fd_source_new()Thomas Haller2020-01-132-16/+19
| | | | | Its source-func argument has the right signature. Otherwise, this is an easy to make mistake.
* tui: fix signature for nmt_newt_form_keypress_callback() callbackThomas Haller2020-01-131-1/+1
| | | | Fixes: 3bda3fb60c10 ('nmtui: initial import of nmtui')
* clients/polkit: signal error when polkit setuid helper cannot be spawnedAntonio Cardace2019-12-241-0/+8
| | | | | | Also the child fds are set to -1 so that nm_close() doesn't throw an assertion. Fixes: df1d214b2 (clients: polkit-agent: implement polkit agent without using libpolkit)
* clients: nm-polkit-listener: fix segfault when a session id for a given uid ↵Antonio Cardace2019-12-241-3/+4
| | | | is not found
* clients: polkit-agent: implement polkit agent without using libpolkitAntonio Cardace2019-12-246-444/+896
|
* clients,libnm-core: zero-out memory used to store plain-text secretsAntonio Cardace2019-12-182-2/+4
|
* common: readline: fix memory leak of plain text secretAntonio Cardace2019-12-181-1/+5
| | | | | | | | After a user entered a secret it would get stored in the readline history data structure (in plain text) and eventually get leaked. This commit instructs readline to not store any secret in its history and fixes a non-related memory leak.
* all: fix wrong "gs_free GError *" declarationsThomas Haller2019-12-161-1/+1
| | | | This is a bug and leads either to a leak or a crash.
* all: rename time related function to spell out nsec/usec/msec/secThomas Haller2019-12-133-6/+6
| | | | | | The abbreviations "ns" and "ms" seem not very clear to me. Spell them out to nsec/msec. Also, in parts we already used the longer abbreviations, so it wasn't consistent.
* cloud-setup/trivial: rename timeout_ms to timeout_msecThomas Haller2019-12-134-13/+13
| | | | | I think "ms" as abbreviation is too short and unclear. Also, it's not used consistently. Rename variable.
* clients/tests: add test for selecting fields from multiple connections with ↵Thomas Haller2019-12-132-818/+2153
| | | | `nmcli con show`
* clients/tests: support Util.replace_text_sort_list() helperThomas Haller2019-12-131-0/+6
| | | | | | | This will be necessary to sort a list of text that contains text to replace. The use case is to get all UUIDs from the server, but some of these UUIDs are dynamic. So, in order to have a fixed sort order, we need to handle sorting the list, based on the replacement.
* clients/tests: add NMStubServer.findConnections() helper functionThomas Haller2019-12-131-5/+9
| | | | Will be used to get all connection from the test stub server.
* clients/tests: support replacing UUIDs in command textThomas Haller2019-12-131-0/+8
| | | | | | | We want to issue a nmcli command with the connection's UUID in the command line. As the command line is stored to disk and compared, we cannot use UUIDs that are randomly generated. Instead, we need to support replacing the text in the command line.
* clients/tests: fix wrongly constructing command line string as tuple in ↵Thomas Haller2019-12-131-1/+1
| | | | | | | TestNmcli It had no bad effect, but the cmd was a tuple with one string, and not a string.
* clients/tests: support string arguments to Util.replace_text()Thomas Haller2019-12-131-1/+8
|
* clients/tests: rename "replace_stdout" variable to "replace_uuids"Thomas Haller2019-12-131-64/+64
| | | | | | The variable name should say what it is, not what it is used for. E.g. we would use the very same replacements for stderr. Rename so that it can (by its name) used for different purposes.
* cli: expose device D-Bus pathBeniamino Galvani2019-12-104-880/+1180
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1745574
* doc: clarify default values for ipv4.mdns and ipv4.llmnr settingsThomas Haller2019-12-101-2/+2
| | | | | | | | | | | | | | | | | | | | | LLMNR and mDNS settings can have their global default value configured in "NetworkManager.conf". Global default values should work the way that all regular values of the property can be configured explicitly in the connection profile. The special "default" value only indicates to allow lookup of the global default, but it should not have a meaning of its own. Note that if mDNS/LLMNR settings are left unspecified, we will set the argument to SetLinkMulticastDNS() and SetLinkLLMNR() functions to "", which means that systemd-resolved decides on a default. Also, depending on the DNS plugin, the default value differs. This is all fine however. In this case, the ultimate default value depends on other things (like the DNS plugin), but each possible value is in fact explicitly configurable. We also do that for "ipv6.ip6-privacy". Anyway, cleanup the documentation a bit and try to better explain what the default is.
* cli: don't fetch permissions for NMClient in nmcli unless requiredThomas Haller2019-12-102-40/+53
| | | | | | | | | | | | | | | | | This avoids unnecessarily fetching permissions, which are not needed most of the time. During `nmcli general permissions` we require to fetch the permissions. This is now solved better, because previously the code waited for any permissions to be not UNKNOWN. That was a hack, because there are cases where all permissions would be UNKNOWN (hidepid mount option) and nmcli would hang. There is a downside too: for `nmcli general permissions` we now first need to wait for NMClient to initialize, before starting to fetch permissions. Previously, we would call GetPermissions() in parallel with initializing NMClient. It now takes longer. That should be fixed be refactoring the code in nmcli to not wait for NMClient to be fully initialized, before requesting the permissions.
* cli: use nmc_client_new_async() instead of nm_client_new_async()Thomas Haller2019-12-102-4/+14
| | | | | This will allow us to set construct parameters to the instance, like NM_CLIENT_INSTANCE_FLAGS.
* nm-online: don't fetch permissions for NMClient in nm-onlineThomas Haller2019-12-101-0/+1
| | | | nm-online doesn't care about the permissions. Don't fetch them.
* nm-online: use nmc_client_new_async() instead of nm_client_new_async()Thomas Haller2019-12-102-12/+18
| | | | | This will allow us to set construct parameters to the instance, like NM_CLIENT_INSTANCE_FLAGS.
* cloud-setup: don't fetch permissions for NMClient in nm-cloud-setupThomas Haller2019-12-101-0/+1
| | | | nm-cloud-setup doesn't care about the permissions. Don't fetch them.
* cloud-setup: reuse nmc_client_new_waitsync() to create NMClient instanceThomas Haller2019-12-102-62/+26
|
* tui: don't fetch permissions for NMClient in nmtuiThomas Haller2019-12-101-0/+1
| | | | nmtui doesn't care about the permissions. Don't fetch them.
* tui: create NMClient instance via async initThomas Haller2019-12-102-2/+7
| | | | | | | | Using sync init (nm_client_new()) has an overhead as it requires an internal GMainContext to ensure preserving the order of D-Bus messages. Let's avoid that by using the async init. Note that the difference here is that we will iterate the caller's GMainContext while creating the instance. But that is no problem for nmtui at that point.
* cli: sort permission in output of `nmcli general permissions`Thomas Haller2019-12-102-514/+513
|
* libnm,cli: cleanup mapping between NMClientPermission and stringsThomas Haller2019-12-101-38/+2
|
* core: also return unknown permission check resultThomas Haller2019-12-101-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For example with mount -o remount,rw,hidepid=1 /proc/ all permission checks will fail with an error. Internally, we map the failure to NM_AUTH_CALL_RESULT_UNKNOWN. <trace> [1575645672.5958] auth: call[1069]: CheckAuthorization(org.freedesktop.NetworkManager.enable-disable-connectivity-check), subject=unix-process[pid=468316, uid=1000, start=1912881] <trace> [1575645672.6295] auth: call[1069]: completed: failed: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code4: Failed to open file “/proc/468316/status”: No such file or directory <debug> [1575645672.6296] manager: unknown auth chain result 0 First of all, we should not log a debug message about that (we already log the result of permission checks separately). Also, we should include the unknown result in the response. The permission was checked, and omitting it from GetPermissions() result seems wrong (even if we failed to get the result). Note that "unknown" is now a new possible return value on D-Bus. But see how nm_permission_result_to_client() would map such a value to "unknown" as well. So, it's probably a fine extension of the D-Bus API. Note that NMClient API is currently quite limited. The user won't know whether permissions were received (and if they were received, they could not distinguish between UNKNOWN and absent). Hence, returning all permissions as unknown (or not at all) causes `nmcli general permissions` to hang. The solution here is to improve NMClient API to allow the user to know when the permissions are received. But this patch doesn't fix the hanging of nmcli nor the limitation of NMClient's API.
* client/tui: add OWE supportDavid Bauer2019-12-052-0/+10
|
* client/cli: add support for OWE key management flagDavid Bauer2019-12-051-3/+11
|
* clients/secret-agent: don't require secrets for OWE connectionsDavid Bauer2019-12-051-1/+1
|
* clients/meta-setting-desc: allow setting wifi-sec.key-mgmt to OWEDavid Bauer2019-12-051-1/+1
|
* libnm-core/setting-wireless-security: add support for OWE key-managementDavid Bauer2019-12-051-1/+1
|
* cloud-setup: mark environment variables that are supported configurationThomas Haller2019-12-033-4/+13
| | | | | | "nm-cloud-setup" can by configured via environment variables. Mark all the names of such variables with NMCS_ENV_VARIABLE() macro. This allows to grep for them.
* cloud-setup: require to explicitly opt-in for providers via environment variableThomas Haller2019-12-034-3/+19
| | | | | | | | | | | | | | | | | | | "nm-cloud-setup" is supposed to work without configuration. However, it (obviously) fetches data from the network you are connected to (which might be untrusted or controlled by somebody malicious). The tool cannot protect you against that, also because the meta data services uses HTTP and not HTTPS. It means, you should run the tool only when it's suitable for your environment, that is: in the right cloud. Usually, the user/admin/distributor would know for which cloud the enable the tool. It's also wasteful to repeatedly probe for the unavailable cloud. So, instead disable all providers by default and require to opt-in by setting an environment variable. This can be conveniently done via `systemctl edit nm-cloud-provider.service` to set Environment=. Of course, a image can also pre-deploy such am override file.
* cloud-setup: let dispatcher script run tool only if service is enabledThomas Haller2019-12-032-1/+7
| | | | | | | | | | | | | | | | | | We don't want that when the user installs the package, that the dispatcher script automatically executes the tool. Instead, the user should use `systemctl enable/disable` to control whether the service is active (of via the timer). Hence, let the dispatcher script check whether the service is enabled. That leads to a different problem, that we need to make it possible for "nm-cloud-setup.service" to be enabled in the first place. As such, add a [Install] section and let it be wanted by NetworkManager.service. The problem with this is that now the tool will run very early, just after NetworkManager started. At that point, it might not yet have setup networking. But that should be acceptable, after all, the tool either fails to fetch meta data that early, or it succeeds. Very likely, it will by aborted by dispatcher's restart command.
* cloud-setup: enable more sandboxing in systemd unitThomas Haller2019-12-031-0/+19
|
* cloud-setup: add tool for automatic IP configuration in cloudThomas Haller2019-11-2814-0/+3410
| | | | | | | | | | | | | | | | | | | | | | | | This is a tool for automatically configuring networking in a cloud environment. Currently it only supports IPv4 on EC2, but it's intended for extending to other cloud providers (Azure). See [1] and [2] for how to configure secondary IP addresses on EC2. This is what the tool currently aims to do (but in the future it might do more). [1] https://aws.amazon.com/premiumsupport/knowledge-center/ec2-ubuntu-secondary-network-interface/ It is inspired by SuSE's cloud-netconfig ([1], [2]) and ec2-net-utils package on Amazon Linux ([3], [4]). [1] https://www.suse.com/c/multi-nic-cloud-netconfig-ec2-azure/ [2] https://github.com/SUSE-Enceladus/cloud-netconfig [3] https://github.com/aws/ec2-net-utils [4] https://github.com/lorengordon/ec2-net-utils.git It is also intended to work without configuration. The main point is that you boot an image with NetworkManager and nm-cloud-setup enabled, and it just works.
* libnm: add ipvx.dhcp-hostname-flags propertiesBeniamino Galvani2019-11-284-632/+922
| | | | | | | | | | | | When using the dhclient DHCP backend users can tweak the behavior in the dhclient configuration file. One of the options that was reported as useful in the past was the FQDN flags [1] [2]. Add native support for FQDN flags to NM by introducing new ipv{4,6}.dhcp-hostname-flags properties. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1684595 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1255507
* all: add device carrier flagBeniamino Galvani2019-11-224-592/+821
| | | | | | | | | Add a new 'carrier' flag to the InterfaceFlags property of devices to indicate the current carrier state. The new flag is equivalent to the 'lower-up' flag for all devices except the ones that use a non-standard carrier detection mechanism like NMDeviceAdsl.
* cli: print interface flagsBeniamino Galvani2019-11-224-408/+1269
|
* ovs: allow changing mac address of bridges and interfacesBeniamino Galvani2019-11-201-0/+1
| | | | | | | | | | | | | Allow changing the cloned MAC address for OVS bridges and interfaces. The MAC address set on the bridge is propagated by ovs to the local interface (the one with the same name as the bridge), while all other internal interfaces use the address defined in the interface connection. https://bugzilla.redhat.com/show_bug.cgi?id=1763734 https://bugzilla.redhat.com/show_bug.cgi?id=1740557 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/321
* all: support 'stable' DHCP IAIDbg/dhcp-iaid-rh1749358Beniamino Galvani2019-11-111-2/+2
| | | | | Support a new DHCP IAID special value 'stable' that generates the IAID based on the stable-id, a per-host key and the interface name.
* all: add ipvX.dhcp-iaid propertiesBeniamino Galvani2019-11-114-632/+912
| | | | | Add new ipv4.dhcp-iaid and ipv6.dhcp-iaid properties to specify a DHCP IAID.
View Lorry Controller Status