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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When a subshell is used ('make' or 'make all') the LOOPDEV environment
variable, which is used to store the opened loop device, is lost.
So the cleanup on trap/exit doesn't do anything, and the loop
device used to mount the test image is left around.
Avoid using a subshell to fix the issue.
This is an updated version of #8608 with more restrictive logic. To
quite the original bug:
Some captive portals, lie and do not respond with the captive portal
IP address, if the query is with EDNS0 enabled and D0 bit set to
zero. Thus retry "secure" domain name look ups with less secure
methods, upon NXDOMAIN.
https://github.com/dns-violations/dns-violations/blob/master/2018/DVE-2018-0001.md
Yes, this fix sucks hard, but I guess this is what we need to do to make
sure resolved works IRL.
Heavily based on the original patch from Dimitri John Ledkov, and I
copied the commentary verbatim.
Replaces: #8608
In scrutinizing the journal overhead of `systemctl status $service`
it became apparent that the matching engine was performing the unit
matches on every journal in my system, even ones containing nothing
relevant to the current boot.
This seemed strange and likely suboptimal to me, since there's likely
far more unit data to rifle through than boot IDs in any given
journal. The _BOOT_ID match seemed like it should be serving as an
early exit match on irrelevant journals, but that wasn't what seemed
to be happening.
As a quick experiment to see if I could get the _BOOT_ID match to be
something along the lines of a higher priority when matching, and try
early exit on these unrelated journals, I moved add_match_this_boot()
to after the unit match adds, inserting a conjunction between them.
The end result seems to be a very substantial performance gain in my
simple uncached tests, and I still get the expected journal output
from the `systemctl status $service` command:
----------------------------------------------------------------------
Unmodified systemctl times:
root@localhost:/# echo 2 > /proc/sys/vm/drop_caches
root@localhost:/# time systemctl --no-pager status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static; vendor preset: enabled)
Active: active (running) since Sun 2020-10-25 17:03:05 PDT; 1 day 6h ago
Docs: man:dbus-daemon(1)
Main PID: 572 (dbus-daemon)
Memory: 2.8M
CPU: 110ms
CGroup: /system.slice/dbus.service
└─572 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
Oct 25 17:03:05 localhost systemd[1]: Started D-Bus System Message Bus.
Oct 25 17:06:26 localhost dbus[572]: [system] Activating via systemd: service name='org.freedesktop.machine1' unit='dbus-org.freedesktop.machine1.service'
Oct 25 17:06:26 localhost dbus[572]: [system] Successfully activated service 'org.freedesktop.machine1'
real 0m0.695s
user 0m0.005s
sys 0m0.043s
root@localhost:/# echo 2 > /proc/sys/vm/drop_caches
root@localhost:/# time systemctl --no-pager status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static; vendor preset: enabled)
Active: active (running) since Sun 2020-10-25 17:03:05 PDT; 1 day 6h ago
Docs: man:dbus-daemon(1)
Main PID: 572 (dbus-daemon)
Memory: 2.8M
CPU: 110ms
CGroup: /system.slice/dbus.service
└─572 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
Oct 25 17:03:05 localhost systemd[1]: Started D-Bus System Message Bus.
Oct 25 17:06:26 localhost dbus[572]: [system] Activating via systemd: service name='org.freedesktop.machine1' unit='dbus-org.freedesktop.machine1.service'
Oct 25 17:06:26 localhost dbus[572]: [system] Successfully activated service 'org.freedesktop.machine1'
real 0m0.696s
user 0m0.003s
sys 0m0.046s
root@localhost:/# echo 2 > /proc/sys/vm/drop_caches
root@localhost:/# time systemctl --no-pager status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static; vendor preset: enabled)
Active: active (running) since Sun 2020-10-25 17:03:05 PDT; 1 day 6h ago
Docs: man:dbus-daemon(1)
Main PID: 572 (dbus-daemon)
Memory: 2.8M
CPU: 110ms
CGroup: /system.slice/dbus.service
└─572 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
Oct 25 17:03:05 localhost systemd[1]: Started D-Bus System Message Bus.
Oct 25 17:06:26 localhost dbus[572]: [system] Activating via systemd: service name='org.freedesktop.machine1' unit='dbus-org.freedesktop.machine1.service'
Oct 25 17:06:26 localhost dbus[572]: [system] Successfully activated service 'org.freedesktop.machine1'
real 0m0.694s
user 0m0.006s
sys 0m0.041s
----------------------------------------------------------------------
Modified systemctl including this commit:
root@localhost:/home/vc/gh/systemd/build# echo 2 > /proc/sys/vm/drop_caches
root@localhost:/home/vc/gh/systemd/build# time ./systemctl --no-pager status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static)
Active: active (running) since Sun 2020-10-25 17:03:05 PDT; 1 day 6h ago
TriggeredBy: ● dbus.socket
Docs: man:dbus-daemon(1)
Main PID: 572 (dbus-daemon)
Memory: 2.8M
CPU: 110ms
CGroup: /system.slice/dbus.service
└─572 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
Oct 25 17:03:05 localhost systemd[1]: Started D-Bus System Message Bus.
Oct 25 17:06:26 localhost dbus[572]: [system] Activating via systemd: service name='org.freedesktop.machine1' unit='dbus-org.freedesktop.machine1.service'
Oct 25 17:06:26 localhost dbus[572]: [system] Successfully activated service 'org.freedesktop.machine1'
real 0m0.168s
user 0m0.003s
sys 0m0.016s
root@localhost:/home/vc/gh/systemd/build# echo 2 > /proc/sys/vm/drop_caches
root@localhost:/home/vc/gh/systemd/build# time ./systemctl --no-pager status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static)
Active: active (running) since Sun 2020-10-25 17:03:05 PDT; 1 day 6h ago
TriggeredBy: ● dbus.socket
Docs: man:dbus-daemon(1)
Main PID: 572 (dbus-daemon)
Memory: 2.8M
CPU: 110ms
CGroup: /system.slice/dbus.service
└─572 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
Oct 25 17:03:05 localhost systemd[1]: Started D-Bus System Message Bus.
Oct 25 17:06:26 localhost dbus[572]: [system] Activating via systemd: service name='org.freedesktop.machine1' unit='dbus-org.freedesktop.machine1.service'
Oct 25 17:06:26 localhost dbus[572]: [system] Successfully activated service 'org.freedesktop.machine1'
real 0m0.167s
user 0m0.005s
sys 0m0.013s
root@localhost:/home/vc/gh/systemd/build# echo 2 > /proc/sys/vm/drop_caches
root@localhost:/home/vc/gh/systemd/build# time ./systemctl --no-pager status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static)
Active: active (running) since Sun 2020-10-25 17:03:05 PDT; 1 day 6h ago
TriggeredBy: ● dbus.socket
Docs: man:dbus-daemon(1)
Main PID: 572 (dbus-daemon)
Memory: 2.8M
CPU: 110ms
CGroup: /system.slice/dbus.service
└─572 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
Oct 25 17:03:05 localhost systemd[1]: Started D-Bus System Message Bus.
Oct 25 17:06:26 localhost dbus[572]: [system] Activating via systemd: service name='org.freedesktop.machine1' unit='dbus-org.freedesktop.machine1.service'
Oct 25 17:06:26 localhost dbus[572]: [system] Successfully activated service 'org.freedesktop.machine1'
real 0m0.170s
user 0m0.005s
sys 0m0.014s
This adds minimal support for RFC5001 NSID to the stub resolver. This
useful to identify systemd-resolved when talking to the stub resolver,
and distuingishing the packets resolved answers itself (where NSID is
now set) from those which it proxies 1:1 upstream (where NSID will not
be set, or set to whatever the upstream server has it set to).
The NSID chosen consist of two parts:
1. The first part is derived from /etc/machine-id and identifies the
resolved instance in a stable way.
2. The second part is the fixed string ".resolved.systemd.io".
This thus maybe used for a veriety of checks:
a. Am I talking to a resolved stub?
b. Am I talking to the same stub as last time?
c. Am I talking to the local resolved?
Given that the first part leaks the identity of the system in away two
protections are in place:
I) The NSID is only included on the main stub, not the extra stub. The
main stub has with a TTL of 1 and other protections a lot of safety
in place that the datagrams never leave the local system, thus the
identifying info is only accessible to the local system — but
/etc/machine-id is accessible to local software anyway.
II) The NSID is hashed from /etc/machine-id in a non-invertable way, so
that the machine ID itself isn't leaked, but only an identifier
derived from it.
Example dig run:
```
$ dig +nsid localhost @127.0.0.53
; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc33 <<>> +nsid localhost @127.0.0.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46917
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
; NSID: 35 33 64 34 61 34 66 63 32 31 32 65 34 31 61 30 39 66 30 39 65 33 32 34 63 64 64 38 30 36 32 33 2e 72 65 73 6f 6c 76 65 64 2e 73 79 73 74 65 6d 64 2e 69 6f ("53d4a4fc212e41a09f09e324cdd80623.resolved.systemd.io")
;; QUESTION SECTION:
;localhost. IN A
;; ANSWER SECTION:
localhost. 0 IN A 127.0.0.1
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Do Nov 12 20:57:16 CET 2020
;; MSG SIZE rcvd: 110
```
Taking a stab at implementing #14479.
Add {Condition,Assert}CPUFeature to `systemd-analyze` & friends. Implement it
by executing the CPUID instruction. Add tables for common x86/i386
features.
Tested via unit tests + checked that commands such as:
```bash
systemd-analyze condition 'AssertCPUFeature = rdrand'
```
Succeed as expected and that commands such as
```bash
systemd-analyze condition 'AssertCPUFeature = foobar'
```
Fail as expected. Finally, I have amended the `systemd.unit` manual page
with the new condition and the list of all currently supported flags.
The existing set_offline() short-circuit erroneously included
when f->archive was true and header->state was STATE_OFFLINE.
This commit makes the short-circuit f->archive aware, so it will
only catch scenarios where there's not an offlining in progress
and the header state matches the target state of either archived
or offline.
Fixes https://github.com/systemd/systemd/issues/17770
It's better for users if programs don't do "significant" things too easily, and
should be especially conservative when called without any arguments whatsoever.
So far systemd would would try to launch itself as a user manager and fail on
some cgroup permission stuff. systemd --user is run execlusively from user@.service
and there we call it with --user. Calls to the binary without any arguments as
non-pid1 are almost always a mistake.
https://github.com/systemd/systemd/issues/18419#issuecomment-779422571
