Commit bb850fda0e ('nmcli: connection: process port-type, type
and controller first') started correctly rejecting IP configuration
on port connections.
However, previously nmcli would accept IP parameters for ports when
using a specific parameters order. To avoid breaking user scripts that
may have relied on this behavior, introduce a backward compatibility
quirk.
Specifically, nmcli accepts a disabled/ignore IP method on a port
connection. For any other IP setting on a port connection, a specific
error message is now shown.
https://issues.redhat.com/browse/RHEL-90756https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2227
- ausearch is part of audit package
- mlocate is not available anymore
- "openvswitch2*" packages are not available anymore
- ipsec-tools is not available anymore
Currently, both man pages and gtk-doc HTML documentation are enabled by
the same build option. It is common for users to want to choose whether
to build HTML docs, as not everyone cares about HTML developer docs, but
manpages are intended directly for end-user consumption and should
always be available. At the very least, there should be a separate
option to disable them to avoid accidentally disabling them while trying
to disable HTML developer docs.
Resolves: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1653
It is a little odd that client tests connect "UNAVAILABLE" devices, and
the devices return to "DISCONNECTED" after deactivation.
It differs from what happens in reality, and some client tools
(hey nm-cloud-setup) can break when they rightly assume that the
device is not ready for activation when it's "UNAVAILABLE" not
"DISCONNECTED".
PyGObject 3.52 switched from gobject-introspection’s libgirepository 1.0
to glib’s libgirepository 2.0. As a result, the Python script would
no longer be able to find the `GIRepository` 2.0 typelib:
(process:1944): GLib-GIRepository-DEBUG: 15:25:14.521: Ignoring GIRepository-2.0.typelib because this libgirepository corresponds to GIRepository-3.0.typelib
We could update the script to support both versions of the typelib
but it is not really necessary. It was only used to add extra directories
from `$LD_LIBRARY_PATH` and the CLI argument to repository’s library path
but libgirepository already supports using `LD_LIBRARY_PATH` directly:
https://docs.gtk.org/girepository/method.Repository.prepend_library_path.html
This message is useless for non-interactive use and clobbers over
otherwise very appealing test output.
The callers knows what we're going to listen on, it passed us the file
descriptor.
In nmcli we have renamed dhcp-send-hostname and dhcp-send-hostname-v2 to
dhcp-send-hostname-deprecated and dhcp-send-hostname so users don't need
to worry about the details of the weird workarounds that we sometimes
need to do to expand and/or deprecate some properties.
However, the autogenerated documentation didn't include this names. Add
---nmcli--- specific documentation, adding a new property-infos field
called "rename" with the new name used in nmcli. This field can be used
for more properties if we use the same strategy in the future.
This patch add support to IPVLAN interface. IPVLAN is a driver for a
virtual network device that can be used in container environment to
access the host network. IPVLAN exposes a single MAC address to the
external network regardless the number of IPVLAN device created inside
the host network. This means that a user can have multiple IPVLAN
devices in multiple containers and the corresponding switch reads a
single MAC address. IPVLAN driver is useful when the local switch
imposes constraints on the total number of MAC addresses that it can
manage.
The setting was missing from the script. The patch is adding it and also
regenerates the docs.
Fixes: 5426bdf4a1 ('HSR: add support to HSR/PRP interface')
Script to create a RHCOS custom image containing a NetworkManager rpm from
a copr repository.
In order to have a custom RHCOS image, we cannot modify the image itself but
we can add a custom layered image that includes all RHCOS functionality and
adds additional functionality to it.
Requirements:
- A quay.io registry where you have push access.
- You must have your pull-secret in the same directory where the script is
being run. You can download your pull-secret from:
https://console.redhat.com/openshift/install/pull-secret
In order to install this on nodes from a cluster that already exists it must
be done using MachineConfig operator. In essence the following YAML file
must be created.
```
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: <role>
name: os-layer-custom-nm
spec:
osImageURL: <registry>
```
Please, notice that the role and registry need to be set to your needs.
Then, it can be applied by:
$ oc create -f <yaml file>
Finally, the machines will be ready once the field UPDATED has the True value
in the output of this command.
$ oc get mcp
Currently, the Dockerfile expects /etc/systemd/journald.conf to exist on the base container,
but sometimes this may not be the case, for example on Fedora 40, which causes
the build process to fail if the host machine is also running Fedora 40.
Update the dockerfile to create a conf.d file instead, which has higher precedence.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1972
The test "tarball+meson" fails on systems with old meson version with
the message "ERROR: Neither directory contains a build file
meson.build". This message is raised when calling `meson dist` from the
build directory.
According to meson documentation, `meson dist` is supported since 0.52,
and older vesions need to execute `ninja dist`.
https://mesonbuild.com/Creating-releases.html
Also, when using meson.add_dist_script, the env variable MESON_SOURCE_ROOT
is not passed in versions < 0.54. As we don't use it in the script,
don't assert for it.
We claim to support down to meson 0.47.3 (we need to raise it because we
are actually using a bit newer features, but that's another topic). Use
`ninja dist` that will work fine on old and new meson.
Fixes: 61f0531509 ('gitlab-ci: test re-buildability of distribution tarballs')
We want to distribute the generated documentation when we generate the
tarball because we normally do it when we do a release, but `meson dist`
only includes files that are commited to the repository, so a script
meson-dist-data.sh was added with meson.add_dist_script in commit
1c41066a40 ('build: include documentation in meson dist').
This script was copying the whole documentation folders, including some
intermediate files that are not useful for users that wants to read the
docs. Get rid of them and copy only the files that are useful for users:
the generated html pages in docs/api and docs/libnm and the final man
pages.
Also, including these intermediate files caused at least one build
failure, although quite difficult to reproduce:
- Generate tarball with meson
- Untar the generated tarball
- Using the sources from the tarball, configure the project with
autotools, but building to an out-of-tree folder, not building in
the source dir (i.e. using a 'build' subfolder). This is called
a "VPATH build" by autotools and Make. See:
- https://www.gnu.org/software/make/manual/html_node/General-Search.html
- https://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html
- Build
In that scenario, we get an error trying to generate any file under man/
because the man/ subdirectory has not been created. The reason of this
was that the man/ subdirectory is created by the Makefile when
generating the file man/common.ent. However, this file was present in
the source directory because it has been included in the tarball, so
Make detects it and doesn't run the rules to generate it. The result is
that out-of-tree-dir/man folder is not created.
Not including the intermediate files solves this problem.
Fixes: 1c41066a40 ('build: include documentation in meson dist')
Previously, the mock server did not behave as expected when given an aliased property
and the test results were not matching that of actual NM daemon behavior.
Previously, the tarball generated by `meson dist` did not contain the
autogenerated documentation due to the way meson works (packaging the
latest revision control commit). This introduces a dist script which
builds & copies the generated documentation into the distribution
tarball.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1811
The base image for the "check-tree" test got bumped to Fedora 39. This
brings a new python-black version (23.7.0 vs. 22.8.0) and requires
reformatting.
Maybe we should stick to 22.8.0, via `pip install`. But it seems better
to just follow the latest black version (the one from current Fedora).
So do the reformatting instead.
https://black.readthedocs.io/en/stable/change_log.html#id38
The user can set "$NMTST_LIBTOOL" to empty or the path to libtool.
If unset, we want to detect it. However, previously we would always
use "$SCRIPT_PATH/../libtool", even if that file doesn't exit. Improve
that.
For example, when running on Ubuntu with the ".gitlab-ci/debian-install.sh"
script, we don't have libtool. Entering such a container and running the
"run-nm-test.sh" script will fail as "$SCRIPT_PATH/../libtool" doesn't
exist.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1800
- If ".git/nm-in-container-host" exists, bind mount all of "/" to
"/Host".
- also honor all ".git/nm-data-link-*" files for additional
directories to bind mount.
- as before, honor ".git/NetworkManager-ci" symlink.
Note that directories also get symlinked from "/". Like
"/NetworkManager-ci" which symlinks links to the bind mount location.
Gtkdoc comments are used, among other things, to generate the various
nm-setting-* manual pages. When a constant is referenced in a gtkdoc
comment (i.e. `%NM_IP_TUNNEL_MODE_IPIP`) it is expanded to show the C name
and the value (i.e. `NM_IP_TUNNEL_MODE_IPIP (1)`). To generate the
nm-setting-* manual pages, we don't use gtkdoc, but we process this data
with the custom script tools/generate-docs-nm-settings-docs-gir.py.
This script was expanding the constants in the same way than gtkdoc.
Showing the constants in that way in nm-setting-* manual pages makes
little sense, because users are not going to use the C identifiers.
Let's show them with a more appropriate format.
Additionally, the different nm-setting-* pages might require different
formats than the other. For example, for nm-setting-nmcli a format like
`"ipip" (1)` is prefered, but for nm-setting-dbus it's better
`1 (ipip)`. Let's generate different nm-settings-docs-gir-*.xml files for
nmcli, dbus, keyfile and ifcfg-rh, using the right format for each one.
In some cases, properties documentation might require to provide an
explanation of each of the possible values that the property accepts.
If the possible values are the variants of an enum, we can use the
introspection data to get all the possible values for that enum and
their descriptions. With that info, we can automatically generate the
documentation with an always up to date list of accepted values.
Add a new "expand enumvals" feature: it will convert a token with the
format `#EnumName:*` to a list of all the possible values. For the
docbook (description-docbook field in the XML), it is expanded to a
bulleted list of all the values and their respective documentations.
This feature is limited to the "property-infos" comments (those like
---nmcli---, ---dbus---, etc). This comments are used only to generate
the nm-settings-* manual pages. For the documentation under the doc/
folder this is not needed: it's not supported by gtkdoc and, anyway,
it's better to use just `#EnumName` that will generate an HTML link.
Additionally, expansion of `%ENUM_VALUE` is now supported in the
property-infos comments. Instead of expanding them in the same style
than gtkdoc "ENUM_VALUE (num)", it is expanded in a format more suitable
for the nm-setting-* manual pages:
- for nmcli: value_nick (num)
- others: num (value_nick)
Also, fix typo in meson build file propery -> property.
If there are properties that accept special values apart from the
normally accepted values, or any of those values has an special meaning,
it can be shown as "Special value", indicating the nicknames and numbers
that can be used to select it.
Show a new field called "Valid values" in those properties that only
accept a limited set of values, like enums, ints with a valid range of
values, etc.
As there is some complex logic behind getting this information, this
logic has been put in nm-meta-setting-desc and nm-enum-utils so they can
be re-used, avoiding duplicity and errors. Some refactor has been done
in nm-meta-setting-desc in this direction, too.
Message of the day was shown twice because the same bashrc.my file than
for containers was used. That file contained some code to show motd in
the container, where it is not shown by default. But in the VM, the motd
is shown by default, so it was shown twice.
Move the code to show motd to a file used only by nm-in-container and
not by nm-in-vm.
Also, modify the explanation about using prepare-for-system.sh because
it's only valid for Fedora but nm-in-vm can be used with other SOs too.
The $VM name is used also as hostname in the guest so ssh connection can
be made to root@$VM. However, valid hostnames can only contain letters,
numbers and '-'. If other characters are used, they are removed from the
hostname so you cannot connect to root@$VM. Fix it by not allowing
invalid hostnames in $VM at VM creation.
Also, fix some incorrect bash regexes.
Install missing repositories required to install all the packages.
Unluckily, it doesn't support 9P filesystem shares, and virtiofs is not
supported for non-root hosts. Emit a warning about that.
Images of qcow2 format dynamically grow up to the maximum size that they
have been configured at creation time. Because of this, higher size can
be selected without wasting unnecesary space in the host. Rise image
size to 20G.
Also, allow to set an empty value to IMAGE_SIZE, and don't resize in
that case. This is useful because virt-resize fails with some guest
partition layouts (like with ubuntu-20.04).
Using more than one VM can be a quite common use case. Insteado of
having to do VM=vm_name ./nm-in-vm, allow the more common way of passing
options ./nm-in-vm --vm vm_name.
Also, in build command, accept one positional argument to set OS_VERSION.
The connectivity with the host depends on getting a DHCP lease from the
host. With the latest commit's customizations, the virtual NIC is not
managed by NM so it is not configured.
Keep it unmanaged so debuging NetworkManager doesn't affect to this
virtual NIC. Use dhclient to get a DHCP lease from the host. Assign a
fixed interface name (host_net) to match it from NM and dhclient config
files.
The script was generating the data-* files that later copies to the
container.
In order to the files being reusable for nm-in-vm, put them as separate
files inside the data directory.
However, some of the files need the full path to NetworkManager project,
which varies for each user. Instead, make a sed replacement on them and
generate the actual files that will be copied. Replacement:
{{BASEDIR_NM}} -> $BASEDIR_NM
Also, rename the files to more descriptive names, using some prefixes
that give a hint of where those files will be put, and the .in extension
to indicate that they will be processed.
nm-in-vm can use the same generated files than nm-in-container, so let's
move them to a place common for both: tools/nm-guest-data.
With this change, it is not worth it to have the nm-in-container
directory, so move the script to tools and delete the subdirectory.
