summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* device: let slaves wait in IP_CONFIG until master is readybg/nested-slavesBeniamino Galvani2017-05-041-0/+12
| | | | | | | | | | We call nm_device_activate_stage3_ipX_start() in various places, e.g. after a carrier change or when a master enslaves a new device to configure IP for the device. If the device is a slave in state IP_CONFIG, this makes it transition to IP_CHECK, while it should stay in IP_CONFIG until the master becomes ready. When the master is ready, it will move slaves directly to SECONDARIES, skipping IP configuration entirely.
* device: avoid integer overflow with route-metric penaltyThomas Haller2017-05-021-10/+18
| | | | (cherry picked from commit bd805b7e49849c76e4bd273799ae84c718033dc0)
* policy: fix memleak in lookup_callback() and cancellingThomas Haller2017-05-021-13/+11
| | | | | | | | | | | | | When the operation is cancelled, we must not touch user_data. Note that NM_POLICY_GET_PRIVATE() theoretically doesn't dereference the pointer (does it?) but doing pointer arithmetic on a dangling pointer is a very ugly thing to do. And of course, the memleak. Fixes: 5c716c8af8ddca1d3f7510494754d875b01a8889 Fixes: a2cdf632045d60b26f7aff470dedb56c1f9b938d (cherry picked from commit 3215508293c26e9e8531c2482def598ef1bbbefd)
* dhcp: dhclient: fix timeout greater than 60 secondsBeniamino Galvani2017-05-023-0/+23
| | | | | | | | | | | | The default timeout in dhclient is 60 seconds; if a lease can't be obtained during such interval, dhclient sends to NM a FAIL event and then the IP method fails. Thus, even if user specified a greater dhcp-timeout, NM terminated DHCP after 60 seconds. Fix this by passing an explicit timeout to dhclient. (cherry picked from commit 82ef497cc9e2728e73cb0426efbae85c83bec3fe)
* ifcfg-rh/tests: fix test_write_unknown() after change svGetValue() for ↵Thomas Haller2017-04-271-1/+1
| | | | | | | invalid values Fixes: daaa741a3d4bddcfd01715fd6caf7d0c84107a6d (cherry picked from commit 43c3501f978aeb783b363bff923e781302736985)
* ifcfg-rh: preserve the archaic NETMASK keyLubomir Rintel2017-04-271-2/+11
| | | | | | | | | | py-kickstart writes this out and there apparently are users using this. Let them have one less problem. Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=1445414 (cherry picked from commit dbe0659ba419a77ad5ff2340bfc93c71a1bec61a)
* ifcfg-rh: preserve the archaic BOOTPROTO=static formLubomir Rintel2017-04-271-4/+9
| | | | | | | | py-kickstart writes this out. Okay -- we don't care on read and it makes sense when there actually are addresses. https://bugzilla.redhat.com/show_bug.cgi?id=1445414 (cherry picked from commit aa50dfc236b3806c6d7161cdea450655a1268f0d)
* ifcfg-rh: treat a wrongly quoted value like empty stringThomas Haller2017-04-271-2/+13
| | | | | | | | | | | | | | | | | | | | For example, if you want to test whether a value is present and reset it to a different value (only if it is present), it would be reasonable to do if (svGetValue (s, key, &tmp)) { svSetValue (s, key, "new-value"); g_free (tmp); } Without this patch, you could not be sure that key is not set to some inparsable value, which svWriteFile() would then write out as empty string. Have invalid values returned by svGetValue() as empty string. That is how svWriteFile() treats them. (cherry picked from commit 6470bed5f1ad25e20df14b333f1b083c9b390ece)
* core: make dad_counter argument guint32 typeThomas Haller2017-04-273-7/+7
| | | | | | | | | | | | | | | | | | The dad_counter is hashed into the resulting address. Since we want the hashing to be independent of the architecture, we always hash 32 bit of dad_counter. Make the dad_counter argument of type guint32 for consistency. In practice this has no effect because: - for all our (current!) architectues, guint is the same as guint32. - all callers of nm_utils_ipv6_addr_set_stable_privacy() keep their dad-counter argument as guint8, so they never even pass numbers larger then 255. - nm_utils_ipv6_addr_set_stable_privacy() limits dad_counter further against RFC7217_IDGEN_RETRIES. (cherry picked from commit 951e5f5bf87df01c603c9cbe69f401bfdfbbd579)
* core: avoid generating reserved IPv6 interface identifiersThomas Haller2017-04-271-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://tools.ietf.org/html/rfc7217 says: The resulting Interface Identifier SHOULD be compared against the reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] and against those Interface Identifiers already employed in an address of the same network interface and the same network prefix. In the event that an unacceptable identifier has been generated, this situation SHOULD be handled in the same way as the case of duplicate addresses (see Section 6). In case of conflict, this suggests to create a new address incrementing the DAD counter, etc. Don't do that. If we generate an address of the reserved region, just rehash it right away. Note that the actual address anyway appears random, so this re-hashing is just as good as incrementing the DAD counter and going through the entire process again. Note that now we no longer generate certain addresses like we did previously. But realize that we now merely reject (1 + 16777216 + 128) addresses out of 2^64. So, the likelyhood of of a user accidentally generating an address that is suddenly rejected is in the order of 10e-13 (1 / 1,099,503,173,697). Which is not astronomically, but still extreeeemely unlikely. Also, the whole process is anyway build on the idea that somebody else might generate conflicting addresses (DAD). It means, there was always the extremely tiny chance that the address you generated last time is suddenly taken by somebody else. So, this change appears to a user like these reserved addresses are now claimed by another (non existing) host and a different address gets generated -- business as usual, as far as SLAAC is concerned. (cherry picked from commit f15c4961ad02a1edf766f140dd94e2d5449f8d82)
* core: move NMIPAddr to nm-core-utils.hThomas Haller2017-04-274-22/+23
| | | | (cherry picked from commit 67da0a28db834192d207fb315a3ba1983fe4a79e)
* ifcfg-rh/tests: fix out-of-tree build for cexpected fileThomas Haller2017-04-271-1/+1
| | | | | Fixes: f04bf45e84bddb7d685b03b9b36088848a46e75d (cherry picked from commit 5fc4bfc0e356444c294d1d8d839c62d56e2f4507)
* device: disable delegating prefixes to the device when the IPv6 config is ↵Lubomir Rintel2017-04-271-1/+4
| | | | | | | | | | | removed Fixes a crash where the default DNS domain to be announced together with the prefixes to be delegated is updated at the same time the device is being unrealized. https://bugzilla.redhat.com/show_bug.cgi?id=1425818 (cherry picked from commit 3e076cf8b1eba4937e1462d2ca34b9a65f500aff)
* libnm-core,shared: fix typo in '(allow-none)' annotationBeniamino Galvani2017-04-273-3/+3
| | | | (cherry picked from commit d19553392bca006174c2fe05119fb072663a8042)
* device: fix restricting Generic connection by interface-nameThomas Haller2017-04-261-9/+17
| | | | | | | | | | | | | | | | | NMDeviceGeneric:check_connection_compatible() doesn't check for a matching interface name. It relies on the parent implementation to do that. The parent implementation calls nm_manager_get_connection_iface(). That fails for NM_SETTING_GENERIC_SETTING_NAME, because that one has no factory. Maybe this imbalance of having no factory for the Generic device is wrong, but usually factories only match a distinct set of device types, while the generic factory would handle them all (as last resort). Without this, activating a generic connection might activate the wrong interface. (cherry picked from commit 3876b10a4749638c3dcfa7e65b12bfee8030334c)
* ifcfg-rh/tests: compare the written files to a expected resultThomas Haller2017-04-2627-28/+601
| | | | | | | | | | | | | | | | | | | | | | We have unit tests for writing and re-reading ifcfg file. Those tests compare whether a file can be successfully read and is semantically identical. However, there were no tests that a certain output is written in a stable format. We aim not to change the output of what we write. For that, add tests to not only check the semantic of the written ifcfg file, but their bits and bytes. Some future changes may well intentionally change the current output. That will require to update the expected result files and can be done via NMTST_IFCFG_RH_UPDATE_EXPECTED=yes src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh Note that alias, route, and key files are not checked. Related: https://bugzilla.redhat.com/show_bug.cgi?id=1445414 (cherry picked from commit f04bf45e84bddb7d685b03b9b36088848a46e75d)
* ifcfg-rh/tests: remove unused macro _writer_update_connection_FIXME()Thomas Haller2017-04-261-13/+0
| | | | | Fixes: 670e088efec40ca5cc3432e347c5226c9fa7cffc (cherry picked from commit e1e5d0d867c1fd0ef686b278e6ae636851713048)
* proxy: merge branch 'th/proxy-rh1444374'Thomas Haller2017-04-234-115/+168
|\ | | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1444374 (cherry picked from commit b495d0bf94e5cc043636064abf8a6053ff965af2)
| * proxy: send proxy config after creating D-Bus proxyThomas Haller2017-04-231-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | As NMDevice now creates the NMPacrunnerManager instance as needed, it is even more likely that the initial call to nm_pacrunner_manager_send() will only queue (but not yet send) the new config. Later, when the D-Bus proxy is created, we will not get a name-owner changed signal. We instead have to push the configuration right away. (cherry picked from commit 019b9fbfc0aa2123d1e0a742c0b3d01caaa7d874)
| * proxy: unify logging in nm-pacrunner-managerThomas Haller2017-04-231-11/+25
| | | | | | | | | | | | | | Give logging lines that are concerned with a certain "config" the same prefix: their call-id. (cherry picked from commit 8c81a4b58b17283596b0dcb45825890dd6722ac9)
| * proxy: introduce call-id for clearing pacmanager configurationThomas Haller2017-04-234-104/+137
|/ | | | | | | | | | | | | | | | | | | | nm_pacrunner_manager_remove() required a "tag" argument. It was a bug for callers trying to remove a configuration for a non-existing tag. That effectively means, the caller must keep track of whether a certain "tag" is pending. The caller also must remember the tag -- a tag that he must choose uniquely in the first place. Turn that around and have nm_pacrunner_manager_send() return a (non NULL) call-id. This call-id may later be used to remove the configuration. Apparently, previously the tracking of the "tag" was not always correct and we hit the assertion in nm_pacrunner_manager_remove(). https://bugzilla.redhat.com/show_bug.cgi?id=1444374 (cherry picked from commit b04a9c90eb0a866f2d730cc4777b4f670220ddc7)
* firewall: merge branch 'th/firewall-dbus-policy-rh1436770'Thomas Haller2017-04-212-17/+21
|\ | | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1436770 (cherry picked from commit 7d1f725743146a1ff8740bba5f4503a5ddd23a3d)
| * dbus: allow firewalld to communicate with NetworkManagerThomas Haller2017-04-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Usually, this "<allow send_destination="..."/>" part is shipped by firewalld's D-Bus policy. However, if firewalld is initially not installed with NetworkManager already running, dbus-daemon seems to cache the missing permission for the D-Bus connection. As a result, when installing and starting firewalld, NetworkManager requests fail until restart: firewall: [0x7f4b83643890,change:"eth1"]: complete: request failed (Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -")) https://bugzilla.redhat.com/show_bug.cgi?id=1436770 (cherry picked from commit cc1d409ba886e8e7c33f845790cfc700fcd2d854)
| * org.freedesktop.NetworkManager.conf: don't use tabsThomas Haller2017-04-211-14/+14
| | | | | | | | (cherry picked from commit 8583e62276a23a7ea858edf6c71d122e22f41955)
| * firewall: fix supressing errors from D-Bus callsThomas Haller2017-04-211-3/+5
|/ | | | | | | | | | | | | | | | | We want to ignore certain errors from firewalld. In the past, the error message contained only the error code. Since recently ([1], [2]), the error message contains a longer text: NetworkManager[647]: <debug> [1492768494.7475] device[0x7f7f21e78f50] (eth0): Activation: setting firewall zone 'default' NetworkManager[647]: <debug> [1492768494.7475] firewall: [0x7f7f21ed8900,change:"eth0"]: firewall zone change eth0:default ... firewalld[2342]: ERROR: UNKNOWN_INTERFACE: 'eth0' is not in any zone NetworkManager[647]: <warn> [1492768494.7832] firewall: [0x7f7f0400c780,remove:"eth0"]: complete: request failed (UNKNOWN_INTERFACE: 'eth0' is not in any zone) [1] https://github.com/t-woerner/firewalld/commit/c77156d7f688a0be3f0a1b4869b1c659e9e18cd6 [2] https://github.com/t-woerner/firewalld/commit/7c6ab456c5c461ac40cd7bb979a5daec6a13e6e4 (cherry picked from commit 2ad8bb0ce377624eefafe3b626d3fe691a7b9b7c)
* firewall: merge branch 'th/firewall-async'Thomas Haller2017-04-213-130/+207
|\ | | | | | | (cherry picked from commit ec3a9c0607de22f19015f4335fbabef2e02e135a)
| * firewall: queue operations while NMFirewallManager instance is initializingThomas Haller2017-04-212-27/+80
| | | | | | | | | | | | | | | | | | | | | | | | We now initialize the NMFirewallManager asynchronously. That means, at first firewalld appears as "not running", for which we usually would fake-success right away. It would be complex for callers to wait for firewall-manager to be ready. So instead, have the asynchronous requests be queued and complete them once the D-Bus proxy is initialized. (cherry picked from commit fb7815df6e691c6e22769a4703204c010836fca9)
| * firewall: drop _cb_info_is_idle()Thomas Haller2017-04-211-15/+12
| | | | | | | | | | | | | | | | Next we will get another mode, so an is-idle doesn't cut it. It can be confusing where the mode is set and where it is only accessed read-only. For that, add mode_mutable. (cherry picked from commit 04f4e327a9be606de5de009e0b5e1cc88abb8d6a)
| * firewall: factor out D-Bus call from _start_request()Thomas Haller2017-04-211-26/+46
| | | | | | | | | | | | Will be used in the next commit. (cherry picked from commit d8bf05d3e695f043eeb0fac4646fc6babad1bee3)
| * firewall: merge "started" signal and "available" propertyThomas Haller2017-04-213-62/+33
| | | | | | | | | | | | | | The GObject property NM_FIREWALL_MANAGER_AVAILABLE is basically unused. Drop it. (cherry picked from commit db576b848ab029b9a232fe9fda2f816660c6a9b8)
| * firewall: create firewall D-Bus proxy asynchronouslyThomas Haller2017-04-211-26/+62
|/ | | | | | | | | | | | | | Creating it asynchronously changes that on the first call to nm_firewall_manager_get() the instance is not yet running. Note that NMPolicy already connects to the "STARTED" signal and reapplies the zones when firewalld appears. So, this delayed change of the running state is handled mostly fine already. One part is still missing, it's to queue add_or_change/remove calls while the firewall manager is initializing. That follows next. (cherry picked from commit 753f39fa826405d4f50793647899059303b0f0cf)
* release: bump version to 1.7.91 (1.8-rc2)1.8-rc3Lubomir Rintel2017-04-201-1/+1
|
* release: update NEWSLubomir Rintel2017-04-201-1/+1
|
* nmcli: fix access to memeber nmc->show_secretFrancesco Giudici2017-04-201-1/+1
| | | | | | | | Cherry-picked commit from master which used the new nmc->nmc_config member not available in nm-1-8. We should use the nmc->show_secret member here. Fixes: d4c8a3fbf2bf7a2b67b606cc38562ea6a6d42a0c
* device: merge branch 'th/device-assume-guess-rh1443878'Thomas Haller2017-04-207-50/+111
|\ | | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1443878 (cherry picked from commit c828277872997dc0a90f30ff5a70705eec0979c3)
| * device: assume matching connections during first startThomas Haller2017-04-201-24/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
| * config: add first_start paramter to NMConfig to detect restartThomas Haller2017-04-205-5/+35
| | | | | | | | (cherry picked from commit 2131954a190244714e8b27b48567594c7b103fb9)
| * config: remove unused NMConfig self argument from nm_config_device_state_*() APIThomas Haller2017-04-204-21/+10
|/ | | | | | | | | | | nm_config_device_state_*() always access the file system directly, they don't cache data in NMConfig. Hence, they don't use the @self argument. Maybe those functions don't belong to nm-config.h, anyway. For lack of a better place they are there. (cherry picked from commit 1940be410cc0272de2f690542f43ef7dcb7bc4e1)
* nmcli: show secrets when the --show-secrets option is put after the ↵Francesco Giudici2017-04-201-0/+17
| | | | | | | | | | | | | | | connection id 'nmcli connection show <con_id1> --show-secrets' secrets were not shown. 'nmcli connection show <con_id1> --show-secrets <con_id2>' secrets were shown only for connection ids following the "--show-secrets" option (so only for 'con_id2'). Fix these behaviors showing secrets for all connections also if the "--show-secrets" option is put after the connection ids. (cherry picked from commit 4bdb6b026a808ab718258e17d20d0472f3fcdd76)
* po: update Polish (pl) translation (bgo #780277)Piotr Drąg2017-04-191-32/+12
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=780277
* po: make update-poThomas Haller2017-04-191-2234/+2554
|
* po: update Polish (pl) translation (bgo #780277)Piotr Drąg2017-04-191-2617/+2293
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=780277
* po: import Zanata translationsThomas Haller2017-04-1953-1049/+159
|
* po: make update-poThomas Haller2017-04-1966-58114/+61702
|
* po: fix project-version for nm-1-8 branch in zanata.xmlThomas Haller2017-04-191-1/+1
|
* gitignore: ignore generated files from master branchThomas Haller2017-04-191-0/+5
|
* gitignore: ignore .zanata-cache directoryThomas Haller2017-04-191-0/+1
| | | | (cherry picked from commit b4b8e8115341a2fad9d02c22d414bb6090f2866f)
* merge: branch 'bg/sriov-numvfs-rh1398934'Beniamino Galvani2017-04-1910-14/+202
|\ | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1398934 (cherry picked from commit 45e4cc67b33914bb960ceae78ae540739c411651)
| * device: re-apply sriov_numvfs after SIGHUPBeniamino Galvani2017-04-191-11/+14
| | | | | | | | (cherry picked from commit 264624f91dce43859205faa20303ec2d9cddaa64)
| * core: allow setting SR-IOV num_vfsBeniamino Galvani2017-04-194-0/+36
| | | | | | | | (cherry picked from commit 32975b6aa5b48118ec65a3790e763a530a4ad913)
View Lorry Controller Status