summaryrefslogtreecommitdiff
path: root/Makefile.am
Commit message (Collapse)AuthorAgeFilesLines
...
* | device: add support for OpenVSwitch devicesLubomir Rintel2017-10-301-0/+57
| |
* | libnm: add support for ovs-bridge devicesLubomir Rintel2017-10-301-0/+2
| |
* | libnm: add support for ovs-port devicesLubomir Rintel2017-10-301-0/+2
| |
* | libnm: add support for ovs-interface devicesLubomir Rintel2017-10-301-0/+2
| |
* | introspection: add o.fd.NM.Device.OvsBridge interfaceLubomir Rintel2017-10-301-0/+4
| |
* | introspection: add o.fd.NM.Device.OvsPort interfaceLubomir Rintel2017-10-301-0/+4
| |
* | introspection: add o.fd.NM.Device.OvsInterface interfaceLubomir Rintel2017-10-301-0/+4
| |
* | libnm-core: add ovs-bridge settingLubomir Rintel2017-10-301-0/+2
| |
* | libnm-core: add ovs-port settingLubomir Rintel2017-10-301-0/+2
| |
* | libnm-core: add ovs-interface settingLubomir Rintel2017-10-301-0/+2
| |
* | libnm-core: add ovs-patch settingLubomir Rintel2017-10-301-0/+2
| |
* | dhcp: add support for dhcpcanon clientjuga02017-10-301-0/+2
| | | | | | | | https://github.com/NetworkManager/NetworkManager/pull/31
* | build: create clients/common/ when building libnmc_base libraryBeniamino Galvani2017-10-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the following build error where gcc fails because the client/common does not exist yet: CC shared/nm-utils/clients_common_libnmc_base_la-nm-enum-utils.lo cc1: error: ./clients/common: No such file or directory [-Werror] cc1: all warnings being treated as errors make[4]: *** [shared/nm-utils/clients_common_libnmc_base_la-nm-enum-utils.lo] Error 1 # libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../shared -I./shared -I../libnm-core -I./libnm-core -I../libnm -I./libnm -I../clients/common -I./clients/common ... -c ../shared/nm-utils/nm-enum-utils.c -fPIC -DPIC -o shared/nm-utils/.libs/clients_common_libnmc_base_la-nm-enum-utils.o cc1: error: ./clients/common: No such file or directory [-Werror] Fixes: 3434261811b6edde77689983ac4c4e70cd2ca39a
* | all: use siphash24 for hashingThomas Haller2017-10-181-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | siphash24() is wildly used by projects nowadays. It's certainly slower then our djb hashing that we used before. But quite likely it's fast enough for us, given how wildly it is used. I think it would be hard to profile NetworkManager to show that the performance of hash tables is the issue, be it with djb or siphash24. Certainly with siphash24() it's much harder to exploit the hashing algorithm to cause worst case hash operations (provided that the seed is kept private). Does this better resistance against a denial of service matter for us? Probably not, but let's better be safe then sorry. Note that systemd's implementation uses a different seed for each hash table (at least, after the hash table grows to a certain size). We don't do that and use only one global seed.
* | core,clients: use our own string hashing function nm_str_hash()Thomas Haller2017-10-181-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace the usage of g_str_hash() with our own nm_str_hash(). GLib's g_str_hash() uses djb2 hashing function, just like we do at the moment. The only difference is, that we use a diffrent seed value. Note, that we initialize the hash seed with random data (by calling getrandom() or reading /dev/urandom). That is a change compared to before. This change of the hashing function and accessing the random pool might be undesired for libnm/libnm-core. Hence, the change is not done there as it possibly changes behavior for public API. Maybe we should do that later though. At this point, there isn't much of a change. This patch becomes interesting, if we decide to use a different hashing algorithm.
* | shared: split random and hash utilsThomas Haller2017-10-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | "nm-utils/nm-shared-utils.h" shall contain utility function without other dependencies. It is intended to be used by other projects as-is. nm_utils_random_bytes() requires getrandom() and a HAVE_GETRANDOM configure check. That makes it more cumbersome to re-use "nm-shared-utils.h", in cases where you don't care about nm_utils_random_bytes(). Split nm_utils_random_bytes() out to a separate file. Same for hash utils, which depend on nm_utils_random_bytes(). Also, hash utils will eventually be extended to use siphash24.
* | build: move nm-client-utils.c to libnmc-base.aBeniamino Galvani2017-10-161-3/+3
| | | | | | | | | | | | | | | | | | In a later commit we'll add a new generic client function used by nmcli and nmtui. nm-client-utils.c seems the right place for it, so move the file to the base library that is used by both clients. While at it, also put in that file some functions that will be needed by nmtui.
* | build: cleanup style for toplevel Makefile.amThomas Haller2017-09-251-7/+7
| | | | | | | | | | | | | | | | Use consistently $() instead of ${}. Don't use the $(top_*) variables, because we don't do recursive make and the toplevel directory is the same as the current directory. For consistency, only use the non-toplevel versions of the variables.
* | build: add missing header file to MakefileBeniamino Galvani2017-09-221-0/+1
| | | | | | | | Fixes: 734c5b38ad57dbfefd67fdd73fd1e45b77483f48
* | core: rework handling of default-routes and drop NMDefaultRouteManagerth/platform-route-pt4Thomas Haller2017-09-081-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
* | tui: link nm-utils/nm-shared-utils.c into nmtuiThomas Haller2017-09-051-0/+2
| |
* | platform: add non-exclusive routes and drop route-managerThomas Haller2017-08-241-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
* | build: fix building src/systemdFrancesco Giudici2017-08-111-1/+3
| | | | | | | | | | | | | | | | While rebasing systemd from upstream the "sd-adapt/process-util.h" file was renamed and few other header files were added in the sources. Update Makefile.am. Fixes: e0cdaf9880929a40f60c1327cf67f800feefc951
* | systemd: merge branch systemd into masterBeniamino Galvani2017-08-101-0/+2
|\ \ | |/ | | | | | | | | - fix DHCP over Infiniband https://bugzilla.redhat.com/show_bug.cgi?id=1477678
* | device: add NMDevicePPPBeniamino Galvani2017-08-051-0/+8
| | | | | | | | | | | | The new device type represents a PPP interface, and will implement the activation of new-style PPPoE connections, i.e. the ones that don't claim the parent device.
* | c-list: add c_list_sort()Thomas Haller2017-07-251-0/+4
| | | | | | | | | | | | | | | | | | | | Add a stable, recursive merge sort for CList. This could be improved by doing an iterative implementation. The recursive implementation's stack depth is not an issue, as it is bound by O(ln(n)). But an iterative implementation would safe the overhead of O(n*log(n)) function calls and be potentially faster.
* | service: don't install dependency for "NetworkManager-wait-online.service" ↵Thomas Haller2017-07-171-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to "network-online.target.wants" If we install "NetworkManager-wait-online.service" in the "network-online.target.wants" directory, network-online.target always pulls in NetworkManager-wait-online.service. As it was, it could only be disabled by masking the service. Instead, we should enable NetworkManager-wait-online.sevice via systemd's preset. That is already done for Fedora 26 and newer. Note that NetworkManager-wait-online.sevice already has Install.WantedBy. This way, the dependency is created automatically when enabling the service. https://bugzilla.redhat.com/show_bug.cgi?id=1455704
* | platform: move the NMPCache from linux platform to NMPlatformThomas Haller2017-07-051-0/+1
| | | | | | | | | | | | | | | | We want to expose the NMPLookup and NMDedupMultiHeadEntry to the users of NMPlatform, so that they can iterate the cache directly. That means, NMPCache becames an integral part of NMPlatform's API and must also be implemented by NMFakePlatform.
* | core: remove NMMultiIndexThomas Haller2017-07-051-2/+0
| | | | | | | | It's unused now.
* | shared: add NMDedupMultiIndex "nm-dedup-multi.h"Thomas Haller2017-07-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the NMDedupMultiIndex cache. It basically tracks objects as doubly linked list. With the addition that each object and the list head is indexed by a hash table. Also, it supports tracking multiple distinct lists, all indexed by the idx-type instance. It also deduplicates the tracked objects and shares them. - the objects that can be put into the cache must be immutable and ref-counted. That is, the cache will deduplicate them and share the reference. Also, as these objects are immutable and ref-counted, it is safe that users outside the cache own them too (as long as they keep them immutable and manage their reference properly). The deduplication uses obj_id_hash_func() and obj_id_equal_func(). These functions must cover *every* aspect of the objects when comparing equality. For example nm_platform_ip4_route_cmp() would be a function that qualifies as obj_id_equal_func(). The cache creates references to the objects as needed and gives them back. This happens via obj_get_ref() and obj_put_ref(). Note that obj_get_ref() is free to create a new object, for example to convert a stack-allocated object to a (ref-counted) heap allocated one. The deduplication process creates NMDedupIndexBox instances which are the ref-counted entity. In principle, the objects themself don't need to be ref-counted as that is handled by the boxing instance. - The cache doesn't only do deduplication. It is a multi-index, meaning, callers add objects using a index handle NMDedupMultiIdxType. The NMDedupMultiIdxType instance is the access handle to lookup the list and objects inside the cache. Note that the idx-type instance may partition the objects in distinct lists. For all operations there are cross-references and hash table lookups. Hence, every operation of this data structure is O(1) and the memory overhead for an index tracking an object is constant. The cache preserves ordering (due to linked list) and exposes the list as public API. This allows users to iterate the list without any additional copying of elements.
* | all: add base object type in "nm-obj.h"Thomas Haller2017-07-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Platform has it's own, simple implementation of object types: NMPObject. Extract a base type and move it to "shared/nm-utils/nm-obj.h" so it can be reused. The base type is trival, but it allows us to implement other objects which are compatible with NMPObjects. Currently there is no API for generic NMObjBaseInst type, so compatible in this case only means, that they can be used in the same context (see example below). The only thing that you can do with a NMObjBaseInst is check it's NMObjBaseClass. Incidentally, NMObjBaseInst is also made compatible to GTypeInstance. It means, an NMObjBaseInst is not necessarily a valid GTypeInstance (like NMPObject is not), but it could be implemented as such. For example, you could do: if (NMP_CLASS_IS_VALID ((NMPClass *) obj->klass)) { /* is an NMPObject */ } else if (G_TYPE_CHECK_INSTANCE_TYPE (obj, NM_TYPE_SOMETHING)) { /* it a NMSometing GType */ } else { /* something else? */ } The reason why NMPObject is not implemented as proper GTypeInstance is because it would require us to register a GType (like g_type_register_fundamental). However, then the NMPClass struct can no longer be const and immutable memory. But we could. NMObjBaseInst may or may not be a GTypeInstance. In a sense, it's a base type of GTypeInstance and all our objects should be based on it (optionally, they we may make them valid GTypes too).
* | build: fix race creating "libnm-core/tests" directory for ↵Thomas Haller2017-06-141-0/+3
| | | | | | | | | | | | "nm-core-tests-enum-types.c" https://bugzilla.gnome.org/show_bug.cgi?id=783783
* | build: fix nm binutils tool when building with LTOThomas Haller2017-06-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building with -flto, we need to use linker plugins. In case of binutils' nm, it means to prefer gcc-nm if available. Like for ranlib and ar, prefer gcc-nm. - replace AC_PATH_TOOL() by AC_CHECK_TOOLS(). That is consistent with what we do for ar,ranlib and suggested on bgo#783311. - instead of using the variable $BINUTILS_NM, replace it by $NM, which is more common according to bgo#783311. - Keep recognizing $BINUTILS_NM environment, which was introduced by commit 8bc88bcc7c. This is purely to keep previous build scripts working. Originally I named it "$BINUTILS_NM" because using $NM in NetworkManager seemed confusing. But well... https://bugs.gentoo.org/show_bug.cgi?id=620052 https://bugzilla.gnome.org/show_bug.cgi?id=782525 https://bugzilla.gnome.org/show_bug.cgi?id=783311
* | build: add a missing test artifact to distLubomir Rintel2017-06-011-0/+1
| | | | | | | | Fixes: ba05819c89d913ad1bc6b86e62c7704d173ef534
* | build: don't drop the test suite log on failureLubomir Rintel2017-05-311-0/+1
| | | | | | | | Fixes: 2198f73b0ec810b6b9084c0e00dcf07d4a6ee8e3
* | ifcfg-rh/tests: add test for reading NETMASK propertyThomas Haller2017-05-301-0/+1
| |
* | build: sort filenames in Makefile.am alphabeticallyThomas Haller2017-05-301-150/+151
| |
* | build: don't link static libraries multiple timesThomas Haller2017-05-191-2/+0
| | | | | | | | | | | | | | | | libnm-core.a should only be linked once in libnm.so. Previously, it was linked twice, once as part of libnm-utils.a and once directly in libnm.so. Fixes: 8df944c7e495d18bfecaf9d8316ef7783039c94b
* | build: don't install intermediate library libnm/libnm-utils.laThomas Haller2017-05-191-1/+1
| | | | | | | | Fixes: 8df944c7e495d18bfecaf9d8316ef7783039c94b
* | libnm: add testable libnm/nm-libnm-utils.c fileThomas Haller2017-05-191-7/+38
| | | | | | | | | | | | | | Previously, internal parts of libnm were not testable. Instead, add "libnm/nm-libnm-utils.c" and "libnm/libnm-utils.la" to contain code that can be statically linked with a new test "libnm/tests/test-general".
* | hostname: split out hostname management from NMSettingsThomas Haller2017-05-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
* | shared: add "nm-utils/c-list.h" headerThomas Haller2017-05-111-0/+1
| | | | | | | | | | | | | | Include the circular, doubly-linked list implementation from c-util/c-list [1], commit 864051de6e7e1c93c782064fbe3a86b4c17ac466. [1] https://github.com/c-util/c-list
* | ifcfg: add read/write support for user-dataThomas Haller2017-05-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The user data values are encoded in shell variables named prefix "NM_USER_". The variable name is an encoded form of the data key, consisting only of upper-case letters, digits, and underscore. The alternative would be something like NM_USER_1_KEY=my.keys.1 NM_USER_1_VAL='some value' NM_USER_2_KEY=my.other.KEY.42 NM_USER_2_VAL='other value' contary to NM_USER_MY__KEYS__1='some value' NM_USER_MY__OTHER___K_E_Y__42='other value' The advantage of the former, numbered scheme is that it may be easier to find the key of a user-data entry. With the current implementation, the shell script would have to decode the key, like the ifcfg-rh plugin does. However, user data keys are opaque identifers for values. Usually, you are not concerned with a certain name of the key, you already know it. Hence, you don't need to write a shell script to decode the key name, instead, you can use it directly: if [ -z ${NM_USER_MY__OTHER___K_E_Y__42+x} ]; then do_something_with_key "$NM_USER_MY__OTHER___K_E_Y__42" fi Otherwise, you'd first have to search write a shell script to search for the interesting key -- in this example "$NM_USER_2_KEY", before being able to access the value "$NM_USER_2_VAL".
* | ifcfg-rh/tests: compare the written files to a expected resultThomas Haller2017-04-261-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | core: add NMNetns to bundle platform and route managersThomas Haller2017-04-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together.
* | build: fix broken line wraps in Makefile.amThomas Haller2017-04-071-2/+2
| |
* | build: add missing build dependency for ifupdownThomas Haller2017-04-071-8/+13
| | | | | | | | | | | | | | And reorder _OBJECTS dependencies of settings plugins after their corresponding _LDADD declartion. https://mail.gnome.org/archives/networkmanager-list/2017-April/msg00016.html
* | build: commit pre-generated "settings-docs.c" in gitThomas Haller2017-04-051-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | nmcli has documentation strings embedded. Those strings are extracted from gtk-doc comments, using pygobject and put in the generated file "clients/common/settings-docs.c". This file "clients/common/settings-docs.c" is disted, so from a source tarball you can build nmcli without enabling introspection. However, when building from a git-tree, the file is missing and thus one cannot build --with-nmcli unless also using at least --enable-introspection to generate "clients/common/settings-docs.c". That is inconvenient. Especially during cross-compilation, where one also needs python and pygobject in the foreign architecture (because the generation of "settings-docs.c" loads the built libnm.so via pygobject). It is bad because nmcli is an essential part of NetworkManager, so building --without-nmcli is not a great option. Previously, the only alternative was to pre-generate a source tarball on a separate machine and build that. This however complicates efforts to automatically build git snapshots of NetworkManager. Fix that by commiting "clients/common/settings-docs.c.in" to git. When building with --disable-introspection, the pre-generated file is used instead. This is fine, because the file only depends on static, checked-in documentation strings that seldomly change. Also add a check target to notice when the pre-generated file differs from what we are about to generate during --enable-introspection. That happens when editing one of the gtk-doc entires. In this case, `make check` will notify that the pre-generated "settings-docs.c.in" file needs updating too. Yes, when changing gtk-doc comments you need to updte the file manually. At least, the check failure notifies you.
* | cli/tests: add "clients/common/tests/test-general.c"Thomas Haller2017-04-051-6/+27
| |
* | build: build intermediate library libnmc.la for nmcliThomas Haller2017-04-051-54/+86
| | | | | | | | | | | | | | Used for unit testing in the next commit. Also add libnmc-base.la, which contains common files for nmcli and nmtui.
View Lorry Controller Status