| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=710505
|
| |
|
|
|
|
|
|
|
| |
Add a "monitor-connection-files" config option, which can be set to
"false" to disable automatic reloading of connections on file change.
To go with this, add a new ReloadConnections method on
o.fd.NM.Settings that can be used to manually reload connections, and
add an nm-cli command to call it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ifcfg-rh didn't let you unmanage an InfiniBand device by hardware
address because it was recording the hardware address with uppercase
letters, while nm_match_spec_hwaddr() required lowercase. Fix this by
making nm_match_spec_hwaddr() match case-insensitively (and remove the
manual lowercasing that several other places were doing to work around
this.)
keyfile didn't let you unmanage an InfiniBand device by hardware
address because it only accepted ARPHRD_ETHER hardware addresses. Fix
that by using nm_utils_hwaddr_valid() instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't always want to immediately write new connections to disk, to
facilitate "runtime" or "temporary" connections where an interface's
runtime config isn't backed by on-disk config. Also, just because
an interface's configuration is changed doesn't necessarily mean
that new configuration should be written to disk either.
Add D-Bus methods for adding new connections and for updating existing
connections that don't immediately save the connection to disk.
Also add infrastructure to indicate to plugins that the new connection
shouldn't be immediately saved if the connection was added with the
new method.
|
| |
|
|
|
| |
They can just call nm_config_get() now to get the config, and
nm_config_get_path() to get its path.
|
| |
|
|
|
| |
[keyfile]
unmanaged-devices=interface-name:eth0
|
| |
|
|
|
|
|
| |
Virtual devices often don't have stable hardware addresses. So allow
for marking a device unmanaged via its interface name instead.
https://bugzilla.gnome.org/show_bug.cgi?id=693684
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
GObject creation cannot normally fail, except for types that implement
GInitable and take a GError in their _new() method. Some NM types
override constructor() and return NULL in some cases, but these
generally only happen in the case of programmer error (eg, failing to
set a mandatory property), and so crashing is reasonable (and most
likely inevitable anyway).
So, remove all NULL checks after calls to g_object_new() and its
myriad wrappers.
https://bugzilla.gnome.org/show_bug.cgi?id=693678
|
| |
|
