ifnet has two extra instances @p12_type/@phase2_p12_type, that only
differed from @pk_type/@phase2_pk_type by their suffix.
But as the suffix field as unused, we can drop that entirely.
If one property has multiple ways to be handled, we should not create
two ObjectType instances, instead let the ObjectType have enough
information to act accordingly.
The PKCS#11 URIs start with the "pkcs11:" scheme. There's a slight
possiblity of a clash with file names relative to the ifcfg file, but
that's probably is unlikely enough the leave us not worried.
The alteratives are probably more horrible (using a different key, or
using a separate key for the scheme alone) and it's already simple
enough to avoid a clash by using an absolute file name.
main() should pass the same atomic-section-prefix setting to it's
NMConfig instances. Currently both are NULL, but make it a define
to make this explicit.
Also, make static array @default_values const and sanitize value
when setting PROP_ATOMIC_SECTION_PREFIXES property.
When the main ifcfg file contains no IP addresses, the method
will be "disabled". Later, when reading IP addresses for the
aliases, we must ensure that the method is manual.
Otherwise, validation fails with
ip.addresses: this property is not allowed for method=disabled
Update the connectivity state if we go from CONNECTED_GLOBAL to
CONNECTED_LOCAL. It will likely fail immediately (unless there's a default
route we're not aware of or the check URL is routable locally), keeping the
Connectivity property up-to-date.
When we create a source tarball, documentation and other generated files
are disted. Those files depend on the configure options when creating
the tarball. For example, the generated man pages contain the compile time
configurable default values.
For that reason, it is generally better to regenerate the documentation when
building NetworkManager. However, let's set explict configure options to
have a more reproducible way to generate the tarball.
When doing a release, you should not just call `make dist`. Instead, the
proper way of creating an official source tarball is:
$ ./contrib/fedora/rpm/build_clean.sh --srpm
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
If no D-Bus connection is provided to the constructor of an NMObject, a
default one will be assigned in set_property(). However, construction of
that default D-Bus connection might fail (if our connection to the
system bus is refused, for example), so priv->connection might still be
NULL. This will cause the constructor to fail construction of the
NMObject, which is correct, but hard to debug.
Instead, move the default D-Bus connection handling into the
constructor, so all the (priv->connection == NULL) handling is in the
same place. Print out any error message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778610
This is sort of ugly, because it includes the domain and log levels
verbatim. They're just plain strings on the API, there's no way the
client would know which ones are valid.
On the other hand this kills one of two uses of nmc_parse_args(), which
probably means it's not a very good abstraction and maybe we should get
rid of it altogether. It is in particular unfriendly to argument
completion.
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
After commit 2049e97d9e ("dhcp: refactor parsing of 'request' and
'also request' options") NM parses all the existing 'request' and
'also request' from the original configuration file and appends them
as 'also request' to avoid duplicates and conflicts.
So if the original file contains 'request x' (which means "request
only option x instead of builtin defaults"), we would translate it
into 'also request x', which appends the option to the builtin
defaults, causing duplicates in the DHCP request as dhclient seems not
smart enough to sanitize the list by itself.
To fix this, ensure that the request list is reset if the
configuration file contains a 'request'.
Fixes: 2049e97d9ehttps://bugzilla.gnome.org/show_bug.cgi?id=778430
Also change the signature of the NM_SUPPLICANT_INTERFACE_STATE signal,
to have three "int" type arguments. Thereby also fix the subscribers
to this signal that wrongly had type guint32, instead of guint
(which happens to be the same underlying type, so no real problem).
https://mail.gnome.org/archives/networkmanager-list/2017-February/msg00021.html
Building the man pages via xsltproc requires "docbook.xsl"
which is part of docbook.
Previously, we would build the man pages solely based on
"--enable-introspection", which checks for the presence of
xsltproc, but not docbook. This can lead to build failure
when docbook is not available, but "--enable-introspection"
is given.
Instead of adding yet another configure option to fine-tune
and say "--with-docbook --disable-gtk-doc", just simplify it.
Now, documentation (both man pages and setting docs) will be generated
with "--enable-gtk-doc" and "--enable-introspection".
If the documentation is not about to be generated, pre-generated docs
will be installed if they are available. That is commonly the case
with a source tarball, but not with a git checkout.
Finally, if documentation is nither generated nor pre-generated,
no documentation will be installed *duh*.
This removes the possibility to treat man pages separate from settings
docs. Now you either generate both, install both pre-generated, or don't
get any of them.
https://bugzilla.gnome.org/show_bug.cgi?id=778551
We can't pass the password obtained from
nm_setting_802_1x_get_*private_key_password() to
nm_setting_802_1x_set_*private_key() as the latter also frees the old
password.
Fixes: afd2811028
