Age | Commit message (Collapse) | Author |
|
Improve libsystemd-networkd DHCP API (v3)
|
|
networkd: tunnel add support to configure address "any"
|
|
Fix IPv6PrivacyExtension (networkd-ndisc.c)
|
|
Nss link less 2
|
|
networkd: link - do not drop config for critical interfaces
|
|
libsystemd-network provides the public function
sd_dhcp6_client_set_request_option() to enable the request of a given
DHCP option. However the enum defining such options is defined in the
internal header dhcp6-protocol.h. Move the enum definition to the
public header sd-dhcp6-client.h and properly namespace values.
|
|
libsystemd-network provides the public function
sd_dhcp_client_set_request_option() to enable the request of a given
DHCP option. However the enum defining such options is defined in the
internal header dhcp-protocol.h. Move the enum definition to the
public header sd-dhcp-client.h and properly namespace values.
|
|
At the moment sd_dhcp_lease_get_routes() returns an array of structs
which are not defined in public headers. Instead, change the function
to return an array of pointers to opaque sd_dhcp_route objects.
|
|
Remove the old version of the lz4 stream compressor
|
|
core: use bus_unit_check_load_state() in transaction_add_job_and_depe…
|
|
hwdb: remove references to udevadm info /dev/input/event*
|
|
journal-gatewayd: fix offset
|
|
I was checking something when writing the patch and
committed this by mistake.
|
|
bootctl: use DRAW_TREE_RIGHT rather than hard-coded UTF-8 character
|
|
basic/terminal-util: introduce SYSTEMD_COLORS environment variable
|
|
Fixes #2384
|
|
resolved bus API improvements
|
|
... to determine if color output should be enabled. If the variable is not set,
fall back to using on_tty(). Also, rewrite existing code to use
colors_enabled() where appropriate.
|
|
Not only report whether the server actually supports DNSSEC, but also first check whether DNSSEC is actually enabled
for it in our local configuration.
Also, export a per-link DNSSECSupported property in addition to the existing manager-wide property.
|
|
So far, we exposed SetLinkXYZ() on the Manager interface, to set a couple of link properties. This adds similar calls
SetXYZ() on the Link interface, and makes sure the former is little more than a shortcut to the latter.
SetLinkXYZ() has the benefit of not requiring a GetLink() round trip for setting these properties, while the method
actually belongs to the Link objects, and this change corrects that.
|
|
|
|
|
|
strv_consume() is pretty expensive when invoked piecemeal, hence optimize it a bit by pre-allocating a properly sized
array.
|
|
The link objects expose as properties the current settings made with SetLinkDNS() and related calls, plus some more
information.
|
|
Man page grammar and build tweaks v3
|
|
various configuration files
|
|
This is useful for alternative network management solutions (such as NetworkManager) to push DNS configuration data
into resolved.
The calls will fail should networkd already have taken possesion of a link, so that the bus API is only available if
we don't get the data from networkd.
|
|
These were previously forgotten, add them now.
|
|
For mDNS and LLMNR we already created the scopes only if the specific interfaces where actually up and suitable for
Multicasting. Add a similar (but weaker) logic for unicast DNS as well.
|
|
|
|
This should be generally useful information, hence show it.
|
|
|
|
- remove things which are clear from the context
- 0 is a valid descriptor number, hence "positive" → "non-negative"
- "positive" means greater than zero, hence "positive non-zero" → "positive"
- use oxford comma
- reword some things for clarity
|
|
resolved: hide public mDNS configuration knobs for now
|
|
Remove gcc warnings v2
|
|
These bits were intenionally left out while mDNS is under development.
Remove the exposed knobs and man page entries again until this is settled.
|
|
Fixes #2366
|
|
sixteenth DNSSEC patch set
|
|
Certain Belkin routers appear to implement a broken DNS cache for A RRs and some others, but implement a pass-thru for
AAAA RRs. This has the effect that we quickly recognize the broken logic of the router when we do an A lookup, but for
AAAA everything works fine until we actually try to validate the request. Given that the validation will necessarily
fail ultimately let's make sure we remember even when downgrading a feature level that OPT or RRSIG was missing.
|
|
|
|
|
|
When we restart a transaction because of an incompatible server, pick a new transaction ID.
This should increase compatibility with DNS servers that don't like if they get different requests with the same
transaction ID.
|
|
given that DNSSEC lookups may result in quite a number of auxiliary transactions, let's better be safe than sorry and
also enforce a limit on the number of total transactions, not just on the number of queries.
|
|
|
|
Previously, when getting notified about a completed auxiliary DNSSEC transaction we'd immediately act on it, and
possibly abort the main transaction. This is problematic, as DNS transactions that already completed at the time we
started using them will never get the notification event, and hence never be acted on in the same way.
Hence, introduce a new call dns_transaction_dnssec_ready() that checks the state of auxiliary DNSSEC transactions, and
returns 1 when we are ready for the actual DNSSEC validation step. Then, make sure this is invoked when the auxiliary
transactions are first acquired (and thus possibly reused) as well when the notifications explained above take place.
This fixes problems particularly when doing combined A and AAAA lookups where the auxiliary DNSSEC transactions get
reused between them, and where we got confused if we reused an auxiliary DNSSEC transaction from one when it already
got completed from the other.
|
|
|
|
Let's avoid thinking that a CNAME/DNAME chain traversal could be a good idea if QTYPE is already CNAME/DNAME.
(Also, let's bail out early when trying to see if some RR is a suitable CNAME/DNAME for some other RR).
|
|
If the first step was done via a search domain, make sure the subsequent steps are not.
|
|
|
|
IDNA checks
|