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.
[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
