On ti, 02 maalis 2021, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 02, 2021 at 11:29:21AM +0200, Alexander Bokovoy wrote:On ma, 01 maalis 2021, Lennart Poettering wrote: >On Fr, 26.02.21 21:01, Alexander Bokovoy (abokovoy@xxxxxxxxxx) wrote: > >>> 1. Dots (".") for separating IPV4 address bytes >>> 2. Colons (":") for separating IPv6 address parts, as well as separating >>> port numbers from the IP addres >>> 3. Brackets ("[]") for separating ipv6 addresses from the rest of the >>> construct >>> 4. Percent ("%") characters to separate interface info from the rest >>> 5. Hash ("#") characters to separate SNI host name specifications >>> >>> Now, we currently don't use "," and ";" for separators here, but as >>> these things keep growing we might need them for something soon too. >> >>I understand your willingness to apply the same rules for multiple >>options in the config files owned by systemd codebase. This, however, is >>a content pushed out by external parties, not a part of systemd >>proper. > >It's a configuration file *owned* by resolved. it's its private >property, with defined and documented syntax. if other tools make >changes to that config files, but they better follow the documented >syntax then. > >I'd be a lot more open to a more relaxed parser if this was some >"foreign" config file, not owned by resolved. i.e. /etc/resolv.conf is >owned by glibc and is maybe even more generic than that. There it's >our duty to to accept even the worst formatted files. > >But resolved.conf is inherently only ours, we define the contents and >are the sole consumer of it. Hence I think we don't have to be and >shouldn't be so lenient, so that the variances remain smaller. > >I mean, I#d consider the original issue here a simple bug. The >question is simply where to fix it: in cloud-init or in systemd. Given >that cloud-init is responsible for it, and given that either way >there's exactly one project to fix I think it should be cloud-init >that is fixed. Clearly, what happened in the cases described in this thread, is that some other configuration file was imported into resolved state and parsing the content that came from that import was failing. This is what I think an issue on systemd-resolved side. See below for cloud-init part. > >>Digital Ocean updates pushed with cloud-init use. Cloud-init does not >>have any native support for systemd-resolved. It means it writes >>something that systemd-resolved imports into own state. I would argue >>that your arguments for systemd-wide configuration rules do not apply >>here. Either you'd need to fix cloud-init or allow for a variance in >>input data that comes to systemd-resolved from third parties. > >Hmm, cloud-init has no direct support for resolved.conf? But how is it >then that that file is modified? I don't get it? https://github.com/canonical/cloud-init/search?q=resolved.conf -- nothing handles resolved.conf. It is done by something else after parsing cloud-init provided content. For example, on my Digital Ocean's node which is not affected by this bug I have /etc/sysconfig/network-scripts/ifcfg-eth0 which was written by cloud-init. The network scripts update is done by cloudinit/net/sysconfig.py:Renderer._render_subnets() method. Additionally, render_network_state() writes down NetworkManager configuration snippet. Does systemd-resolved parse any of those?No. It seems DigitalOcean added *custom code* [1] to write /etc/systemd/resolved.conf, and in *that new code* they messed up the syntax. Considering that it's new code, it seems most reasonable to just fix that.
Yes, I agree with that. How can we ensure they'd fix it? :)
[1] https://www.digitalocean.com/community/questions/fedora-33-how-to-persist-dns-settings-via-etc-resolv-conf?comment=96290 Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
