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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Fixes#6282.
This solution is a bit busy, but we close the race without setting *.all.*, so
it is still possible to set a different setting for particular interfaces.
Setting just "default" is not very useful because any interfaces present before
systemd-sysctl is invoked are not affected. Setting "all" is too harsh, because
the kernel takes the stronger of the device-specific setting and the "all" value,
so effectively having a weaker setting for specific interfaces is not possible.
This makes ping(8) work without CAP_NET_ADMIN and CAP_NET_RAW because
those aren't effective inside rootless Podman containers.
It's quite useful when using OSTree based operating systems like Fedora
Silverblue, where development environments are often set up using
rootless Podman containers with helpers like Toolbox [1]. Not having
a basic network utility like ping(8) work inside the development
environment can be inconvenient.
See:
https://lwn.net/Articles/422330/http://man7.org/linux/man-pages/man7/icmp.7.htmlhttps://github.com/containers/libpod/issues/1550
The upper limit of the range of group identifiers is set to 2147483647,
which is 2^31-1. Values greater than that get rejected by the kernel
because of this definition in linux/include/net/ping.h:
#define GID_T_MAX (((gid_t)~0U) >> 1)
That's not so bad because values between 2^31 and 2^32-1 are reserved
on systemd-based systems anyway [2].
[1] https://github.com/debarshiray/toolbox
[2] https://systemd.io/UIDS-GIDS.html#summary
This should PID collisions a tiny bit less likely, and thus improve
security and robustness.
2^22 isn't particularly a lot either, but it's the current kernel
limitation.
Bumping this limit was suggested by Linus himself:
https://lwn.net/ml/linux-kernel/CAHk-=wiZ40LVjnXSi9iHLE_-ZBsWFGCgdmNiYZUXn1-V5YBg2g@mail.gmail.com/
Let's experiment with this in systemd upstream first. Downstreams and
users can after all still comment this easily.
Besides compat concern the most often heard issue with such high PIDs is
usability, since they are potentially hard to type. I am not entirely sure though
whether 4194304 (as largest new PID) is that much worse to type or to
copy than 65563.
This should also simplify management of per system tasks limits as by
this move the sysctl /proc/sys/kernel/threads-max becomes the primary
knob to control how many processes to have in parallel.
These sysctls were added in Linux 4.19 (torvalds/linux@30aba6656f), and
we should enable them just like we enable the older hardlink/symlink
protection since v199. Implements #11414.
This switches the RFC3704 Reverse Path filtering from Strict mode to Loose
mode. The Strict mode breaks some pretty common and reasonable use cases,
such as keeping connections via one default route alive after another one
appears (e.g. plugging an Ethernet cable when connected via Wi-Fi).
The strict filter also makes it impossible for NetworkManager to do
connectivity check on a newly arriving default route (it starts with a
higher metric and is bumped lower if there's connectivity).
Kernel's default is 0 (no filter), but a Loose filter is good enough. The
few use cases where a Strict mode could make sense can easily override
this.
The distributions that don't care about the client use cases and prefer a
strict filter could just ship a custom configuration in
/usr/lib/sysctl.d/ to override this.
To further avoid bufferbloat Explicit Congestion Notification (ECN)
should be enabled for both in and outgoing connections. The kernel
default is to enable it when requested for incoming connections, but
not to request it on outgoing connections. This patch enables it for
both.
A long time ago enabling these was causing problems, but these issues
have since been dealt with.
Fixes#9087.
It is redundant because in these cases the values in
`net.ipv4.conf.all.*` take precedence. Also, setting the `default` does
nothing for devices that already exist.
The default of 16 is pretty low, let's bump this to accomodate for more
queued datagrams. This is useful for AF_UNIX/SOCK_DGRAM logging and
sd_notify() sockets as this allows queuing more datagrams before things
start to block, thus improving parallelization and logging performance.
Quoting from Jon Corbet's report of Stephen Hemminger's talk at Linux
Plumbers Conference 2014 (https://lwn.net/Articles/616241/):
[...] So Stephen encouraged everybody to run a command like:
sysctl -w net.core.default_qdisc=fq_codel
That will cause fq_codel to be used for all future connections
[Qdiscs apply to interfaces, not connections. Pointed out by TomH
in the article comments. -- mschmidt] (up to the next reboot).
Unfortunately, the default queuing discipline cannot be changed,
since it will certainly disturb some user's workload somewhere.
Let's have the recommended default in systemd.
Thanks to Dave Täht for advice and the summary at
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2014-October/003701.html
Without this, secondary addresses would get deleted when the primary one is. This is not
the desired behavior when one would like to transition from one address to another in the
same subnet (such as when a new IP address is given over DHCP).
In networkd, when given a new IP over DHCP we will add it, without explicitly removing the
old one first (and hence never have a window without an IP address configured). Assuming the
addresses are in the same subnet, that means that the old address is the primary and the new
address is the secondary one. Once the old address expires, the kernel will drop it. With the
old behavior this means that both addresses would be lost, which is clearly not what we want.
With the new behavior, only the old address is lost, and the new one is promoted to primary.
Reported by Michael Olbrich <m.olbrich@pengutronix.de>
