Calling g_file_test with a NULL path causes valgrind to complain.
NetworkManager[24512]: <debug> [1377884547.687536] [dhcp-manager/nm-dhcp-dhclient.c:482] create_dhclient_config(): (em1): no existing dhclient configuration to merge
==24512== Syscall param access(pathname) points to unaddressable byte(s)
==24512== at 0x3F976E7627: access (in /usr/lib64/libc-2.17.so)
==24512== by 0x4EDA556: g_file_test (in /usr/lib64/libglib-2.0.so.0.3600.3)
==24512== by 0x49BB69: create_dhclient_config (nm-dhcp-dhclient.c:364)
==24512== by 0x49CC39: ip4_start (nm-dhcp-dhclient.c:671)
Signed-off-by: Thomas Haller <thaller@redhat.com>
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
Add hidden command line option --run-from-build-dir; with that, helpers
like nm-avahi-autoipd.action and nm-dhcp-helper will be called from the
build tree instead of libexecdir, which allows testing without having to
install first.
Helper paths are now stored in global variables instead of macros, and
get modified with that new option.
https://bugzilla.gnome.org/show_bug.cgi?id=698752
Although having different parts of NM in different subdirectories
keeps the source tree neat, it has made the build messy, particularly
because of cross-dependencies between the subdirs.
Reorganize to build all of the pieces of the NetworkManager binary
from src/Makefile, and only use recursive make for test programs,
helper binaries, and plugins.
As part of this, get rid of all the per-directory convenience
libraries, and switch to building a single top-level
libNetworkManager.la, containing everything except main.c, which all
of the test programs can then link against.
Allows DHCP to work when a bus daemon isn't running. This also
fixes a race condition where when multiple interfaces are attempting
to get a DHCP lease at the same time, if one DHCP client instance
triggers the callout, that instance gets the bus name, and any
other client triggering the callout at that time will fail because
the bus name is already taken. Since this commit allows using
a private socket, where no process has a bus name, this race is
avoided.
Also move the DHCP helper from callouts/ to src/dhcp-manager/ to
consolidate all the DHCP stuff and clean up some of the helper's
code.
Rather than passing specific bits of data to NMDHCPManager and
NMDnsManager, just let them call nm_config_get() and then get the data
themselves.
Also, remove the GError argument from nm_dhcp_manager_new(), since the
function never returned NULL. This in turn means there is no longer
any need for a distinction between nm_dhcp_manager_new() and
nm_dhcp_manager_get(), so remove the former.
When the default leasefile location got moved from distro-specific
dhclient locations to a single NM-specific location, that apparently
broke scripts and external tools that depended on the old location,
like dract netbooting.
During a netboot, DHCP is started from the initramfs and gets a
lease, and the leasefile lives in the initramfs. When the real
system is started, and the rootfs switches from the initramfs to
the actual rootfs, something needs to copy the leasefiles over to
where NetworkManager can find them. For dracut at least, various
dracut scripts were doing this, and copying to the old location
in /var/lib/dhclient or /var/lib/dhcp. Which means NM can no
longer find them, and proceeds to acquire a new DHCP lease when
taking over the existing connection, rather than renewing the
existing lease. This can lead to loss of network connectivity
and thus the netboot process fails.
If no leasefile for the connection in the new location exists,
look in the old locations and copy that leasefile over to the new
location.
Not all systems have machine-id in /etc, some still have it in /var/lib/dbus/
especially if they aren't using systemd. Furthermore, if we don't have
any machine-id file (like in the future, if we don't have a messaebus
daemon running) fall back to a random DUID as a last resort.
The config file can specify a dhclient script, which gets used instead
of what NM passes on the command-line. Make sure that script gets
ignored in the final dhclient config, because the script NM passes
is the script that needs to be used to pass data back to NM. People
may have old dhclient.conf files lying around that get picked up and
we don't want any script specified there to interfere.
The original used uuid_parse() but that function did not
work properly since the format of the machine-id is
not compatable with a real uuid. This patch adds a new
machine_id_parse() routine to correctly convert the
character string of hex digits to a 16 byte binary string.
g_malloc(), etc, never return NULL, by API contract. Likewise, by
extension, no other glib function ever returns NULL due to lack of
memory. So remove lots of unnecessary checks (the vast majority of
which would have immediately crashed had they ever run anyway, since
g_set_error(), g_warning(), and nm_log_*() all need to allocate
memory).
https://bugzilla.gnome.org/show_bug.cgi?id=693678
DHCPv6 RFCs require the DUID to be constant over time and to
be used as a permanent identifiers of the machine. This precludes
using a network interface MAC address since the MAC address may
change, and there may be more than one network interface installed.
Storing the DUID causes problems when an OS image is cloned between
virtual or physical machines because then the saved DUID is no longer
unique.
To fix all these issues, generate the DUID from the machine's hashed
machine-id, which is already a unique identifier of the machine and
will always be present because dbus requires it, and NM requires
dbus. It is assumed administrators will change the machine-id when
cloning an OS image; thus they only have to update one file, not
two (machine-id and the stored DUID).
Administrators may still override the machine-id-derived DUID by
setting a DUID in the default dhclient config file or the
interface-specific dhclient config files.
dhclient no longer saves a generated DUID to the config files,
because the default DUID will always be regenerated from
the machine-id on startup and thus always stable.
The DUID is supposed to be machine-wide, so if we're writing a new
leasefile, save the default DUID to it. If we haven't saved a
persistent DUID yet, do that to.
Add infrastructure for generating DUID-LLT from a given device MAC and
passing it around to the DHCP client implementations.
Thanks to Mathieu Trudel-Lapierre for bug fixes in the
unescaping code, which were merged into this commit.
For the default wired connection (or any connection that doesn't have an IPv4
setting, which means "auto"), the hostname should always be sent to the DHCP
server to register in DNS.
This patch makes DHCPv6 support more or less equivalent to that
one of IPv4 DHCP.
(dcbw: fix some formatting, rearrange code so it's less convoluted,
fix up writing hostname to ifcfg files)
For NetworkManager, dhclient is a runtime dependency. Distribution dhclient
configuration is either put directly into /etc or in /etc/dhcp. It is much
safer to check this at runtime than to guess the location from distribution
name.
Additionally, the distribution dhclient configuration files can be overriden
by a configuration file in /etc/NetworkManager.
TODO: Functions get_dhclient_config() and merge_dhclient_config() should
be also used for IPv6.
DHCP lease file names are built by NetworkManager and contain connection UUID
which makes them NM-specific. Their new location belongs to NetworkManager and
doesn't have to be guessed. With no guessing, we don't need distribution-specific
conditionals.
Note: This change may require modifications to the selinux policy. But after all
these files actually belong to NetworkManager as well as the instance of dhclient
that uses them.
Use --enable-doc and --enable-tests instead of --with-docs and
--with-tests. This is consistent with other features and with
--enable-gtk-doc option. Support current variants as fallback.
Don't build tests unless --enable-tests is specified.
Use autoconf/automake variables for NetworkManager paths. Use
NetworkManager subdirectory where appropriate.
Files in /var/run (or /run on some distros) are moved into a separate
directory as is usual with other daemons. It makes the filesystem
more readable and file prefixing unnecessary.
/var/run/NetworkManager.pid -> /var/run/NetworkManager/NetworkManager.pid
/var/run/nm-dns-dnsmasq.pid -> /var/run/NetworkManager/dnsmasq.pid
/var/run/nm-dns-dnsmasq.conf -> /var/run/NetworkManager/dnsmasq.conf
The /var/run/NetworkManager directory is created at runtime, if it doesn't
exist.
Note: Path-based security policies like SELinux and AppArmor may need to
be adapted.