Now that nm-setting-docs.xml is more D-Bus-specific, it's less
appropriate for nmcli's internal documentation. So generate a second
copy of the docs without using the overrides file, and use that one
for nmcli's documentation.
Add "---dbus---" sections to the NMSetting property docs, in the same
style as the plugin docs, parse them out into a file
"nm-setting-docs-overrides.xml", and use them to override the GObject
property docs in nm-setting-docs.xml.
This lets us put more D-Bus-specific information in the setting docs,
without cluttering up the property docs, and it also lets us document
dbus-only properties.
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
When quitting, the Manager asks each device to spawn the interface helper,
which persists and manages dynamic address on the interface after NetworkManager
is gone. If the dynamic address cannot be maintaned, the helper quits and
the interface's address may be removed when their lifetime runs out.
To keep the helper as simple as possible, NetworkManager passes most of the
configuration on the command-line, including some properties of the device's
current state, which are necessary for the helper to maintain DHCP leases
or IPv6 SLAAC addresses.
Port libnm-core/libnm to GDBus.
The NetworkManager daemon continues to use dbus-glib; the
previously-added connection hash/variant conversion methods are now
moved to NetworkManagerUtils (along with a few other utilities that
are now only needed by the daemon code).
Instead of creating it in NMSettings, where we must use
NM_IS_DEVICE_ETHERNET() (not NM_DEVICE_TYPE_ETHERNET because various generic
devices masquerade as NM_DEVICE_TYPE_ETHERNET too), push knowledge
of which device types create default wired connections into the device
types themselves. This solves a problem with testcases where
libNetworkManager.a (which testcases link to) requires the symbol
nm_type_device_ethernet().
Implement some basic secret agent functionality in
test-networkmanager-service.py, and add test-secret-agent to test that
NMSecretAgent works as expected.
Port the dbus-glib-based examples to GDBus.
Also, don't use libnm in them at all; there's not much point in
examples that use the D-Bus API directly if they're just going to fall
back to libnm for the hard stuff... (And also, this avoids the problem
that GDBus uses GVariant, while the libnm-core APIs currently still
use GHashTables.)
Also fix up some comment grammar and copyright style, and add emacs
modelines where missing.
Also rename the existing GDBus-based examples to have names ending in
"-gdbus", not "-GDBus", since there's no reason to gratuitously
capitalize here.
Make the formerly-nm-param-spec-specialized test compile (fix use of
inet_pton), and pass (include the mandatory "gateway" element in the
IPv6 addresses), make it use gtestutils and g_assert (so it actually
fails when it fails), and test a few more cases.
generate-plugin-docs.pl was assuming that it was being run out of
srcdir, and so failed in srcdir!=builddir builds (such as "make
distcheck"). Fix that.
Also, update .gitignore
Instead of handling iBFT (iSCSI Boot Firmware Table) in the ifcfg-rh plugin,
create a new plugin for it. This allows all distributions to use iBFT
configuration, and makes both iBFT handling and ifcfg-rh less complicated.
The plugin (like the old ifcfg-rh code) creates read-only connections backed
by the data exported by iscsiadm. The plugin does not support adding new
connections or modifying existing connections (since the iBFT data is
read-only anyway). Instead, users should change their iBFT data through
the normal firmware interfaces.
Unmanaged devices can be configured through NetworkManager.conf and the
normal 'keyfile' mechanisms.
(In the future, we'll read this data directly from the kernel's
/sys/firmware/ibft/ethernetX directory instead of iscsiadm, since the
kernel has all the information we need and that's where iscsiadm gets
it from anyway.)
https://bugzilla.gnome.org/show_bug.cgi?id=734009
When switching to and fro old branches, you end up with
the (now removed) libgsystem submodule. As `git clean -fd`
refuses to remove git-repositories, this is especially annoying.
Tell git to ignore it.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Since the API has not changed at this point, this is mostly just a
matter of updating Makefiles, and changing references to the library
name in comments.
NetworkManager cannot link to libnm due to the duplicated type/symbol
names. So it links to libnm-core.la directly, which means that
NetworkManager gets a separate copy of that code from libnm.so.
Everything else links to libnm.
This fixes up the code from the previous "clean" import, and adds
build infrastructure.
[There are two slightly orthogonal sets of changes in this patch.
First, the files added in the previous commit were modified as followed:
# Replace internal references to "libnm-util" and "libnm-glib" with "libnm"
perl -pi -e 's/libnm-(util|glib)/libnm/;' libnm-core/*.[ch] libnm-core/tests/*.[ch] libnm/*.[ch] libnm/tests/*.[ch]
# Fix includes of the enum-types files
perl -pi -e 's/nm-utils-enum-types/nm-core-enum-types/;' libnm-core/*.[ch] libnm-core/tests/*.[ch] libnm/*.[ch] libnm/tests/*.[ch]
perl -pi -e 's/nm-glib-enum-types/nm-enum-types/;' libnm/*.[ch] libnm/tests/*.[ch]
# Fix some python example code
perl -pi -e 's/import NMClient/import NM/;' -e 's/NMClient.Client\(\)/NM.Client()/;' libnm/nm-client.c
Then, the build infrastructure was added (without further modifying
any existing files in libnm-core or libnm.)
Note: to regenerate libnm.ver after rebase:
(head -2 libnm-util/libnm-util.ver; (grep -h '\s'nm_ libnm-util/libnm-util.ver libnm-glib/libnm-glib.ver | env LANG=C sort); tail -3 libnm-util/libnm-util.ver) > libnm/libnm.ver
]
Some subdirectories of src/ encapsulate large chunks of functionality,
but src/config/, src/logging/, and src/posix-signals/ are really only
separated out because they used to be built into separate
sub-libraries that were needed either for test programs, or to prevent
circular dependencies. Since this is no longer relevant, simplify
things by moving their files back into the main source directory.
The remaining contents of the test/ directory are:
- 2 python example programs that aren't as good as the ones in examples/
- a test of the deprecated libnm_glib API which isn't as good as the one
in libnm-glib/
- A DHCP-related test program that hasn't been relevant since 2005
Let's just kill it all
Create a new clients/ subdirectory at the top level, and move cli/ and
tui/ into it, as well as nm-online.c (which was previously in test/,
which made no sense).
cli/ was split into two subdirectories, src/ and completion/. While
this does simplify things (given that the completion file and the
binary both need to be named "nmcli"), it bloats the source tree, and
we can work around it by just renaming the completion file at install
time. Then we can combine the two directories into one and just have
it all under clients/cli/.
NetworkManager.h, NetworkManagerVPN.h, and nm-version.h are part of
the libnm-util API, so move them to libnm-util.
include/ still contains headers that are strictly NM-internal (eg,
nm-glib-compat.h).
nmcli used the GParamSpec doc strings to get property descriptions,
but they will be going away. Generate a .c file from the new XML
setting docs file, and link that into nmcli.
Add generate-setting-docs.py, based on tools/generate-settings-spec.c,
which generates a simple XML file describing all libnm setting
properties (still getting the default values via GParamSpec
introspection like generate-settings-spec.c does, but getting the
documentation out of the gtk-doc strings in the GIR file instead).
Make Wi-Fi support a plugin using the new device factory interface.
Provides a 7% size reduction in the core NM binary.
Before After
NM: 1154104 1071992 (-7%)
Wi-Fi: 0 110464
(all results from stripped files)
NetworkManager stopped touching /etc/hosts in late 2010 before the
NetworkManager 0.8.1 release. The code in nm-policy-hosts.c's only
purpose is to remove any of the entries that NetworkManager added long
ago.
I think we're at the point where people have already upgraded to
NetworkManager 0.8.1 or later and thus this code would be a NOP. The
only risk is that some stale /etc/hosts entries will be left if you
upgrade from NM 0.8 or lower to anything higher than that.
FWIW, Ubuntu Lucid (10.04) ships NM 0.8.0 and SLES11 ships NM 0.7.0, so
if users of these distros upgraded to a later NetworkManager they might
run into the stale entries issue if we remove this code from NM. But
given how old these distros are, it seems unlikely that users will do a
direct upgrade to something 4+ years newer...
https://bugzilla.gnome.org/show_bug.cgi?id=729689
Given an IPv4 address and prefix for a shared config, figure out
the DHCP address range automatically. To keep things simple we
allow a max of 252 addresses (not including network address,
broadcast address, and the hotspot) no matter what prefix you use,
so if the address is 10.0.10.1, you still only get a range of
10.0.10.2 -> 10.0.10.254.
But we also leave some addresses available above the host address
for static stuff, like we did before. This is done on a sliding
scale from 0 to 8 addresses, where about 1/10th the number of
available addresses are reserved.
https://bugzilla.gnome.org/show_bug.cgi?id=675973
If the interface who's IP configuration is being captured has the default
route, then read DNS servers from resolv.conf into the NMIP[4|6]Config.
This allows NetworkManager to repopulate resolv.conf if anything changes.
For example, if the system does not define a persistent hostname, then
when a device which has generated a connection activates, a hostname
lookup will be performed. The results of that lookup may change resolv.conf,
and thus NetworkManager must rewrite resolv.conf. Without capturing
DNS information at startup when generating connections, an empty
resolv.conf would be written.
