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.
> 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?
Lennart
--
Lennart Poettering, Berlin
_______________________________________________
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
