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?
--
/ 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
