Re: [systemd-devel] Prefix delegation and IPv6 subnetting
If you're on a distribution running recent version of software, note that prefix delegation is completely dysfunctional as of 251 [1]. [1] https://github.com/systemd/systemd/issues/23546
Re: [systemd-devel] resolved vs. DNS servers listening on Linux dummy interfaces
> use DNSStubListenerExtra=
It's indeed this directive I'm using on the downstream interface. Maybe
I should have mentioned that.
Configuration / results (MACs etc. obfuscated, but all correct on the
running system):
# head -n-0 /etc/systemd/network/linux-dummy_local0.{netdev,network}
==> /etc/systemd/network/linux-dummy_local0.netdev <==
[NetDev]
Description=[...]
Kind=dummy
Name=local0
==> /etc/systemd/network/linux-dummy_local0.network <==
[Match]
Name=local0
[Network]
Description=[...]
Address=/64
Address=/24
DNSSEC=false
Domains=~home.example.org
LLMNR=false
MulticastDNS=false
# networkctl status local0
5: local0
Link File: /usr/lib/systemd/network/99-default.link
Network File:
/etc/systemd/network/linux-dummy_local0.network
Type: ether
State: routable (configured)
Online state: online
Driver: dummy
Hardware Address:
MTU: 1500
QDisc: noqueue
IPv6 Address Generation Mode: eui64
Queue Length (Tx/Rx): 1/1
Address:
*.network>
fe80::[...]
Route Domains: home.example.org
Activation Policy: up
Required For Online: yes
DHCP6 Client DUID: DUID-EN/Vendor:[...]
Mai 08 23:08:07 rpi3b-router systemd-networkd[378]: local0: netdev ready
Mai 08 23:08:07 rpi3b-router systemd-networkd[378]: local0: Link UP
Mai 08 23:08:07 rpi3b-router systemd-networkd[378]: local0: Gained carrier
Mai 08 23:08:07 rpi3b-router systemd-networkd[378]: local0: Gained IPv6LL
# ip address show local0
5: local0: mtu 1500 qdisc noqueue state
UNKNOWN group default qlen 1000
link/ether [...] brd ff:ff:ff:ff:ff:ff
inet [...]/24 brd [...] scope global local0
valid_lft forever preferred_lft forever
inet6 [...]/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::[...]/64 scope link
valid_lft forever preferred_lft forever
# resolvectl status local0
Link 5 (local0)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
DNS Domain: ~home.example.org
And with all these results a querying a DNS server on local0 e. g. by
"drill @ home.example.org" works but "resolvectl query
home.example.org" fails.
Re: [systemd-devel] resolved vs. DNS servers listening on Linux dummy interfaces
Hi, Petr. > Do you need any systemd-resolved specific features? Primarily, it's about the way directive Domains allows for directing queries to particular DNS servers based on the queries' domains. I'm using it to restrict the ISP's DNS server to the ISP's domain, use a local DNS server for local subdomains and have a DNS server like Quad 9 serve all the rest. This can be achieved with other applications, too, e. g. dnsmasq. But I find it more handy to configure with networkd/resolved, in particular, when these are already in use anyway. > I don't think resolved considers it common to have more than one DNS server on the localhost. As I understand it, it's the very purpose of directive Domains to have systemd-resolved interact with various different DNS servers. So why shouldn't one of these run on the same host as resolved? > unbound, knot-resolver These aren't an option. I do not need a cache only, but want to serve the said local-only subdomain, which also needs to comprise RRs other than [AAA]A like CNAME, MX or TXT. > dnsmasq This is indeed what I've been using so far. But I'd like to replace it for several reasons. I'm not happy with its development any more in many ways. The network configuration I need involves things like Prefix Delegation which I find easier to handle with networkd. So dnsmasq is limited to the DNS part, which in turn I'd prefer to configure with a server like Knot. I find this simply easier, e. g. I can use a regular zone file and don't have to memorize a bunch of custom dnsmasq switches. Serving a whole LAN is probably not exactly what resolved was primarily meant for. But my LAN isn't that big and so far having its stub resolver listen on the router's downstream interface is working like a charm. That aside my actual question was, whether resolved shouldn't recognize a DNS server on a Linux dummy interface just the way it recognizes servers on regular hardware links. And I'd find this interesting to know totally independent from the maybe a bit particular rest of my setup.
Re: [systemd-devel] 628c89cc (tentative devices) + disk/by-label udev rule
The messages about several sysfs paths per device aren't caused by volume labels as seen in /dev/disk/by-label only. On GPT systems they seem to be triggered by identical partition labels corresponding to variable PARTLABEL in output of blkid as well. Also, they can be seen launching Arch Linux installer's live system the file system handling of which I don't know well enough to tell what exactly is happening. I guess the solution to just suppress the messages will still be the same but thought it may make sense to quickly mention those findings here as the thread had been limited to labels in /dev/disk/by-label so far. On a side note several partitions tagged by the same partition label will probably exist on nearly every system. As /dev/disk/by-partlabel seems to reference only one per label I wonder whether this directory makes any sense at all. Regards, Peter Mattern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
I saw this on an Arch Linux (systemd 218) i686 QEMU VM using BIOS and GPT, too. Couldn't see it on another x86_64 VM using UEFI (TianoCore / OVMF) and GPT but configured exactly the same apart from this. Lenovo's Yoga 2 Pro used by the said bug report's OP is featuring a BIOS, too. So perhaps the more robust fix would be to make the gpt generator not generate swap units if fstab already configures any swap device? I. e. auto-discovery and swaps in fstab are mutually exclusive then. According to man (http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html, see section Description) systemd-gpt-auto-generator is supposed to behave like this by now already. So maybe a bug in systemd-gpt-auto-generator manifesting only in the context of BIOS + GPT? Regards, Peter Mattern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Long waiting for swap device
Similar findings can result from running systemd ≥ 209 on a kernel compiled without CONFIG_FHANDLE. You may want to check this on your system. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man (5) machine-info: add hostnamed chassis type embedded
man machine-info lacks hostnamed chassis type embedded as introduced in 218. The following lines should fix this. --- man/machine-info.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/man/machine-info.xml b/man/machine-info.xml index c654daa..9bf2bcb 100644 --- a/man/machine-info.xml +++ b/man/machine-info.xml @@ -139,7 +139,8 @@ literalserver/literal, literaltablet/literal, literalhandset/literal, - literalwatch/literal, as well as + literalwatch/literal and + literalembedded/literal as well as the special chassis types literalvm/literal and literalcontainer/literal for -- 2.2.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl list-dependencies: consider BindsTo as well?
Thanks for fixing this. May I suggest to adjust man systemctl accordingly, too? Necessary parts would be the one about option --reverse and command list-dependencies. As for the latter I'd suggest another change while you're at it. Phrase required and wanted units is rather ambiguous as it might make think of WantedBy and RequiredBy which don't apply here, if I didn't get it wrong. I for one think it would be better to simply state the parameters themselves, much as it's done with --reverse already, e. g. something like Show units stated by options Requires, Wants or BindsTo in unit NAME. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl list-dependencies: consider BindsTo as well?
Hello. Right now systemctl's command list-dependencies is considering parameters Wants and Requires only. But given that command's purpose I was wondering whether it wouldn't make sense to have it consider BindsTo as well. Regards, Peter Mattern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Calendar Timers: setting system clock may trigger jobs from the past
Separating the unit to sync time from the ones featuring OnCalendar by time-sync.target (or any arbitrary target used as separating wall) worked exactly as expected on ARM and is indeed a workaround for the problem. Couldn't reproduce the need to set DefaultDependencies=No in the units featuring OnCalendar as stated in the ToDo item but that could have been me, of course. Also, I tried to simulate the lacking RTC on an x86 QEMU guest by setting the VM's RTC to a date in the past for the sake of quicker reboots. Without using time-sync.target as disscussed *.timer units featuring OnCalendar did get started before the time was set yet setting the time did not trigger the corresponding *.service. This seemed worth mentioning to me as Tobias stated his patch was tested on a system featuring an RTC only so far. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Condition* options linked by AND if stated more than once
If one of these options gets stated more than once the different
instances seem to be linked by a logical AND, too. This prevents
overwriting these options via snippets in /etc, e. g.
systemd-timesyncd.service still won't run in KVM with a snippet
/etc/systemd/system/systemd-timesyncd.service.d/do-run-in-kvm.conf stating
[Unit]
ConditionVirtualization=kvm
Seen on Arch Linux, systemd 215-4, tested
Condition{Architecure,Host,Virtualization}.
Any thoughts?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Condition* options linked by AND if stated more than once
First, thank you very much for your quick responses. I had missed the description in man systemd.unit (If any of these options is assigned the empty string, ... at the end of the paragraph about Condition*, right?) and a snippet as posted by Michal works (I had already checked this myself but not posted back yet). So sorry for the noise. What seems odd to me is that all Config* options of a unit in /usr have to appear in the snippet in /etc if it's intended to change only a part of them but leave the others unmodified. But this is for a reason, I guess? Regards ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Calendar Timers: setting system clock may trigger jobs from the past
Hello. If a *.timer unit's timestamp as stated by OnCalendar is in the past and the actual system time is even before that timestamp the *.timer gets activated when the system clock gets set. This frequently happens on embedded devices which get their system time set during boot by 'ntpd -qg' and the like due to lack of an RTC. An import drawback is that *.timer units cannot be used to shut down or reboot the system in a context like this, imho. Seen like so with 215 on Arch Linux, both x86 and ARM. The behaviour can btw. not be reproduced with cronie's or Busybox's cron implementation. I don't know whether something could or should be done about this (personally I think yes), but thought it might make some sense to report here. Regards, Peter Mattern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
