summaryrefslogtreecommitdiff
path: root/man
AgeCommit message (Collapse)AuthorFilesLines
2017-09-11device: enable support for ipv6.dhcp-timeoutThomas Haller1-0/+5
- cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-05man: fix evaluation of unsupported ifcfg-rh settingsBeniamino Galvani1-1/+1
The 'contains' function has no notion of separators, so 'vlan' can match 'macvlan' in the unspported list. Add separator to avoid matching substrings.
2017-09-05man: add unsupported ifcfg-rh settingsBeniamino Galvani1-1/+1
Add macsec and dummy setting to the unsupported list. While at it, also sort entries.
2017-09-05man: remove unused xsl variableBeniamino Galvani1-1/+0
2017-08-30man: nmcli: grammar fixBeniamino Galvani1-3/+3
s/It's equivalent of/It's equivalent to/
2017-06-22device: handle carrier changes for master device differentlyNikolay Martynov1-1/+8
For master devices, instead of ignoring loss of carrier entirely, handle it. First of all, master devices are now by default ignore-carrier=yes. That means, without explict user configuration in NetworkManager.conf, the previous behavior in carrier_changed() does not change. If the user decides to configure the master device like [device-with-carrier] match-device=type:bond,type:bridge,type:team ignore-carrier=no then, master device will disconnect on carrier loss like regular devices. https://github.com/NetworkManager/NetworkManager/pull/18 Co-authored-by: Thomas Haller <thaller@redhat.com>
2017-06-13device: don't set MTU of device unless explicitly configuredThomas Haller1-1/+1
Since commit 2b51d3967 "device: merge branch 'th/device-mtu-bgo777251'", we always set the MTU for certain device types during activation. Even if the MTU is neither specified via the connection nor other means, like DHCP. Revert that change. On activation, if nothing explicitly configures the MTU, leave it unchanged. This is like what we do with ethernet's cloned-mac-address, which has a default value "preserve". So, as last resort the default value for MTU is now 0 (don't change), instead of depending on the device type. Note that you also can override the default value in global configuration via NetworkManager.conf. This behavior makes sense, because whenever NM actively resets the MTU, it remembers the previous value and restores it when deactivating the connection. That wasn't implemented before 2b51d3967, and the MTU would depend on which connection was previously active. That is no longer an issue as the MTU gets reset when deactivating. https://bugzilla.redhat.com/show_bug.cgi?id=1460760
2017-05-31clients: add support for Bluetooth NAP typeLubomir Rintel1-4/+4
2017-05-24core: add configuration flag to choose slaves activation orderBeniamino Galvani1-0/+13
Commits 39d0559d9a7a ("platform: sort links by name instead of ifindex") and 529a0a1a7f19 ("manager: sort slaves to be autoconnected by device name") changed the order of activation of slaves. Introduce a system-wide configuration property to preserve the old behavior. https://bugzilla.redhat.com/show_bug.cgi?id=1452585
2017-04-28supplicant: configure PMF for each connectionBeniamino Galvani1-0/+5
Now that we have a PMF connection property, get rid of the previous code to globally enable/disable PMF and use the 'ieee80211w' configuration option for each configured network when the supplicant supports it.
2017-04-18core: allow setting SR-IOV num_vfsBeniamino Galvani1-0/+10
2017-03-28nmcli: add -g[et-values] option as a '-m tab -t -f <arg>' shortcutFrancesco Giudici2-4/+43
Quick and easy way to get clean and parsable field values.
2017-03-24man: add description for the 'hostname' config option in the main sectionFrancesco Giudici1-0/+28
2017-03-24man: fix default location for keyfile.path in documentationThomas Haller1-1/+1
Fixes: 530af7009ecca099372fd50a9b2b130c875a6524 Fixes: 90683fcb3a4a60d2902ebb7e4a47419d76acb1d8
2017-03-17device: add spec "driver:" to match devicesThomas Haller1-0/+7
Changing the MAC address of devices is known to fail with certain drivers. Add a device-spec to allow disabling it for for such devices. Related: https://bugzilla.gnome.org/show_bug.cgi?id=777523
2017-03-17man: include the description for settingsLubomir Rintel1-15/+18
2017-02-22cli: support dummy connectionsBeniamino Galvani1-0/+1
2017-02-15build: use `sed` instead of AC_SUBST() to generate man/common.entThomas Haller1-1/+1
Otherwise, substitions are not properly expanded. For example - "AC_SUBST(nmrundir, '${runstatedir}'/$PACKAGE, [NetworkManager runtime state directory])" gives ${runstatedir}/NetworkManager/resolv.conf - "AC_SUBST(nmrundir, "${runstatedir}/$PACKAGE", [NetworkManager runtime state directory])" gives ${prefix}/var/run/NetworkManager/resolv.conf
2017-02-14dns: change behavior for "rc-manager=symlink" to preserve "/etc/resolv.conf" ↵Thomas Haller2-9/+12
as file The purpose of "rc-manager=symlink" is so that the administrator can point the "/etc/resolv.conf" as a symlink to a certain file, and thus indicating that a certain component is responsible to manage resolv.conf, while others should stay away from it. For example, systemd-resolved never touches "/etc/resolv.conf", but expects the admin to setup the symlink appropriately. It also recognizes whether the symlink points to it's own resolv.conf in /run or to another component. Previously, "rc-manager=symlink" would always replace a regular file with a symlink to "/var/run/NetworkManager/resolv.conf". Only if "/etc/resolv.conf" is already a symlink somewhere else, NM would not touch it. This with the exception that if "/etc/resolv.conf" points to "/var/run/NetworkManager/resolv.conf", it would replace the symlink with the same link to raise inotify events. Change behavior so if "/etc/resolv.conf" is already a regular file, keep it as file. This means, if you have multiple components that don't care, everybody can write the "/etc/resolv.conf" (as file) and there is no clear expressed responsibility. It was wrong that NetworkManager would convert the file to a symlink, this should be reserved to the admin. Instead, NetworkManager should accept that the intent is unspecified and preserve the regular file. It's up to the admin to replace the symlink to somewhere else (to keep NM off), or to point it to "/var/run/NetworkManager/resolv.conf", to show the explicit intent. The wrong behavior causes dangling symlinks when somebody disables NetworkManager for good. https://bugzilla.redhat.com/show_bug.cgi?id=1367551
2017-01-17device: make the MTU globally configurable via connection-defaultsThomas Haller1-0/+16
This allows a user to restore the previous behavior where NetworkManager would not reconfigure the MTU during device activation, if no MTU is available (commit "22e8af6 device: set a per-device default MTU on activation"). Well, not exactly. The previous behavior was to use per-connection configuration, then DHCP provided value, or finally leave the MTU unspecified. Now, we prefer a per-connection configuration, followed by a global connection default. If "ethernet.mtu=0", the MTU is left unspecified. In absense of a global connection default, the value from DHCP is used or finally a per-device-type default. That is effectively 1500 for most types, except for infiniband where the MTU is still left unspecified.
2017-01-09man: minor fix to nmcli.xmlFrancesco Giudici1-1/+1
2017-01-09device: support dynamic "connection.stable-id" in form of text-substitutionThomas Haller1-0/+3
Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-15man: replace libnm-util reference with libnm-core in nm-settings pageJiří Klimeš1-3/+3
2016-12-15man: add unsupported settings to the list in nm-settings-ifcfg-rh pageJiří Klimeš1-1/+1
2016-11-25config/trivial: unify name of compile time config defaultsThomas Haller2-8/+8
2016-11-14man: clarify dns=default setting in NetworkManager.conf manualThomas Haller1-7/+11
https://bugzilla.gnome.org/show_bug.cgi?id=774399
2016-11-11man: use <filename> to mark file namesLubomir Rintel2-19/+24
This gives the templates a chance to do something extra clever with the formatting. The templates, of course, choose not to :(
2016-11-11man: link to some online resourcesLubomir Rintel1-0/+9
2016-11-11man: get rid of the extra capitalization in docbook sourceLubomir Rintel1-2/+2
The temaplates capitalize the names if they wish.
2016-11-03man: use /run instead of /var/runLubomir Rintel1-5/+5
/var/run is just a compatibility symlink, according to file-hierarchy(7).
2016-11-02man: clarify behavior of "ip4"/"ip6" alias to nmcliThomas Haller1-7/+8
2016-10-27dhcp: make default dhcp plugin configurable at compile-timeThomas Haller2-3/+4
2016-10-23man: document /var/run/NetworkManager/conf.d directoryThomas Haller1-3/+7
2016-10-21build: merge "man/Makefile.am" into toplevel MakefileThomas Haller1-126/+0
2016-10-16core: handle the autoconnect-retries propertyBeniamino Galvani1-0/+15
2016-10-04cli: support qualifying proxy.pac-script with "file://" or "js://"Thomas Haller1-0/+13
2016-09-27cli: support explicitly selecting team-config as file or json dataThomas Haller1-6/+10
nmcli has a heuristic when setting the team-config to accepting both a filename or the plain json text. Add support for two schemes "file://" and "json://" to explicitly determine whether to read from file or from json. Also, no longer silently ignore an all-whitespace word. That is an error (unless you have a file named " "). Also, no longer replace newlines with space. Don't mangle the input text at all.
2016-09-20man: NetworkManager.conf: better document dns=dnsmasqBeniamino Galvani1-1/+9
It's potentially unexpected by user that dnsmasq works differently from the libc resolver and doesn't try the servers in order. Add a paragraph to explain that and how to tweak the resolution order.
2016-09-12device: change default value for cloned-mac-address to "preserve" (bgo#770611)Thomas Haller1-2/+2
Long ago before commit 1b49f94, NetworkManager did not touch the MAC address at all. Since 0.8.2 NetworkManager would modify the MAC address, and eventually it would reset the permanent MAC address of the device. This prevents a user from externally setting the MAC address via tools like macchanger and rely on NetworkManager not to reset it to the permanent MAC address. This is considered a security regression in bgo#708820. This only changed with commit 9a354cd and 1.4.0. Since then it is possible to configure "cloned-mac-address=preserve", which instead uses the "initial" MAC address when the device activates. That also changed that the "initial" MAC address is the address which was externally configured on the device as last. In other words, the "initial" MAC address is picked up from external changes, unless it was NetworkManager itself who configured the address when activating a connection. However, in absence of an explicit configuration the default for "cloned-mac-address" is still "permanent". Meaning, the user has to explicitly configure that NetworkManager should not touch the MAC address. It makes sense to change the upstream default to "preserve". Although this is a change in behavior since 0.8.2, it seems a better default. This change has the drastic effect that all the existing connections out there with "cloned-mac-address=$(nil)" change behavior after upgrade. I think most users won't notice, because their devices have the permanent address set by default anyway. I would think that there are few users who intentionally configured "cloned-mac-address=" to have NetworkManager restore the permanent address. https://bugzilla.gnome.org/show_bug.cgi?id=770611
2016-09-08man: document dns=systemd-resolvedBeniamino Galvani1-3/+7
2016-09-02man: fix wording in NetworkManager.conf for "rc-manager"Thomas Haller1-3/+3
2016-09-02doc: add comment to systemd's NetworkManager.service about ibft requiring ↵Thomas Haller1-0/+3
CAP_SYS_ADMIN We don't want to enable this upstream, but make the requirement more discoverable by documenting it and put a comment to NetworkManager.service. https://bugzilla.redhat.com/show_bug.cgi?id=1371201
2016-08-26man: NetworkManager.conf: fix link syntaxBeniamino Galvani1-1/+1
Fixes: c7cee12189d8fe64bc9037d5b9daaf1c887e0466
2016-08-26man: fix reference in NetworkManager.confThomas Haller1-1/+1
Without this, it reads: See the section called “Sections” for details. but there are multiple sections called “Sections” and it should explicitly refer to the one from the other top-level section. With this change, it reads: See “Sections” under the section called “CONNECTION SECTION” for details.
2016-08-01man: document completionLubomir Rintel1-0/+17
2016-08-01cli: add ability to indicate command completion expects a file nameLubomir Rintel1-0/+7
2016-07-28man: Added documentation for the connectivity-change dispatcher hookMario Sanchez Prada1-1/+17
Also added documentation for the new CONNECTIVITY_STATE environment variable, that will also be avaiblable in those hooks. https://bugzilla.gnome.org/show_bug.cgi?id=768969
2016-07-19man: additional fixes for nmcli commands syntax in nmcli.xmlJiří Klimeš1-9/+9
2016-07-15man: fix 'domain' to 'domains' for nmcli general loggingJiří Klimeš1-1/+1
2016-07-15man: fix 'nmcli connection edit' description in nmcli.xmlJiří Klimeš1-2/+2
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-25 01:21:09 +0000