IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
This patch add support to enables to send User Class option code 77
RFC 3004.
This option MAY carry multiple User Classes.
The format of this option is as follows:
Code Len Value
+-----+-----+--------------------- . . . --+
| 77 | N | User Class Data ('Len' octets) |
+-----+-----+--------------------- . . . --+
where Value consists of one or more instances of User Class Data.
Each instance of User Class Data is formatted as follows:
UC_Len_i User_Class_Data_i
+--------+------------------------ . . . --+
| L_i | Opaque-Data ('UC_Len_i' octets) |
+--------+------------------------ . . . --+
UserClass=
A DHCPv4 client can use UserClass option to identify the type or category of user or applications
it represents. The information contained in this option is an string that represents the user class
of which the client is a member. Each class sets an identifying string of information to be used by the DHCP service to classify clients. Takes a whitespace-separated list.
UserClass= hello world how are you
Closes: RFC: #5134
Rather than choosing to set or unset any of these flag
use kernel defaults. This patch makes following properties to unset.
UseBPDU = unset
HairPin = unset
FastLeave = unset
AllowPortToBeRoot = unset
UnicastFlood = unset
Double newlines (i.e. one empty lines) are great to structure code. But
let's avoid triple newlines (i.e. two empty lines), quadruple newlines,
quintuple newlines, …, that's just spurious whitespace.
It's an easy way to drop 121 lines of code, and keeps the coding style
of our sources a bit tigther.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
This makes users can configure DHCPv4 client with ClientIdentifier=duid-only.
If set so, then DHCP client sends only DUID as the client identifier.
This may not be RFC compliant, but some setups require this.
Closes#7828.
The DHCPv6 client can obtain configuration parameters from a
DHCPv6 server through a rapid two-message exchange solicit and reply).
When the rapid commit option is enabled by both the DHCPv6 client and
the DHCPv6 server, the two-message exchange is used, rather than the default
four-method exchange (solicit, advertise, request, and reply). The two-message
exchange provides faster client configuration and is beneficial in environments
in which networks are under a heavy load.
Closes#5845
This adds a simple condition/assert/match to the service manager, to
udev's .link handling and to networkd, for matching the kernel version
string.
In this version we only do fnmatch() based globbing, but we might want
to extend that to version comparisons later on, if we like, by slightly
extending the syntax with ">=", "<=", ">", "<" and "==" expressions.
RequiredForOnline= denotes a link/network that does/does not require being up
for systemd-networkd-wait-online to consider the system online; this makes it
possible to ignore devices without modifying parameters to wait-online.
Starting with kernel version 4.8 the kernel has a single `l3mdev` rule
that handles this. This rule will be created when the first VRF device
is added.
Typically when DHCP server sets MTU it is a lower one. And a lower than usual
MTU is then thus required on said network to have operational networking. This
makes networkd's dhcp client to work in more similar way to other dhcp-clients
(e.g. isc-dhcp). In particular, in a cloud setting, without this default
instances have resulted in timing out talking to cloud metadata source and
failing to provision.
This does not change this default for the Annonymize code path.
Routing Policy rule manipulates rules in the routing policy database control the
route selection algorithm.
This work supports to configure Rule
```
[RoutingPolicyRule]
TypeOfService=0x08
Table=7
From= 192.168.100.18
```
```
ip rule show
0: from all lookup local
0: from 192.168.100.18 tos 0x08 lookup 7
```
V2 changes:
1. Added logic to handle duplicate rules.
2. If rules are changed or deleted and networkd restarted
then those are deleted when networkd restarts next time
V3:
1. Add parse_fwmark_fwmask
Add prefix delegation documentation covering IPv6PrefixDelegation=
setting in the Network section as well as all the parameters and
the IPv6PrefixDelegation and IPv6Prefix sections implemented so
far, including DNS= and DNSLifetimeSec= settings.
DHCP responses could include static routes, but unfortunately not an
option to tell what scope to use. So it's important that the client sets
it properly.
This mimics what the `ip route add` command does when adding a static
route without an explicit scope:
* If the destination IP is on the local host, use scope `host`
* Otherwise if the gateway IP is null (direct route), use scope `link`
* If anything else, use the current default `global`.
Fixes#5979.
This work based on Tom's original patch
teg@1312172
By setting GatewayOnlink=yes, the kernel will assume that the gateway is onlink
even if there is no route to it.
Resolves issue #1283.
Allow setting bridge port priority in the Bridge section of the network file,
similar to e.g. port path cost setting.
Set the default to an invalid value of 128, and only set the port priority when
it's not 128. Unlike e.g. path cost, zero is a valid priority value.
Add a networkd-test.py to check that bridge port priority is correctly set.
Incidently, fix bridge port cost type and document valid ranges.
Per man:file-hierarchy(7), /lib is just a compatibility symlink; the
other manpages also refer to /usr/lib.
Found with:
git grep -P '(?<!/usr|/var|local)/lib' man/
IPv6 Neighbor discovery proxy is the IPv6 equivalent to proxy ARP for IPv4.
It is required when ISPs do not unconditional route IPv6 subnets
to their designated target, but expect neighbor solicitation messages
for every address on a link.
A variable IPv6ProxyNDPAddress= is introduced to the [Network] section,
each representing a IPv6 neighbour proxy entry in the neighbour table.
We shouldn't just have snippets of configuration, but instead
examples which show all the parts necessary to build a certain kind
of setup, with short explanations.
Put more emphasis on the routing part. This is the more interesting
thing, and also more complicated and novel.
Explain "search domains" as the special case. Also explain the effect of
~. in more detail.
DNS servers which have route-only domains should only be used for
the specified domains. Routing queries about other domains there is a privacy
violation, prone to fail (as that DNS server was not meant to be used for other
domains), and puts unnecessary load onto that server.
Introduce a new helper function dns_server_limited_domains() that checks if the
DNS server should only be used for some selected domains, i. e. has some
route-only domains without "~.". Use that when determining whether to query it
in the scope, and when writing resolv.conf.
Extend the test_route_only_dns() case to ensure that the DNS server limited to
~company does not appear in resolv.conf. Add test_route_only_dns_all_domains()
to ensure that a server that also has ~. does appear in resolv.conf as global
name server. These reproduce #3420.
Add a new test_resolved_domain_restricted_dns() test case that verifies that
domain-limited DNS servers are only being used for those domains. This
reproduces #3421.
Clarify what a "routing domain" is in the manpage.
Fixes#3420Fixes#3421
Also update the description of drop-ins in systemd.unit(5) to say that .d
directories, not .conf files, are in /etc/system/system, /run/systemd/system,
etc.
The long name is just too hard to type. We generally should avoid using
acronyms too liberally, if they aren't established enough, but it appears that
"RA" is known well enough. Internally we call the option "ipv6_accept_ra"
anyway, and the kernel also exposes it under this name. Hence, let's rename the
IPv6AcceptRouterAdvertisements= setting and the
[IPv6AcceptRouterAdvertisements] section to IPv6AcceptRA= and [IPv6AcceptRA].
The old setting IPv6AcceptRouterAdvertisements= is kept for compatibility with
older configuration. (However the section [IPv6AcceptRouterAdvertisements] is
not, as it was never available in a published version of systemd.
This reworks sd-ndisc and networkd substantially to support IPv6 RA much more
comprehensively. Since the API is extended quite a bit networkd has been ported
over too, and the patch is not as straight-forward as one could wish. The
rework includes:
- Support for DNSSL, RDNSS and RA routing options in sd-ndisc and networkd. Two
new configuration options have been added to networkd to make this
configurable.
- sd-ndisc now exposes an sd_ndisc_router object that encapsulates a full RA
message, and has direct, friendly acessor functions for the singleton RA
properties, as well as an iterative interface to iterate through known and
unsupported options. The router object may either be retrieved from the wire,
or generated from raw data. In many ways the sd-ndisc API now matches the
sd-lldp API, except that no implicit database of seen data is kept. (Note
that sd-ndisc actually had a half-written, but unused implementaiton of such
a store, which is removed now.)
- sd-ndisc will now collect the reception timestamps of RA, which is useful to
make sd_ndisc_router fully descriptive of what it covers.
Fixes: #1079
Add an option to disable appending DHCP option 3 (Router) to the DHCP
OFFER and ACK packets.
This commit adds the boolean option EmitRouter= for the [DHCPServer]
section in .network files.
Rationale: On embedded devices, it is very useful to have a DHCP server
running on an USB OTG ethernet gadget interface to avoid manual setup on
the client PCs, but it should only serve IP addresses, no route(r)s.
Otherwise, Windows clients experience network connectivity issues, due
to them using the address set in DHCP option 3 as default gateway.
Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
This allows selecting the propagation level of emitted LLDP packets
(specifically: the destination MAC address of the packets). This is useful
because it allows generating LLDP packets that optionally cross certain types
of bridges.
See 802.11ab-2009, Table 7-1 for details.
networkd: add support to set route table
1. add support to configure the table id.
if id is less than 256 we can fit this in the header of route as
netlink property is a char. But in kernel this proepty is a
unsigned 32. Hence if greater that 256 add this as RTA_TABLE
attribute.
2. we are not setting the address family now. Now set this property.
This is essentially a revert of f38e0cce75 (which
removed the documentation of DUIDType on purpose). The description is heavily
updated for the new semantics.
This addresses #3127 § 4.
Let's move DUID configuration into the [DHCP] section, since it only makes
sense in a DHCP context, and should be close to the configuration of
ClientIdentifier= and suchlike.
This really shouldn't be a section of its own, we don't have any for any of our
other per-protocol specific identifiers...
Follow-up for #2890#2943
IPv6 protocol requires a minimum MTU of 1280 bytes on the interface.
This fixes#3046.
Introduce helper link_ipv6_enabled() to figure out whether IPV6 is enabled.
Introduce network_has_static_ipv6_addresses() to find out if any static
ipv6 address configured.
If IPv6 is not configured on any interface that is SLAAC, DHCPv6 and static
IPv6 addresses not configured, then IPv6 will be automatically disabled for that
interface, that is we write "1" to /proc/sys/net/ipv6/conf//disable_ipv6.
1. Replace strtol with unhexchar, verified with valid and invalid DUID strings.
2. Fix logging to use log_syntax instead of log_error.
3. On error reading DUID, ignore read and preserve previous state.
4. Fix man-pages to use markup, remove options not yet implemented.
5. Remove spurious header line in new files.
Enabling router advertisement may even trigger SLAAC or DHCPv6 to be used to configure
IPv6 addresses on the link. It may not be obvious that only in the SLAAC case will the
Token have an effect. Clarify this in the man page.
Addresses issue #863.
This way "networkctl status" becomes a bit more useful by default, as router
information is just visible, without any further configuration.
LLDP reception is fully passive and relatively low simple and low traffic,
hence this should be safe to enable by default.
This reworks the sd-lldp substantially, simplifying things on one hand, and
extending the logic a bit on the other.
Specifically:
- Besides the sd_lldp object only one other object is maintained now,
sd_lldp_neighbor. It's used both as storage for literal LLDP packets, and for
maintainging info about peers in the database. Separation between packet, TLV
and chassis data is not maintained anymore. This should be a major
simplification.
- The sd-lldp API has been extended so that a couple of per-neighbor fields may
be queried directly, without iterating through the object. Other fields that
may appear multiple times, OTOH have to be iterated through.
- The maximum number of entries in the neighbor database is now configurable
during runtime.
- The generation of callbacks from sd_lldp objects is more restricted:
callbacks are only invoked when actual data changed.
- The TTL information is now hooked with a timer event, so that removals from
the neighbor database due to TTLs now result in a callback event.
- Querying LLDP neighbor database will now return a strictly ordered array, to
guarantee stability.
- A "capabilities" mask may now be configured, that selects what type of LLDP
neighbor data is collected. This may be used to restrict collection of LLDP
info about routers instead of all neighbors. This is now exposed via
networkd's LLDP= setting.
- sd-lldp's API to serialize the collected data to text files has been removed.
Instead, there's now an API to extract the raw binary data from LLDP neighbor
objects, as well as one to convert this raw binary data back to an LLDP
neighbor object. networkd will save this raw binary data to /run now, and the
client side can simply parse the information.
- support for parsing the more exotic TLVs has been removed, since we are not
using that. Instead there are now APIs to extract the raw data from TLVs.
Given how easy it is to parse the TLVs clients should do so now directly
instead of relying on our APIs for that.
- A lot of the APIs that parse out LLDP strings have been simplified so that
they actually return strings, instead of char arrays with a length. To deal
with possibly dangerous characters the strings are escaped if needed.
- APIs to extract and format the chassis and port IDs as strings has been
added.
- lldp.h has been simplified a lot. The enums are anonymous now, since they
were never used as enums, but simply as constants. Most definitions we don't
actually use ourselves have eben removed.
This changes the UseDomains= setting of .network files to take an optional third value "route", in addition to the
boolean values. If set, the passed domain information is used for routing rules only, but not for the search path
logic.
Previously, .network files only knew a vaguely defined "Domains=" concept, for which the documentation declared it was
the "DNS domain" for the network connection, without specifying what that means.
With this the Domains setting is reworked, so that there are now "routing" domains and "search" domains. The former are
to be used by resolved to route DNS request to specific network interfaces, the latter is to be used for searching
single-label hostnames with (in addition to being used for routing). Both settings are configured in the "Domains="
setting. Normal domain names listed in it are now considered search domains (for compatibility with existing setups),
while those prefixed with "~" are considered routing domains only. To route all lookups to a specific interface the
routing domain "." may be used, referring to the root domain. An alternative syntax for this is the "*", as was already
implemented before using the "wildcard" domain concept.
This commit adds proper parsers for this new logic, and exposes this via the sd-network API. This information is not
used by resolved yet, this will be added in a later commit.
As it turns out the kernel does not support per-interface IPv6 packet
forwarding controls (unlike as it does for IPv4), but only supports a
global option (#1597). Also, the current per-interface management of the
setting isn't really useful, as you want it to propagate to at least one
more interface than the one you configure it on. This created much grief
(#1411, #1808).
Hence, let's roll this logic back and simplify this again, so that we
can expose the same behaviour on IPv4 and IPv6 and things start to work
automatically again for most folks: if a network with this setting set
is set up we propagate the setting into the global setting, but this is
strictly one-way: we never reset it again, and we do nothing for network
interfaces where this setting is not enabled.
Fixes: #1808, #1597.
The previous behavior:
When DHCPv6 was enabled, router discover was performed first, and then DHCPv6 was
enabled only if the relevant flags were passed in the Router Advertisement message.
Moreover, router discovery was performed even if AcceptRouterAdvertisements=false,
moreover, even if router advertisements were accepted (by the kernel) the flags
indicating that DHCPv6 should be performed were ignored.
New behavior:
If RouterAdvertisements are accepted, and either no routers are found, or an
advertisement is received indicating DHCPv6 should be performed, the DHCPv6
client is started. Moreover, the DHCP option now truly enables the DHCPv6
client regardless of router discovery (though it will probably not be
very useful to get a lease withotu any routes, this seems the more consistent
approach).
The recommended default setting should be to set DHCP=ipv4 and to leave
IPv6AcceptRouterAdvertisements unset.
The constraints we place on the pool is that it is a contiguous
sequence of addresses in the same subnet as the server address, not
including the subnet nor broadcast addresses, but possibly including
the server address itself. If the server address is included in the
pool it is (obviously) reserved and not handed out to clients.
This should clear up some confusion in
https://github.com/systemd/systemd/issues/717.
This basically copies the description from systemd.unit to this
man page. Masking can happen also in /run, so strike the part
about /etc, and also add the magic work "mask".
Justification is similar to BPDUGuard rename. "Positive" values
are easier. This is a rather uncommon option, so using a slightly
longer name should not be a problem, and may in fact may make it
easier to guess what the option does without reading the
documentation.
Looking at the kernel commit, "on" seems to be the default value:
commit 867a59436fc35593ae0e0efcd56cc6d2f8506586
Author: Vlad Yasevich <vyasevic@redhat.com>
Date: Wed Jun 5 10:08:01 2013 -0400
bridge: Add a flag to control unicast packet flood.
Add a flag to control flood of unicast traffic. By default, flood is
on and the bridge will flood unicast traffic if it doesn't know
the destination. When the flag is turned off, unicast traffic
without an FDB will not be forwarded to the specified port.
... and it seems to be the reasonable thing to do by default.
Rename to follow the follow the style of other options.
In general "positive" options are preferred to "negative" ones,
because they are easier to describe and easier for humans to
parse (c.f. the shortening on the man page entry).
- Make sure that the IPv6PrivacyExtensions=yes results in
prefer-temporary, not prefer-public.
- Introduce special enum value "kernel" to leave setting unset, similar
how we have it for the IP forwarding settings.
- Bring the enum values in sync with the the strings we parse for them,
to the level this makes sense (specifically, rename "disabled" to
"no", and "prefer-temporary" to "yes").
- Make sure we really set the value to to "no" by default, the way it is
already documented in the man page.
- Fix whitespace error.
- Make sure link_ipv6_privacy_extensions() actually returns the correct
enum type, rather than implicitly casting it to "bool".
- properly size formatting buffer for ipv6 sysctl value
- Don't complain if /proc/sys isn't writable
- Document that the enum follows the kernel's own values (0 = off, 1 =
prefer-public, 2 = prefer-temporary)
- Drop redundant negating of error code passed to log_syntax()
- Manpage fixes
This fixes a number of issues from PR #417
We refer to the same sysctl-setting twice, which is misleading. Correctly
list all global forwarding options. As we _always_ change the forwarding
setting on links, they will get disabled by default. The global sysctl
defaults thus will not have any effect.
This did not really work out as we had hoped. Trying to do this upstream
introduced several problems that probably makes it better suited as a
downstream patch after all. At any rate, it is not releaseable in the
current state, so we at least need to revert this before the release.
* by adjusting the path to binaries, but not do the same thing to the
search path we end up with inconsistent man-pages. Adjusting the search
path too would be quite messy, and it is not at all obvious that this is
worth the effort, but at any rate it would have to be done before we
could ship this.
* this means that distributed man-pages does not make sense as they depend
on config options, and for better or worse we are still distributing
man pages, so that is something that definitely needs sorting out before
we could ship with this patch.
* we have long held that split-usr is only minimally supported in order
to boot, and something we hope will eventually go away. So before we start
adding even more magic/effort in order to make this work nicely, we should
probably question if it makes sense at all.
In particular, use /lib/systemd instead of /usr/lib/systemd in distributions
like Debian which still have not adopted a /usr merge setup.
Use XML entities from man/custom-entities.ent to replace configured paths while
doing XSLT processing of the original XML files. There was precedent of some
files (such as systemd.generator.xml) which were already using this approach.
This addresses most of the (manual) fixes from this patch:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
The idea of using generic XML entities was presented here:
http://lists.freedesktop.org/archives/systemd-devel/2015-May/032240.html
This patch solves almost all the issues, with the exception of:
- Path to /bin/mount and /bin/umount.
- Generic statements about preference of /lib over /etc.
These will be handled separately by follow up patches.
Tested:
- With default configure settings, ran "make install" to two separate
directories and compared the output to confirm they matched exactly.
- Used a set of configure flags including $CONFFLAGS from Debian:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules
Installed the tree and confirmed the paths use /lib/systemd instead of
/usr/lib/systemd and that no other unexpected differences exist.
- Confirmed that `make distcheck` still passes.
