Once IPv6 addresses have been acquired, assign these to the interface
with the prefix lengths taken from the ICMPv6 Router Advertisement
handling code. The preferred and valid IPv6 address lifetimes are
handed to the kernel which will clean up them if not renewed in time.
When a prefix announced via Router Advertisements expires, find all
addresses that match that prefix and update the address to have a
prefix length of 128 causing the prefix to be off-link.
Add test cases that feeds an Router Advertisement to the ICMPv6 code
and verify that the correct prefix lengths are returned given an IPv6
address.
Enhance the prefix verification test by adding a shorter prefix and
check that the intended prefix lengths are now updated.
Save each new onlink IPv6 prefix and attach an expiry timer to it.
If the prefixes overlap, take the shorter prefix and write a debug
message about the event. Once the prefix is resent in a Router
Advertisement, update the timer. Add a new event for the expiring
prefix.
Add two helper functions, one for returning a prefix length given a
Router Advertisement and the other for generic prefix matching given
an IPv6 prefix and address.
As the IPv6 prefixes are needed, update the ICMPv6 Router Advertisement
code to dynamically allocate a suitably sized buffer. Iterate through
the ICMPv6 options one by one returning error if the option length is
too big to fit the buffer.
Revise the address iteration functions so that one helper function
resets the iterator to the start of the address list while the
second one fetches addresses one by one.
The test case is also updated.
We should prefer the unifont.hex file from the system, instead of our
own. Upstream has made a few releases since our version was included,
and we should follow upstream changes. But adding 2.6MB to our source
repo every time upstream releases is not nice.
I looked over all access invocations, and I think are using access()
correctly. Accepting dangling symlinks makes sense only in special
circumstances.
So far we do not allow "flag" files like "/fastboot" to be dangling
symlinks. We could, but I don't see a reason to.
This way timesyncd cannot be used to fork().
Note that it generally is not safe to use RLIMIT_NPROC, since it breaks
running the same daemon in multiple containers if they do not use user
namespacing. However, timesyncd is excepted from running in a container
anyway, hence it is safe in this case.
The offline update mechanism is explicitly designed to work with a
separate /var. systemd-update-generator is supposed to run early,
before filesystems are mounted, so it cannot check if the
/system-update symlink actually points to anything.
The update is run *after* filesystems are mounted, so it should be
able to access the target of the symlink without trouble.
https://bugzilla.redhat.com/show_bug.cgi?id=1178978
Previously, we only minimally altered the dbus1 framing for kdbus, and
while the header and its fields where compliant Gvariant objects, and so
was the body, the entire message together was not.
As result of discussions with Ryan Lortie this is now changed, so that
the messages in there entirely are fully compliant GVariants. This
follows the framing description described here:
https://wiki.gnome.org/Projects/GLib/GDBus/Version2
Note that this change changes the framing of *all* messages sent via
kdbus, this means you have to reboot your kdbus system, after compiling
and installing this new version.
This warning got its own name only in gcc5, so the suppression does
not work in gcc4, and generates a warning of its own. Use a cast,
which is ugly too, but less so.
This is not exposed in the public API. We want to simplify the internal libudev-device API as much as possible
so that it will be simpler to rip the whole thing out in the future.
Both plain opendir() and glob() will bump access time. Privileged
option O_NOATIME can be used to prevent the access time from being
updated. We already used it for subdirectories of the directories
which we were cleaning up. But for the directories specified directly
in the config files, we wouldn't do that. This means that,
paradoxically, our own temporary directories for PrivateTmp would stay
around forever, as long as one let systemd-tmpfiles-clean.service run
regularly, because they had their own glob patterns specified.
https://bugzilla.redhat.com/show_bug.cgi?id=1183684
systemd-tmpfiles can be used by users, but it can be quite hard to
figure out the logic it follows, especially since the logic is in some
places rather torturous. Hopefuly this will make it easier for users
to understand what is happening.
Patch updates Polish translation with new strings from
org.freedesktop.import1.policy.in, as well as incorporates updates in
catalog and po files to accommodate recent changes in the original
strings (commits 2e219e5672 and
2057124e79).
https://bugs.freedesktop.org/show_bug.cgi?id=88707
Current systemd requires kernel >= 3.7 per the README file
but CONFIG_USB_DEVICEFS disappeared from the kernel in
upstream commit fb28d58b72aa9215b26f1d5478462af394a4d253
(kernel 3.5-rc1)
Previously we tried to stick to a DNS server as long as it is available.
When /etc/resolv.conf changed, and the old DNS server we used was still
in there we'd continue to use it, even if it was at the end of the list.
With this change we'll now always start with the first DNS server in the
list again.
Rationale: certain network managing implementations (notably
NetworkManager) when connected to a VPN place both the VPN DNS server as
well as the local DNS server in /etc/resolv.conf. If we used the local
one before we would thus continue to use the local one, making VPN names
unresolvable. NetworkManager really should be fixed to only place the
VPN DNS servers in the file, but with this commit things are at least
similarly bad as they used to be...
According to systemctl man page, 'systemctl reboot [arg]' should work
without any errors. However, it does not work because of 'Invalid number
of arguments' error, except for 'reboot [arg]'. This patch fixes the bug
so that both of commands work in exactly the same way.
After all, mounts below these directories are pretty much guaranteed to
be virtual, and it's hence unnecessary to unmount them during shutdown.
Moreover, in less-priviliged containers we might lack the rights to
unmount them, hence don't even try.
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027113.html
Lennart Poettering