| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now update the default route metric based on the result of the
connectivity check. When we update the metric and there is no other
changes to the IP configuration, NMPolicy is not notified about it and
can't update the best device until an actual change in IP config
happens. This results in a wrong best device set in NMPolicy.
NMDevice has NM_DEVICE_IP[4,6]_CONFIG_CHANGED signals that are used
exclusively by NMPolicy to detect when there is a change in
configuration that requires an update of global DNS and routing
information. Emit those signals also when the default route changes.
|
| |
|
|
|
|
| |
Fixes: 6bf1d6fc163de9f69338af99641bd49f246f32b7
|
|
|
|
| |
Fixes: d720f0955ffda93e0fc1f7b69eb6a01395246229
|
|
|
|
| |
Fixes: d720f0955ffda93e0fc1f7b69eb6a01395246229
|
|
|
|
| |
Fixes: d720f0955ffda93e0fc1f7b69eb6a01395246229
|
|
|
|
| |
Also mark them for translation.
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
A larger refactoring of nmcli.
Splits out (a bit) the tracking of settings meta data. As such,
it goes towards what is proposed by bgo#732292.
Then, get rid (a bit) of the global data that is passed around.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We should not violate the global data to track the output data
while it is constructed and printed.
Most of the time, we actually clear the output data anyway --
either before constructing it, or after printing it.
In some cases we didn't, but I think that is a bug. It's really
hard to keep track of this.
The output data should belong to a certain scope and get destroyed
afterwards. Passing it around is very confusing. Don't do that.
|
| |
| |
| |
| |
| |
| | |
To better understand which part of the code have side effects,
split print_data() in a part that mutilates the input array
and a part that only prints.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Don't cast const strings to non-const. And don't track
whether to free a variable in a boolean. Instead, assign
ownership to variables that get destroyed when the function
returns.
|
| |
| |
| |
| |
| | |
Don't pass down the entire NmCli instance. The output_data
array is modified by print_data(), the rest is read-only input.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The NmCli structure is passed around everywhere and contains all
the state of the program. It is very hard to follow which parts
are used where.
Split out more configuration options to a NmcConfig field. This field
is mostly immutable, and modified at particular places that now can be
easily found.
|
| |
| |
| |
| |
| |
| | |
nmc contains all options and collects output data. It is very hard to
understand what it does. Start splitting it up, and pass arguments along
-- as needed.
|
| |
| |
| |
| |
| |
| |
| | |
Otherwise, changing the structure is difficult because it all depends
on the order (and you don't immdiately see which field is used where).
Also, drop the name_l10n field.
|
| |
| |
| |
| |
| |
| |
| | |
Change in behavior:
- the setter would previoulsy allow "enable" case-insensitive.
Now, it's case sensitive.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
libnm contains the public function nm_utils_enum_from_str() et al.
The function is not flexible enough for nmcli's usecase. So, I would
need another public function like nm_utils_enum_from_str_full() that
has an extended API.
That was already required previously for ifcfg-rh writer, but in that
case I could just add it as internal API as libnm-core is linked statically
with NetworkManager.
I don't want to commit to a public API for an utility function. So move
the code instead to the shared directory, so that nmcli may link
statically against it and use the internal API.
|
| | |
|
| |
| |
| |
| |
| | |
This changes behavior for the pretty-output.
Now, we output "%d (%s)" instead of "%s (%d)".
|
| | |
|
| |
| |
| |
| |
| | |
User data will be printed in a new multiline mode.
Need more work first.
|
| | |
|
| |
| |
| |
| |
| |
| | |
These functions are only used by nm-meta-setting-desc.c. Make them internal.
Unfortunately, they are part of "common.h" which cannot be used without
the rest of nmcli. Still todo.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This part contains static functions and variables to describe
settings. It is distinct from the mechanism to use them, or
access them.
Split it out.
It still uses clients/cli/common.h and clients/cli/utils.h
which shall be fixed next.
|
| |
| |
| |
| |
| |
| | |
They will be moved out of nmcli as they are generally useful.
Even if they happen to be used only inside nmcli, there should
be a better separation between logic (nmcli) and setting decriptions.
|
| |
| |
| |
| |
| |
| |
| |
| | |
is specified (again)
Commit 623d888801f611be4e4d14570d6c2f84dcd92937 was reverted during
refactoring nmcli to simplify merge conflicts. Restore the behavior
of the patch.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
functions
Mostly these strings are static. In same cases they are generated
however. Instead of caching them in a static variable, return them
to the caller.
And belatedly fix invoking describe_fcn().
|
| | |
|
| |
| |
| |
| |
| | |
Restore previous behavior of hiding blobs for certain
certificate properties.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
settings.c basically consists of property-type structures and *a lot* of
accessors. All these accessors share the same argument list.
It is very repetitive to specify it over and over again. Also, there
are so many arguments that one is compelled to wrap the lines. All
in all it results in a lot of noise that takes the eye from the important
code.
Also, the argument list is expected to change, so we possibly only
have to change one place.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We shall not only have a PropertyInfo. Most properties share common
behavior, that is, they have a type. Move the function pointers to
a NmcPropertyType structure, so that it can be reused for multiple
properties.
This promotes the idea that properties have a (limited) set of types
with some type specific behaviors. Contrary, to having each property
re-implement fully it's type. E.g. instead of having various property
re-define their full behavior as an "bool", have one property type
"bool" which can be attached to a property.
|
| | |
|
| |
| |
| |
| |
| | |
It's useful to see the entire name not having a macro construct it.
Otherwise, the usage is not grepable.
|
| |
| |
| |
| |
| | |
It's redundant information that requires us to declare it
in the static meta data. Generate it instead as needed.
|
| | |
|